Web Service Choreography Interface (WSCI)

The WSCI (pronounced "whiskey") draft specification was created jointly by Sun Microsystems, BEA, and Intalio in June 2002. WSCI is an XML vocabulary that describes how Web services that participate in long-lived, stateful message exchanges can be wired together. WSCI builds on top of WSDL.

To illustrate WSCI's major features, we start with a simple example of Flute Bank's loan service. The WSDL document in Listing 17.1 is not complete, because we have not shown the types, message, or service elements. The WSDL shows that the Web service exposes three operations. We define an interface that defines the processes exposed to a Flute customer. The process of helping a customer get a loan is the sequential execution of three steps:

1. The consumer sends a loan application to Flute Bank. Based on the consumer's credit rating and financial worth, the bank returns a list of loan options.

2. Later, from the list of qualified loan options, the consumer sends a selected loan for closing.

3. Because Flute Bank takes five days to process loan closing, the consumer may send a cancel message to Flute to have the loan request canceled within five days of submitting the request.

Listing 17.1: WSDL fragment showing the functional interface for Flute Bank's loan service

<definitions>
    ...
    WSDL types, messages etc go here ...
    ...
    <portType name = "consumerLoan">

        <operation name = "applyForLoan">
            <input message = "tns:loanApplication"/>
            <output message = "tns:qualifiedLoans"/>
        </operation>

        <operation name = "selectLoan">
            <input message = "tns:loan"/>
            <output message = "tns:loanConfirmation"/>
        </operation>

        <operation name = "cancelSelectedLoan">
            <input message = "tns:loan"/>
        <output message = "tns:CancelNumber"/>
        </operation>

    </portType>

</definitions>

These three steps are exposed as operations in the WSDL for the loan service, but as we mentioned before, the WSDL interface does not provide any sequencing information. Listing 17.2 expands the loan service WSDL and illustrates the WSCI elements that combine the operations in the correct order.

Listing 17.2: WSDL elements that combine WSDL operations properly

<wsdl:definitions>
    <types> ... </types>
    <message> ... </message>
    <portType> ... </portType>
    ... other WSDL elements
    ...
<interface name = "LoanService">
    <process name = "ProcessLoan" instantiation = "message">

        <sequence>
            <action name = "receiveApplication"
                role = "tns:LoanService"
                operation = "tns:consumerLoan/applyForLoan">

             <call process = "tns:CheckCredit" />
             </action>

             <action name = "receiveConfirmation"
                 role = "tns:LoanService "
                 operation = "tns:consumerLoan/selectLoan">

             <correlate correlation="tns:loanCorrelation"/>
            </action>
        </sequence>
    </process>

    <process name = "CheckCredit" instantiation = "other">
            <action name = "checkCredit"
              role = "tns:LoanService"
              operation = "tns:CreditAgency/checkConsumerRating">
        </action>

    </process>
</interface>

<correlation name = "loanCorrelation"
    property = "tns:loanRequestNumber">
</correlation>

</wsdl:definitions>

WSCI elements appear within the WSDL definitions (root) element. The WSCI interface element is the container for process definitions. In the example, the Flute Bank loan service interacts with a consumer service and exposes one WSCI interface for the interaction between them. The interface defines a process-the process of requesting a loan. WSCI allows a Web service to have more than one interface element. The intent is to have one interface element contain processes relevant to a particular scenario of interaction.

For example, although not shown here, the loan service will be interacting with an external credit rating service to calculate the consumer's credit rating. The processes used for the interaction between the bank and the credit rating service can be contained in a different interface element.

A process is an activity that establishes a new context of execution. It models the observable behavior of the loan service with respect to a loan request. In the example, ProcessLoan is the process defined in WSCI that models the Web service's behavior for a loan application. Within the process element, we define all relevant information regarding the process: how it is started, which WSDL operations are part of it, the sequence of execution of the operations, and so on. The instantiation = message attribute signifies that the process is instantiated upon receipt of a message-that is, when the first action the process refers to is ready. In this case, the ProcessLoan process will be triggered when the loan service receives the receiveApplication message.

The ProcessLoan process consists of the execution of a set of actions in sequence. The WSCI process uses a sequence element to indicate that activities or actions declared in the element are to be executed in order. The action element identifies an atomic activity-one that performs a single operation. While performing the action, the Web service can represent more than one logical role; the role=loanService attribute specifies that the receiveApplication action is executed on behalf of the loanService role.

A sequence is one way to represent a complex activity, which consists of multiple subactivities or an activity set. WSCI allows other types of complex activities to be modeled:

• The all complex activity can be used where activities in an activity set may be performed in any order.

• choice is used where one activity set is selected based on an event and that activity set is performed in order.

• An activity set can be performed for each iteration using the foreach complex activity.

• The switch complex activity selects an activity set based on a condition and performs that activity set in order.

Because Flute Bank has to check with an external agency for the consumer's credit rating, the receiveApplication action calls another process that does the credit check. The credit check process is modeled as a separate business process and is declared later in the WSCI as follows:

<process name = "CheckCredit" instantiation = "other">
    <action name = "checkCredit"
        role = "tns:LoanService"
        operation = "tns:CreditAgency/checkConsumerRating">
    </action>
</process>

In this case, the CheckCredit process has instantiation = "other", signifying that unlike the ProcessLoan process, which is instantiated by the receipt of a message, this process is started by an explicit call. Because receiveApplication is an atomic action, the call to check credit is done within the scope of the action. (Details of the external interface and the CheckCredit process are not shown.)

The second action declared in the ProcessLoan process is receiveConfirmation, which is declared much like the first action. One difference is that the second action declares a correlation element: <correlate correlation="tns:LoanCorrelation"/>. The correlation element provides the mechanism for modeling a conversation in WSCI. The correlation element in this example signifies that the receiveConfirmation action is to be correlated to the previous receiveApplication action if the values of the loanRequestNumber fields in the two messages are the same.

The simple example above showed how WSCI proposes to handle sequencing and correlation aspects of Web service business interactions. WSCI can also sequence and correlate message exchanges between two or more Web services. Additionally, it specifies how exceptions (or faults) are to be handled. WSCI supports the Java notion of a recoverable fault (in Java, an application can catch an exception and determine an alternate execution path).

Although WSCI does not define a mechanism to support transactional processes, it recognizes that activities may need to be processed within the scope of a transaction. In Chapter 14, we explained the BTP and WS-Transaction specifications. WSCI does not endorse any particular transactional specification-it provides support and guidelines for transactional activities within a process. WSCI also supports compensating activities for long-running transactions where locking may not be appropriate to provide transaction isolation (see Chapter 14 for long-running transactional properties).

Business Process Execution Language for Web Services (BPEL4WS)

Submitted jointly by IBM and Microsoft, BPEL4WS, or BPEL, is a specification that unifies and builds on the earlier XLANG (Microsoft) and WSFL (IBM) specifications for Web service composition.

Like WSCI, BPEL is an XML grammar to describe business processes that are a result of composing two or more Web services. BPEL defines two types of business processes: abstract and executable. Distinguishing between the two requires understanding the BPEL concept of a business protocol, which specifies the roles played by interacting businesses and the sequence of messages they must exchange to achieve a business function.

A BPEL process that shows only the details of the business protocol between two parties is called an abstract business process, because it does not define the private implementation view of the process. An executable business process shows not only the sequence of message exchanges but also the structure of each message, control flow, and so on. An executable business process in BPEL is like a WSCI business process. The BPEL construct that describes an abstract business process is a subset of the BPEL construct needed to describe an executable business process. BPEL, like WSCI, recognizes that WSDL supports only synchronous and uncorrelated asynchronous interactions between Web services. BPEL processes, like WSCI processes, represent long-running stateful (or correlated) conversations between Web services. In BPEL, a process can be conceptually thought of as sitting between interacting Web services (Figure 17.2). To a BPEL process, the participating Web services are partners in the business interaction.

Figure 17.2: BPEL process and partner services

The interaction between a BPEL process and the partner service is usually bilateral and often asynchronous. BPEL uses the notion of a serviceLink to model the peer-to-peer bilateral relationship between a process and its partners. A service link describes the roles played by the partner services and the message and portTypes used in the interactions.

We mentioned before that Web services (with WSDL) inherently do not provide the ability to describe or model long-running stateful message exchanges. In WSCI, correlation elements provide a mechanism to host stateful conversations over multiple WSDL operations. In a business process, messages exchanged between the partner services (a consumer and a loan service, for example) should provide the illusion of being exchanged directly between the partner services. In reality, the infrastructure that hosts the business process must provide a mechanism to correlate different message exchanges that form a part of the business process.

In WSCI, the correlation element instructs the runtime that activities are to be correlated based on the value of a particular field. In BPEL, a correlation set element correlates activities. Both these methods provide a declarative way to inform the runtime of how a set of activities in a process is to be correlated. Because the process must maintain state, the BPEL runtime must maintain all messages and intermediate data required for business logic. BPEL provides the container element to identify the messages and data that represent state information. All messages exchanged between the process and partners must be WSDL messages and should be identified in the container. Figure 17.3 illustrates the core elements of a BPEL process document.

Figure 17.3: Core elements of a BPEL process document

BPEL also defines primitive and compound activities. Simple activities such as receive (receive input message for an operation) , reply (provide a response to an invoked operation), and invoke can be considered steps in the business process. Compound activities are formed by structuring these primitive activities. For example, sequence allows contained activities to be performed in order, flow allows activities to be performed in parallel, and conditional branching is provided for by the switch activity.

Unexpected errors during the execution of the process are handled by faultHandler declarations. FaultHandler elements contain activities performed when declared faults are caught. Long-running processes that do not use locking for concurrency may need to use compensating activities to recover from errors. Compensating activities are an application-specific attempt to undo the partial effects of a business process. BPEL provides the CompensationHandler element to list compensating activities.

Figure 17.4 is taken from the BPEL 1.0 specification and illustrates the basic structure of a BPEL document.

Figure 17.4: Basic structure of a BPEL document

Protocol Bindings

WS-Routing specifies bindings to HTTP, TCP, and UDP. TCP and UDP require DIME (Direct Internet Message Encapsulation), a binary encapsulation mechanism for encapsulating the WS-Routing message. TCP and UDP bindings are not discussed in this section.

When using WS-Routing over HTTP, the mustUnderstand header attribute must be set to true and the SOAP actor attribute must be http://schemas.xmlsoap.org/soap/actor/next, so that all SOAP intermediaries either respect the semantic of the WS-Routing header or are forced to throw a SOAP fault.

When sending a WS-Routing SOAP message, the value of the Request-URI must be the URI of the next node in the message path. That is, if the SOAP message is to be routed via a WS-Routing intermediary, the value of the Request-URI should be the URI of the first intermediary listed in the fwd element. If there are no intermediaries in the path, the Request-URI must have the value of the to element. Also, as mentioned earlier, the value of the SOAPAction header must be the same as the value of the action element.

The simple example we used illustrated some of the basic concepts of WS-Routing. A mechanism to specify a message path for both SOAP requests and responses allows us to take advantage of a truly distributed architecture-each SOAP intermediary along the path can use its resources to provide some value-added service.

For example, while the sending and destination SOAP nodes provide the core business functionality, an intermediary can provide automatic authentication and authorization services. SOAP response messages that contain cacheable data can be routed to caching servers that cache responses for faster response to SOAP requests. In this context, WS-Routing is to be looked upon as a building block on which other specifications can rely on for providing value-added messaging patterns. Currently, the WS-Routing specification has not been endorsed or accepted as a routing standard by other industry players-IBM and Sun, for example, do not support WS-Routing.