Figure 3 shows an alternative (and inferior) representation of the imaginary hub, in which the participants are represented in separate pools (long narrow rectangles), with message flow (the dotted arrows) between them depicting the interchange of messages. Although the pools are a nice visualization of the participants, the message flow creates an indecipherable clutter that makes the diagram almost impossible to read.
The sum-of-parts approach is shown in Figure 4. As the name suggests, choreography represented this way is, in a sense, the sum of the public processes of the individual participants and the exchange of messages that drives them. This approach is suitable if there is no requirement to evaluate the sum! In Web Services Choreography Interface (WSCI, an earlier choreography specification and a precursor to WS-CDL), for example, choreography is defined as the public behavior of each participant plus the global message exchange view. Figure 4 is a convenient representation of a set of WSCI interfaces. WS-CDL, by contrast, requires a single, global, unified definition, which would be hard to synthesize from the mess of process steps in the retailer and distributor pools in the figure. We are accustomed to watching dancers in a show dance as a group. What if each dancer performed separately, and we were left to combine them in thought as a group?
In UML, activity diagrams or collaboration diagrams could be used to build the imaginary hub and sum-of-parts approaches.
Code-Level Choreography with pi4soa
A software developer using pi4soa, the new WS-CDL code editor, can either create a WS-CDL choreography from scratch or import an existing one for modification. Although the import option fits our life cycle best, no tools exist to generate WS-CDL from a model (such as the one designed in the previous section), and hence the developer is left with the less desirable option of building a fresh WS-CDL while eyeballing the model.
The choreography managed by pi4soa is a WS-CDL file in a Java project in Eclipse. The pi4soa plugin provides a graphical editor that, behind the scenes, generates WS-CDL XML code (which can be viewed in a text editor). Figure 5 shows the pi4soa editor (the large window on the right side) open in the "base types" view, which allows the developer to assemble the main building blocks of the choreography. The "participants" view, shown in Figure 6, allows the developer to build structural participant relationships.
The key information in these views is the following:
- The participants (or roles) involved in the choreography are Distributor, Retailer, and CurrentRetailer, as well as two participants meant to simplify the implementation (for reasons discussed below): Customer (to model a customer's interaction with a retailer) and DistributorBizCal (a subsystem of the distributor to model the management of business calendars for completion and switch periods).
- Each participant (or role) has a behavior and a channel. The behavior is the participant's Web service, and the channel is its inbound communication endpoint. All interactions are asynchronous. To send a message to a retailer, for example, call its Web service by placing a message on its channel.
- There are four relationships. RD represents the interface between Retailer and Distributor, CRD the interface between CurrentRetailer and Distributor, RC the interface between Retailer and Customer, and DInt the interface between Distributor and DistributorBizCal. The relationships allow communication in both directions; RD, for example, lets Retailer call Distributor, or vice versa.
- The message type (or information type) exchanged between participants is an XML document called EnergyMsg, which contains fields (or tokens) such as custID, retailer, txID, currentRetailer, and reason.
In the third view ("choreography flows"), the developer uses these building blocks to construct the control flow of the choreography. The overall structure is shown in
Figure 7. The choreography begins with the "interaction" (i.e., message exchange)
enrollReqFromCust, in which the customer sends an enrollment request message to the retailer. The retailer then forwards that message to the distributor in the interaction
enrollReq
, and the distributor executes a "private" (i.e., placeholder) step
determineEnrollmentStatus to decide whether to accept the request, reject it, or initiate a switch.
The heart of the choreography is the "choice" structure enrollmentResult, which allows exactly one of its paths to run based on the enrollment status determined in the previous private step. The simplest of the three paths, for rejection, is the "sequence" shown in Figure 8, in which the distributor, in a private step, adds the reject reason to the message (the WS-CDL "assign" activity could also have been used for this), and then, in the interaction enrollRejected, sends the message to the retailer.
The acceptance sequence in Figure 9 is more complicated. The distributor begins by sending an acceptance message to the retailer in the interaction enrollAccepted, and then, in the private step setCompletionTimer, sets an alarm to go off at the end of the completion period. Next, one of two events can occur: the completion timer expires, or the customer cancels the enrollment with the retailer. These options are modeled as sequences periodExpired and cancel in the choice structure completionPeriod. The logic of each sequence is straightforward: in periodExpired, DistributorBizCal sends an alarm notice to the distributor (periodExpired) and the distributor, in turn, sends a completion event (enrollmentComplete) to the retailer; in cancel, the customer sends a cancel event to the retailer (cancelFromCust), which the retailer forwards to the distributor (cancel).
The switch path, shown in Figure 10, is similar to the acceptance path. The distributor begins by sending a switch pending message to both the retailer and the current retailer (in the pair of interactions named switchPending), having already, in private steps, added the identity of the CurrentRetailer to the message and set the switch business calendar timer. If the timer expires (in the periodExpired interaction), the distributor sends completion messages to both retailers (switchCompleted); if the customer cancels (cancelFromCust from customer to retailer, cancel from retailer to distributor), the distributor sends a notification to the current retailer (switchCancelled).
From Model to WS-CDL to BPEL
The WS-CDL choreography closely resembles the "imaginary hub" process shown in Figure 2 (described in the previous section). In particular:
- An interaction activity in the WS-CDL choreography is equivalent to a receive event followed by a send activity in the hub's process. In both cases, the effect is to move a message from one participant to another.
- The choice control structure in the WS-CDL is equivalent to the exclusive-OR event gateway in the hub's process. In both cases, the effect is to execute exactly one of several paths.
One glaring difference is the introduction in the WS-CDL choreography of the Customer and DistributorBizCal participants. The purpose is simplified implementation; specifically, to use event choice rather than exception handling to handle the race between period expiry and customer cancellation in the logic for enrollment acceptance and switch. Both outcomes are represented as events, and the first one to occur wins. The onerous alternative is to wait for the cancellation event for a specified duration, and handle the period expiry as a timeout exception.
The event choice approach also makes the individual participant process stubs easier to understand. For the retailer, once its enrollment request has been accepted by the distributor, it waits for either an enrollment completion message from the distributor or a cancellation event from the customer. For the distributor, once it has accepted the enrolment, it waits for either a period expiry notification from its business calendar system (an internal event) or the cancel event from the retailer.
The BPEL code generated by pi4soa from the energy choreography uses "pick" activities to model the event choice. Listing 1 shows, in pseudo code, the retailer's BPEL stub. There are two levels of event choice: the outer pick to determine whether the request was accepted, rejected, or caused a switch (lines 3-17), and the inner picks to manage the periods (lines 8-11 and 14-17).
The development life cycle spanning the modeling of the BPMN imaginary hub, the refinement of the WS-CDL code, and the generation of the stub BPEL process works. Viable participant processes can be derived from properly modeled, implemented, and tested choreographies.
References
Cloud computing is a game changer. The cloud ...
Subscribe to SOA World Magazine Email News Alerts
Subscribe via RSS
