Home arrow Web Services arrow Page 3 - Orchestrating 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
  1. · Orchestrating Web Services
  2. · Two-Level Programming Model
  3. · SkatesTown Requirements
  4. · Business Process Execution Language for Web Services

print this article

Orchestrating Web Services - SkatesTown Requirements
(Page 3 of 4 )

SkatesTown's business has grown over time, and the Web services it provides have become increasingly complex. The time has come to break up hard-wired service implementations into more fine-grained and manageable pieces. Processes expressed in a business process language can be changed more easily, which gives SkatesTown more flexibility and the agility to quickly react to changing business requirements.

Up to this point, SkatesTown has offered Web services that allow customers to submit purchase orders. These are now extended with a new service that lets customers cancel running purchase order requests.

Whenever SkatesTown receives purchase order requests, it initiates subsequent processing steps before a response is returned to the customer. These steps include SkatesTown-internal processing such as order request validation, stock management, delivery, and external interactions with the supplier.

During processing of a purchase order, three parties in different roles are participating in SkatesTown's overall business process:

  • The customer, acting as the buyer. The customer may submit order requests and may now in addition cancel orders.

  • SkatesTown itself, acting as the seller. The purchase order process that receives a customer order interacts with internal applications and optionally with services provided by a supplier.

  • The supplier. When SkatesTown can't fulfill a purchase order because it runs out of stock, an additional interaction with the supplier is initiated in order to replenish the item(s).

Figure 12.1 provides a high-level outline of SkatesTown's overall business process. Interactions with the business partners are indicated by lanes that show, from left to right, the communication with the customer, within SkatesTown itself, and with the supplier, respectively.

Figure 12.1  Outline of SkatesTown's purchase order process

We'll now examine more details of BPEL and give some example snippets for important elements of WSDL interfaces and BPEL processes. Finally, we'll explain how SkatesTown implements its business process with BPEL.

blog comments powered by Disqus

- 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 

Developer Shed Affiliates


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