Home arrow Web Services arrow Page 2 - Orchestrating Web Services
WEB SERVICES

Orchestrating Web Services


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).

Author Info:
By: Sams Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 3
August 03, 2006
TABLE OF CONTENTS:
  1. · Orchestrating Web Services
  2. · Two-Level Programming Model
  3. · SkatesTown Requirements
  4. · Business Process Execution Language for Web Services

print this article
SEARCH DEVARTICLES

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 process model 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.


blog comments powered by Disqus
WEB SERVICES ARTICLES

- Dealing with Loose Coupling in a Service-Ori...
- Loose Coupling in a Service-Oriented Archite...
- Safety, Idempotence, and the Resource-Orient...
- The Resource-Oriented Architecture in Action
- Features of the Resource-Oriented Architectu...
- The Resource-Oriented Architecture
- Getting Started with Flex
- Automated Billing and Faxing for the Web
- An Introduction to Web Services
- The Foundations of Web Services: From Novice...
- Web Services Reengineering: Finishing Touches
- Fault Handling with Web Services
- Flow and Web Services
- Process Lifecycles and Web Services
- Business Processes and Web Services

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials