Serializable Scopes
Introduction
Deploying the Process
Running the Process

Serializable Scopes

Introduction

This sample focuses on the variableAccessSerializable attribute of the scope activity along with its use and syntax. It includes an example BPEL process that uses serializable scopes. For a discussion of all other aspects of the scope activity, see The Scope Activity.

Serializable scopes provide concurrency control in governing access to a common set of shared variables. If two or more scopes are serializable, then access to any variable shared between them is controlled. Such scopes behave as if the scopes were executed in sequence (one after another), rather than concurrently.

The sample process, illustrated below, contains a sequence that starts with a receive activity that accepts a message containing an order. The sequence ends with a reply that returns a message containing a status string.

In between the receive and the reply is an assign that sets a status string to "Start", then a scope that sets the status first to "Ordering" and then to "Done ordering". Before doing so, the scope checks to make sure the status is not "Cancelled".

The process has an event handler that contains an onMessage that waits for a cancellation message. The onMessage contains a scope that handles incoming cancellation requests by setting the status variable's value to "Cancelled". Before doing so, it checks to make sure that the order scope has not yet started (the status is still "Start").

Both scopes have their variableAccessSerializable attributes set to "yes". Doing so makes sure that access to the status is serialized; that is, the two scopes can't execute at the same time.

The basic features and XML syntax of the scope activity are described in the Scope Sample documentation. Scopes that have their variableAccessSerializable attribute set to "yes" are said to be serializable. Such scopes provide concurrency control in governing access to shared variables. The engine guarantees that all access to variables shared between serializable scopes (and external to them) is coordinated such that conceptually all activities within each scope are completed before or after other serialized scopes—not concurrently.

Deploying the Process

See Deploying the Samples.

Running

See Running the Samples. The service name to use is serializableScopeProcessService. The sample data file orderMessage.xml can be used as input for this example. The reply will contain the string "Done ordering".