Business Process Execution Language for Web Services 2nd Edition:

The development of web services technology and its use for integrating widely spread legacy applications for a multi-location company was not sufficient. Something more was needed: the integration (composition) of web services deployed by different companies. A typical business transaction requires the use of diverse web services. Let us take an example of a travel booking. When you use a website for booking your flights, you are using the service provided by the website and also the service provided by the airline. You may even request the lowest quote from different airlines during this transaction. So, you will be using the services offered by several companies in a single business transaction. This kind of composition of web services introduces many more considerations. The participating web services (partners) must collaborate with other participants and a coordinator to perform the desired business operation. The operation may be to achieve a simple buyer...

In the distributed web-services model, messages are exchanged between collaborating parties. During this message exchange, end-to-end message security must be addressed. As we have seen in earlier examples of typical business processes, a message may hop between many participating service providers. XML provides a platform-independent and network-neutral format for data transport. However, such messages must be secured. There may be a need to encrypt sensitive data. Also, once a service requester sends a message for a service to a service provider, the service provider may ask for the sender’s identity. The request message should be able to transport the user credentials securely to the provider. Overall, message transport in a business process has many more requirements than are typically required for point-to-point messaging, where a single transport and a single protocol is used for communication.

Message security primarily involves the following:

When you make a business trip, you typically require an airline booking, a hotel booking, and a car rental booking. Generally, all three bookings must be done before you confirm your trip. If any of these bookings is not available, you may have to re-schedule your business trip. This kind of business transaction involves confirmations from more than one participant.

Each participant is an independent business entity and will not like an outer business process, such as the one initiated by your travel agent, to get hold of the company’s resources. An initiating process (your travel agent) makes a request to each of the involved parties and obtains a commitment from them.

For example, you may request a direct flight to the destination on the specified day, the hotel booking for a couple of nights starting on the arrival day, as well as a car rental for the number of days of your trip. The travel agent makes a request to each of the concerned parties and...

In a typical business scenario, web services may be required to share information, such as security context, transaction context, and so on while participating in a composite business process. The WS-Coordination specification defines a framework for this purpose. This is an extensible framework and allows existing applications to hide their proprietary protocols while coordinating with other applications in a heterogeneous environment. It is used in conjunction with other specifications and does not provide a complete solution on its own. WS-Coordination is used whenever coordination between applications developed using different vendor specifications is desired. Such applications obviously run under different trust domains and so appropriate access control must be implemented.

The Web Services Transaction specifications define the coordination types discussed in the previous section. These specifications are used along with WS-Coordination and WS-Security to implement distributed transactions across a set of diverse web services.

The Web Services Transaction Specifications define two specifications:

An atomic transaction is a typical single-domain transaction that requires the ACID properties to be satisfied. This is typically used for activities of short duration and is applicable within a limited trust domain.

A business activity is used for activities having long duration. In this case, due to the long duration, the changes made by each participant are not hidden from others for an unduly long time and so are immediate and permanent. Exceptions are handled by the business logic and compensating transactions are used to guarantee consistency.

Both AT and BA allow coordination...

As mentioned earlier, a typical business activity spans several independent organizations. Implementing a transaction that requires ACID properties to be satisfied may not be possible in such cases, as a single transaction could last for hours or even days together. It may not be possible to hold locks on the participants’ resources for such a long duration. OASIS has defined a protocol called BTP (Business Transaction Protocol) that allows the coordination of business transactions spanning multiple participants. The transaction ensures consistency irrespective of the disparate applications running on different technologies deployed at different organizations. As it is not possible for a single controller to hold the resources belonging to different organizations, each participating organization is responsible for making a commitment required by a business transaction. The requester assumes that the party who has committed a portion of a business process will honor its commitment...

A typical business process is composed of several diverse web services. These services are provided by several coordinating partners. During the execution of the business process, several documents are exchanged between the partners. The means of exchange used for these documents must be reliable. This section discusses the standards for achieving reliable messaging between the partners.

In any communication, delivering a message reliably is of utmost importance to ensure the proper integrity of the system. Delivery of messages is subject to several error conditions arising due to:

Under such unforeseen conditions, messages should still be reliably delivered. XML-based messages are usually exchanged between partners over HTTP. HTTP is a stateless protocol and is not reliable. While using HTTP, a message in split into several small packets during delivery. Such packets are numbered. The order in which these packets are received...

Every web service has an endpoint to which service messages are targeted. WSDL allows you to define endpoints for the messages using port types, bindings, service elements, and so on. However, the WSDL 1.1 model lacks flexibility. (For detailed information on WSDL refer http://www.cos.ufrj.br/~baiao/papers/cavalcantim_workflow.pdf.)

To achieve flexibility, a new specification for defining endpoints has been proposed. This is known as WS-Addressing. This specification facilitates the following:

The specification defines new XML elements to address service endpoints. The following XML document illustrates the use of these new elements.

<S:Envelope xmlns:S=”http://www.w3.org/2002/12/soap-envelope”
  xmlns...

A web service provider publishes a service description for consumers. This is typically published as a WSDL document. The service provider registers a reference to the service description in a centralized registry, typically UDDI. The consumer locates a reference to the service description by looking up the registry and requests the service description from the service provider. The description document is usually emailed to the consumer, limiting the dynamic discovery and use of the service.

The WS-Inspection specification allows for dynamic discovery of service documents. WS-Inspection is XML-based and provides an aggregation of references to service descriptions. A WS-Inspection document does not describe a service—it just helps in locating a desired description document. Generally, a WS-Inspection document is made available at the point of contact of the service. The consumer parses this document to retrieve the references to the service descriptions and selects a desired...

Web services are composed to create an aggregate web service. A participating web service may need to communicate its policies to other participants. For example, one of the participants (a partner) may require a Kerberos security token for its access. This will be defined as a policy assertion in its policy document. Such policy documents must be shared between partners who wish to access the services provided by this partner site. A policy may consist of multiple assertions. The service provider may require all such assertions be satisfied by the requesting partner, or it may request the partner to satisfy at least one of the assertions. WS-Policy was designed for creating policy documents.

WS-Policy defines a set of constructs for specifying web service policies that can be communicated to others. The specification does not define how to transport or discover a policy. Policies may be associated with various entities and resources. The policy may be associated with arbitrary...

In a business process, a participating web service may be interested in receiving notifications whenever a certain type of event occurs in relation with other participating web services. A web service that is interested in such a notification should register its interest (subscribe) with other web services (event sources) where such events may be generated. The subscriber is called an event sink. The WS-Eventing specification allows you to create and delete event subscriptions. An expiration time may be set for each subscription. A subscriber may renew or unsubscribe its subscription with the event source.

All these requests are performed by sending an appropriate message to the event source. The WS-Eventing specification defines the message format for achieving this. Like the other specifications we discussed, this specification also relies on other service specifications for secure, reliable, and transacted message delivery.

Web services expose interfaces of existing components using a standard web-based protocol. A client uses these interfaces to use the services provided by the components. A typical business process requires multiple web services. The involvement of web services from different developers required the creation of new standards to achieve proper coordination between them. Several new standards were developed to achieve this coordination. This chapter has discussed several such open standards that are required for the coordination of web services.

The WS-Security specification addresses how to transport security context between the participating processes and thus how to provide a secured distributed computing based on the collaboration of diverse web services. The WS-Coordination specification defines a framework that is used by participating processes to coordinate the desired activities between multiple processes.

Web Services Transactions require the coordination between multiple...