[Bernstein09] Section 5.7. Products and Standards

5.7. Products and Standards
Thissection offers two concrete examples to illustrate the concepts ofbusiness process management: the Web Services Business ProcessExecution Language (WS-BPEL) standard and the Service Broker componentof Microsoft SQL Server.
Web Services Business Process Execution Language
WS-BPELis a standard from the Organization for the Advancement of StructuredInformation Standards (OASIS), which is responsible for some of the WebServices standards. It specifies an XML syntax and execution semanticsfor business processes. A business process runtime system is WS-BPELcompliant if it can execute business processes that are expressed inWS-BPEL.
TheWS-BPEL standard does not specify a graphical notation or a programminglanguage syntax for expressing processes. Thus, a business processspecification tool is WS-BPEL compliant as long as it compiles businessprocess definitions into WS-BPEL—it can offer any notation or languagesyntax it wants to people who design business processes. There aredozens of such notations and languages. One popular notation is theBusiness Process Modeling Notation (BPMN), which is a graphicalnotation standardized by the Object Management Group and supported bymany tool vendors. An example is shown inFigure 5.7.[1] BPMN has been mapped successfully to WS-BPEL.
Example screenshot from the Eclipse SOA Tools Platform Project BPMN Modeler:http://www.eclipse.org/bpmn/images/screenshots/
Figure 5.7. Sample BPMN Diagram for Order Processing Flow. Therounded rectangles denote steps, the rectangles with folded rightcorners denote data, and the diamonds with plus signs denote fork andjoin.
[View full size image]

In WS-BPEL, the steps of a business process are called activities.WS-BPEL assumes that all activities are performed by Web Services. Aprocess defined in WS-BPEL describes the interfaces between a businessprocess and the Web Services with which it interacts. A WS-BPELbusiness process can itself be exposed as a web service. In addition, abusiness process describes the control flow of the activities, statemanagement, and exception handling.
Avariable in WS-BPEL contains a WSDL message type or an XML Schema (XSD)simple type or element type. For example, a process can use a variableto store a document or message that it receives from one service andthat it intends to send later to another service. Or it can use avariable to record state information about a process, as discussed inSection 5.3.A rich expression language is available to assign a value to avariable. In particular, components of a variable can be identifiedusing XPath, which is an expression language for referencing a portionof an XML document.
Each process is itself a service. Each interaction of a process is described by a partner link, which connects the process to a partner service. Each partner link has a partner link type,which specifies the name of the role of each participant in the linktype and the port type over which each participant communicates. Porttypes are abstract connection points to a service, which are later madeconcrete through a port definition that includes network information. Apartner link specifies the partner link type of which it is an instanceand the role that the process and its partner play. In RPC terminology,the partner link type and partner link define a service contract overwhich service invocations can take place.
Aprocess communicates with another service by invoking it via a partnerlink, either as a one-way or request-reply operation (i.e., an RPC).Since a process is a service, it can also receive such a call from apartner and, if the call is a request-reply operation, the process cansubsequently send a reply to the partner.
Aprocess can communicate with a particular instance of a service. To dothis, it identifies a set of variables that are input parameters toservice calls as a correlation set.Messages to a service that have the same values of a correlation setwill go to the same instance of that service. That is, the value of thecorrelation set identifies the instance of the partner service.
Aprocess has the usual control flow structures available, such as asequential execution of activities, a parallel execution of activities(called a flow), if-then-else, a case statement to select among activities (called a switch),a wait activity to wait for a duration or for a deadline, and loopingconstructs (while, repeat-until, for-each). It also offers an eventblock (called a pick) that identifies a set of event-activity pairs, where the first event to fire causes the associated activity to execute.
Eachactivity defines a scope. Larger scopes consisting of multipleactivities can be explicitly defined. Each scope can have an associatedfault handler and compensation handler. For example, a compensationhandler can be defined using the WS-BusinessActivity protocol ofWS-Transactions. There is considerable flexibility in defining thebehavior of these handlers to override the default. For example,suppose an employee makes a purchase, which is then billed to his orher department. To cancel this sequence and compensate for it, it maybe necessary to cancel the purchase first, to determine if there arecancellation fees that need to be deducted from the credit to thedepartment. This is the opposite order of the default, which is to runcompensations for transactions in the reverse order that they executed.
Scopes can also be used to control serializability. If two concurrent scopes are specified as isolated,then their execution must be serializable relative to their sharedvariables and partner links. That is, the effect of read and writeoperations on shared variables and partner links must be the same asthose effects in a serial execution of the two scopes.
A process may be partially specified as an abstract process,which leaves out certain details that are needed to execute theprocess. An abstract process may be useful as a description to businesspartners who should not see all details of the process or as a stabledescription that is unaffected by subsequent changes to implementationdetails.
At thetime of this writing, the latest release of the WS-BPEL standard isversion 2.0. There are many runtime engines that support some versionof the standard.
SQL Server Service Broker
MicrosoftSQL Server 2005 includes a queue-based system for managing businessprocesses, called Service Broker. It offers functionality to allowmultiple services to cooperate in the execution of a step of a businessprocess and to enable the step to retain persistent state of thebusiness process to be used by later steps. It also reliably andtransactionally delivers events and messages to a business process sothat the business process can reliably recover from failures withoutmissing or repeating steps.
Anapplication in Service Broker consists of a set of steps, which areimplemented by services. Each service is implemented by a program boundto a queue. The program can be a stored procedure or a program externalto SQL Server. To invoke a service, a program first creates a sessionwith the service, called a conversation,by calling Begin Dialog Conversation. It then sends a message over theconversation, which causes a message to be placed in the service’squeue. In the simplest case, the service starts a transaction, receives(i.e., dequeues) the message, does the requested work, and sends areply message over the same conversation and commits. This causes thereply to be enqueued on the caller’s queue. This is essentially themodel of queued messaging that we explored inChapter 4.
Messageswithin a conversation are processed in the exact order they were placedon the queue. This ordering is maintained even in highly scalablemultithreaded and multiprocess services.
ServiceBroker expands this simple queuing model in a number of ways to supportmultistep business processes. First, it has an abstraction called conversation group.Roughly speaking, a conversation group corresponds to a businessprocess. It has a unique ID, which is meant to be used to identifypersistent state that the application associates with the businessprocess. To invoke the first step of a business process, a programcreates a conversation without specifying a conversation group, whichtells Service Broker to create a new one. If this first step is part ofa multistep business process, then the service that executes this stepshould insert a row into a database table whose key is the conversationgroup ID. This row is used by this step and subsequent steps tomaintain the state of the business process. For each subsequent step,the program invoking the steps should create a conversation (to theservice that will perform the step) in the context of the businessprocess’s conversation group, so the service can access the businessprocess’s state. For example, if the first step S1 invokes two other steps, S2 and S3, then S1 should create a conversation to the services for S2 and S3 in the context of S1’s conversation group, thereby causing the services for S2 and S3 to execute in S1’s business process.
Itis possible that there are several messages in a queue that pertain tothe same conversation group. In the previous example, this could happenif S2 and S3 do their work and reply before S1’s service is able to receive either reply. If S1’s service is multithreaded, then when it does get around to receiving S2’s and S3’sreplies, it could end up with two separate threads processing thosereplies. To relieve the application developer from the synchronizationthat would be required between these two threads, Service Broker has abuilt-in locking protocol.
ServiceBroker locks the conversation group for the duration of any transactionthat processes a message in the conversation group to ensure that thisis the only service invocation (i.e., thread) that can process messagesfor this conversation group. The service invocation should receive andprocess the messages for this conversation group one by one. Followingthis protocol in the example would cause S1’s service to process the replies from S2 and S3 in the same transaction with no risk of another service invocation interfering with it.
Aservice can become idle when there are no messages in its queue. Toenable this functionality, Service Broker allows a service to bestarted in the following ways: (1) when a message arrives in its queue;(2) when an event is received; (3) at a scheduled time (e.g., everynight at 11 pm);or (4) when SQL Server starts up. In the first three cases, the servicebecomes idle after it has processed all the items on its queue. In case(4), the service remains active indefinitely and hence consumesresources even when idle.
Toensure that a service is sent only messages it knows how to process,Service Broker offers some message type management. An application candefine message types, each of which includes the name of the messagetype and a validation criterion. The validation criterion can be none(no criterion), empty (requires the message body to be empty), XML(requires the body to be well-formed XML), or validate with schemacollection (requires the body to conform to a given XSD schema). Thevalidation criterion specifies what validation work will be done by therecipient service at runtime for each message of this type that itreceives.
Whenstarting a conversation, one can specify a contract that says whichmessage types can be exchanged between the initiator (which is startingthe conversation) and the target (the other party to the conversation).To do this, the developer first specifies the contract. For eachmessage type in the contract, it says whether the initiator, target, orboth can receive messages of that type. A contract does not constrainthe order in which these messages can be sent or whether they can beduplicated; that is up to the services that participate in theconversation.
ServiceBroker offers a message retention option. This tells Service Broker tomaintain a permanent record of the exact sequence of messages that wereprocessed by a conversation; for example, to undo the steps of abusiness process.