You can use existing Web services to construct more complex Web services. It involves a certain amount of choreography, however. This article gets you started. It is excerpted from chapter 12 of Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418).
Orchestrating Web Services - Two-Level Programming Model (Page 2 of 4 )
Web services may be traditional applications, referred to as elemental services, or composite Web services. Composite Web services can be implemented by complex processes made up of multiple Web service invocations that are executed in a specified order.
Elemental services and composite services together constitute the paradigm of two-level programming: an application consists of a processmodel and service implementations. Programming in the small is the implementation of an elemental service with a traditional programming language. Programming in the large is the development of composite services in a business process language such as BPEL. On both levels, services may be reused in order to form new composite services.
Stateless and Stateful Web Services
Business processes may run for hours, days, or months, and they may invoke other long-running services. A business process can contain steps that require waiting for external events or human interaction. Thus, you need to execute the process in an interruptible fashion. We call such processes long-running processes.
Service requestors may either initiate the long-running process without waiting for its results or have multiple interactions with the process. In the latter case, you need to correlate the interactions with the same instance of the Web service.
We've already examined stateful Web services in Chapter 8. In this chapter, we introduce correlation of multiple requests with the same process instance.
Evolution of Business Process Languages
The Business Process Execution Language for Web Services (BPEL4WS, in most cases abbreviated BPEL) has been developed using combinations of concepts from the Web Service Flow Language (WSFL) and XLANG. BPEL supersedes these two language specifications.
The main objective of WSFL was to provide an XML language for the description of Web services compositions. In WSFL, you can specify a collection of Web services, the flow model, which is a description of a flow composition. A business process is described as a directed graph of activities (the nodes of the graph) and control connectors (the edges of the graph). Nodes and edges of the flow graph are annotated with attributes that determine the execution of the flow: for example, transition conditions for the execution of parts of the flow. In addition to flow composition, you can use WSFL to specify overall partner interactions, the global model. A global model is a simple recursive composition metamodel that lets you describe the interactions between existing Web services and define new Web services as compositions of existing ones.
The objective of XLANG was to provide a notation "for the specification of message exchange behavior among participating web services" in order to enable "automation of business processes based on Web services." To achieve this objective, the major constructs of XLANG include sequential and parallel control flow definition, long-running transactions with compensation, custom correlation of messages, exception handling, and dynamic service referral. An XLANG service description extends a WSDL service description with the behavioral aspects of the service. It lets you specify a set of ports in a service section of a WSDL document and extend it with a description of, for example, the sequence in which the operations provided by each port are to be used.
In July 2002, BEA, IBM, and Microsoft provided a first specification of BPEL. BPEL can be used as an implementation language for executable processes as well as for describing business protocols. It extends the Web services interaction model and enables it to support business transactions. BPEL defines an interoperable integration model that supports both the intraenterprise and the B2B spaces.
The first BPEL specification was published in May 2003 with additional contributions from SAP and Siebel, and it's the foundation for the standards work in the OASIS WS-BPEL Technical Committee.
With this introduction into the history of business process languages, let's look at SkatesTown to see how BPEL can be useful to this company.