Chapter 16
Service-Oriented Design
(Part IV: Business Process
Design)
16.1 WS-BPEL language basics
16.2 WS-Coordination overview
16.3 Service-oriented business process design
(a step-by-step process)
Erl_16.qxd 6/30/05 11:07 AM Page 565
T
he orchestration service layer provides a powerful means by which contempo-
rary service-oriented solutions can realize some key benefits. The most
significant contribution this sub-layer brings to SOA is an abstraction of logic
and responsibility that alleviates underlying services from a number of design
constraints.
For example, by abstracting business process logic:
• Application and business services can be freely designed to be process-agnostic and
reusable.
• The process service assumes a greater degree of statefulness, thus further freeing
other services from having to manage state.
• The business process logic is centralized in one location, as opposed to being dis-
tributed across and embedded within multiple services.
In this chapter we tackle the design of an orchestration layer by using the WS-BPEL lan-
guage to create a business process definition.
How case studies are used: Our focus in this chapter is the TLS environment. We
provide case study examples throughout the step-by-step process description
during which TLS builds a WS-BPEL process definition for the Timesheet Sub-
mission Process. This is the same process for which service candidates were mod-
eled in Chapter 12 and for which the Employee Service interface was designed in
Chapter 15.
16.1 WS-BPEL language basics
Before we can design an orchestration layer, we need to acquire a good understanding
of how the operational characteristics of the process can be formally expressed. This
book uses the WS-BPEL language to demonstrate how process logic can be described as
part of a concrete definition (Figure 16.1) that can be implemented and executed via a
compliant orchestration engine.
Erl_16.qxd 6/30/05 11:07 AM Page 566
WS-BPEL language basics 567
Although you likely will be using a process modeling tool and will therefore not be
required to author your process definition from scratch, a knowledge of WS-BPEL ele-
ments still is useful and often required. WS-BPEL modeling tools frequently make ref-
erence to these elements and constructs, and you may be required to dig into the source
code they produce to make further refinements.
Figure 16.1
A common WS-BPEL process definition
structure.
NOTE
If you are already comfortable with the WS-BPEL language, feel free to skip
ahead to the
Service-oriented business process design (a step-by-step
process)
section.
16.1.1 A brief history of BPEL4WS and WS-BPEL
Before we get into the details of the WS-BPEL language, let’s briefly discuss how this
specification came to be. The Business Process Execution Language for Web Services
(BPEL4WS) was first conceived in July, 2002, with the release of the BPEL4WS 1.0
specification, a joint effort by IBM, Microsoft, and BEA. This document proposed an
Erl_16.qxd 6/30/05 11:07 AM Page 567
orchestration language inspired by previous variations, such as IBM’s Web Services
Flow Language (WSFL) and Microsoft’s XLANG specification.
Joined by other contributors from SAP and Siebel Systems, version 1.1 of the BPEL4WS
specification was released less than a year later, in May of 2003. This version received
more attention and vendor support, leading to a number of commercially available
BPEL4WS-compliant orchestration engines. Just prior to this release, the BPEL4WS
specification was submitted to an OASIS technical committee so that the specification
could be developed into an official, open standard.
The technical committee is in the process of finalizing the release of the next version of
BPEL4WS. It has been announced that the language itself has been renamed to the Web
Services Business Process Execution Language, or WS-BPEL (and assigned the 2.0 ver-
sion number). The changes planned for WS-BPEL have been made publicly available on
the OASIS Web site at www.oasis-open.org.
Notes have been added to the element descriptions in this section where appropriate to
indicate changes in syntax between BPEL4WS and WS-BPEL. For simplicity’s sake, we
refer to the Business Process Execution Language as WS-BPEL in this book.
16.1.2 Prerequisites
It’s time now to learn about the WS-BPEL language. If you haven’t already done so, it is
recommended that you read Chapter 6 prior to proceeding with this section. Concepts
relating to orchestration, coordination, atomic transactions, and business activities are
covered in Chapter 6, and are therefore not repeated here. This chapter also assumes you
have read through the WSDL tutorial provided in Chapter 13.
16.1.3 The process element
Let’s begin with the root element of a WS-BPEL process definition. It is assigned a name
value using the name attribute and is used to establish the process definition-related
namespaces.
<process name="TimesheetSubmissionProcess"
targetNamespace="http://www.xmltc.com/tls/process/"
xmlns=
"http://schemas.xmlsoap.org/ws/2003/03/
business-process/"
xmlns:bpl="http://www.xmltc.com/tls/process/"
xmlns:emp="http://www.xmltc.com/tls/employee/"
xmlns:inv="http://www.xmltc.com/tls/invoice/"
568 Chapter 16: Service-Oriented Design (Part IV: Business Process Design)
Erl_16.qxd 6/30/05 11:07 AM Page 568
WS-BPEL language basics 569
xmlns:tst="http://www.xmltc.com/tls/timesheet/"
xmlns:not="http://www.xmltc.com/tls/notification/">
<partnerLinks>
...
</partnerLinks>
<variables>
...
</variables>
<sequence>
...
</sequence>
...
</process>
Example 16.1 A skeleton process definition.
The process construct contains a series of common child elements explained in the fol-
lowing sections.
16.1.4 The partnerLinks and partnerLink elements
A partnerLink element establishes the port type of the service (partner) that will be par-
ticipating during the execution of the business process. Partner services can act as a
client to the process, responsible for invoking the process service. Alternatively, partner
services can be invoked by the process service itself.
The contents of a partnerLink element represent the communication exchange between
two partners—the process service being one partner and another service being the other.
Depending on the nature of the communication, the role of the process service will vary.
For instance, a process service that is invoked by an external service may act in the role
of “TimesheetSubmissionProcess.” However, when this same process service invokes a
different service to have an invoice verified, it acts within a different role, perhaps
“InvoiceClient.” The
partnerLink element therefore contains the myRole and partner-
Role
attributes that establish the service provider role of the process service and the
partner service respectively.
Put simply, the
myRole attribute is used when the process service is invoked by a part-
ner client service, because in this situation the process service acts as the service
provider. The
partnerRole attribute identifies the partner service that the process serv-
ice will be invoking (making the partner service the service provider).
Erl_16.qxd 6/30/05 11:07 AM Page 569
评论0