In this chapter, we have become familiar with the BPEL, its role in the SOA, and basic concepts related with service composition and the definition of business processes. BPEL provides a rich vocabulary for defining processes and has several features not found in programming languages.
This makes BPEL the preferred choice for composition of services. Major software vendors on Java and Microsoft platforms support BPEL, and even open-source implementations exist. Based on the comparison to other technologies and languages, we have seen that BPEL plays important role in service composition.
BPEL fits very well into the SOA, and with BPEL, we can define executable business processes and abstract business processes. Executable processes are the most important and allow us to define the exact order in which services are composed.
To continue reading, you have two choices:
If you are interested in the web services technology stack, which covers WS-Addressing, WS-Security, WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity, and other specifications, you should continue with Chapter 2.
If you are interested in BPEL only then you should proceed directly to Chapter 3.
2
Web Services Technology Stack
Chapter 1 introduced you to SOA and BPEL—a language for composing web services. The composition of web services requires several new considerations in the protocol stack. Such collaborations require exchange of security tokens, transaction contexts, reliable delivery of messages, etc. Thus, the existing web services protocol stack must be modified to account for the additional information that must be carried as a part of the message.
In this chapter, we will study the modified protocol stack and the various new components added to the stack. Several new standards have been created for accommodating these components in the new stack. These are WS-Security, WS-Coordination, WS-AtomicTransaction, WS-
BusinessActivity, WS-Reliable Messaging, WS-Addressing, WS-Eventing, etc.
E-Business Collaborations
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-seller transaction or a complex supply chain transaction. All such transactions require a workflow to be defined between different collaborating parties. Defining and executing such workflows is called orchestration. In this book, you will learn the emerging standards for defining the workflows for e-business collaborations.
When two companies collaborate and allow the composition of their services into an aggregate service to be invoked by yet another partner (a client), we need to implement proper coordination for all involved activities. A client determines the workflow for the execution of different services.
A typical business activity for travel booking is depicted in the following figure:
Clients interested in making an airline reservation at the cheapest rate log on to a travel agent's site. They fill in the request for travel, specifying the origin, destination, and proposed travel dates.
The travel agent's service now passes on this information to various airlines to obtain the
availability of seats and their best quotes. The availability, along with the lowest fare offer is then communicated to the clients. Clearly, such business activity requires collaboration between diverse parties.
We need a proper standardized language for describing such a workflow. As the workflow requires transport of several messages between coordinating partners, we need to establish an infrastructure for the reliable transmission of messages. The messages must be secured and their delivery should be guaranteed. The client may initiate a business process as a part of a transaction that may involve diverse partners. Such transactions must meet the usual requirements of a DTC (Distributed Transaction Control); this is discussed later in depth. As the messaging is
XML-based, we need to create standards for transporting transaction contexts through an XML document, which is purely text based. The same thing applies even to security context—such context must be transported through a text-based document. Note that typically these contexts are binary and not text based.
Having seen the need for orchestrating web services to achieve e-business collaborations, let us first look at the various standards defined for such collaborations. The following diagram positions the various standards in the stack:
Chapter 2
At the bottom of the stack, we have various specifications for component architecture. These may be Microsoft's .NET/COM+ architecture, Sun's Java EE architecture, or OMG's CORBA
architecture. On top of the component architecture, we have specifications for creating web services. This consists of mainly SOAP and WSDL. Above this, we have several new
specifications to support the integration and composition of web services. This chapter discusses all such new specifications, why they are needed, and the purpose they satisfy. At the top we have BPEL, which is the subject of this book. In this section, we will describe the various specifications that will be discussed in the rest of this chapter:
• WS-Security: Addresses the transport of security context.
• WS-Coordination: Defines a framework for achieving coordination between partners.
• Web Services Transaction Specifications: Specifies the standard for creating a distributed transaction involving multiple web services. This consists of.
• WS-AtomicTransaction: Specification for creating Atomic transactions that typically last for a short duration.
• WS-BusinessActivity: Specifies the standard for creating long duration distributed transactions.
• WS-Reliable Messaging: Specifies standards for reliable delivery of messages between partners.
• WS-Addressing: Defines the endpoint of communication.
• WS-Inspection: Defines specifications used for dynamic discovery of service description documents.
• WS-Policy: Specifies the policy of a web service provider for the benefit of service consumers.
• WS-Eventing: Defines event sources and consumers in the event model.
33