OSOA Home

Introduction

Executable WS-BPEL is a first class implementation language in SCA. It allows a component to be written in WS-BPEL and then deployed and assembled with other components written in WS-BPEL or written in other SCA implementation languages. By its very nature, a WS-BPEL implementation interacts with other components via WSDL interfaces. Therefore, WS-BPEL components can be assembled with other components whose services are exposed via WSDL.
 
SCA and WS-BPEL are complementary with one another. WS-BPEL is a language for defining a business process, which can be invoked by clients and can itself invoke other services. These external interactions, together with the activities that may occur inside the process, provide a business orchestration view of a component. SCA, on the other hand, provides a compositional view of interconnection among service components. SCA does not in itself allow one to define business or application logic. This is left to the implementation languages. SCA does support the aggregation of business services without relying on application states. It models a birds-eye-view of the system that includes WS-BPEL processes and other components with which they interact. This overall view provides a convenient tool to manage the deployment and configuration of a system.

The WS-BPEL Client and Implementation (C+I) Model is designed to allow any WS-BPEL 2.0 and 1.1 process to be used without them needing any knowledge of SCA. It allows any executable WS-BPEL process to be deployed into the SCA runtime without change. The SCA runtime provides features not defined by the WS-BPEL specification such as initialization of endpoint references of partnerLinks via wiring in SCA and initialization of WS-BPEL variable via SCA properties. Without SCA, such features are provided by vendor dependent mechanisms.

Overview of BPEL Client and Implementation Specification

The purpose of a client and implementation specification is to define how an implementation language supports and integrates into SCA. The WS-BPEL C+I defines how executable WS-BPEL processes map to SCA.

WS-BPEL, much like SCA, is built around the Web Services concept of separating implementation code from service interfaces. SCA and WS-BPEL, although based on similar concepts of connecting services together, do so in different ways. Fortunately, it is easy to map between the two.

In WS-BPEL, a partnerLink defines one or two roles, where each role identifies a WSDL interface or portType. A role is defined as belonging to either the WS-BPEL process or to the partner. A partnerLink with a single role belonging to the WS-BPEL process maps to a SCA Service in the WS-BPEL component's description. A partnerLink with a single role belonging to a partner maps to a SCA Reference.

In the remaining case where a partnerLink defines two roles, one for the WS-BPEL process and one for the partner, the directionality of the partnerLink needs to be determined in order to map to either a service or a reference. In SCA, the difference between a service and a reference is determined by which party sends the first message in a conversation. No matter how many messages a bi-directional conversation involves or how long it takes, there is always a first message. The sender of the first message is considered the client and the receiver is the service provider. Messages that go from the service provider "back" to the client are called callback messages.

If the first message on a partnerLink comes from the external party to the WS-BPEL process, the partnerLink is mapped to a Service in the component definition. The myRole will be the interface and the partnerRole will be the callback. All other partnerLinks will be mapped to References in the Component definition, with an appropriate multiplicity. The multiplicity will be "1..1" if the initializePartnerRole is yes; this is a Required Reference. If the WS-BPEL process uses an assign activity to set the value of a partner role before the partnerLink is used and the partnerLink does not have any SCA extension, then the multiplicity is set to "0..1" and the attribute wiredByImpl is set to "true"; this is a Stub Reference. This allows the reference to be exposed at the component level without the need for SCA to perform the wiring since this is done by the component itself; SCA can still apply bindings and policies and may need to set the endpoint address for callbacks, if the interface is bi-directional. All other kinds of partnerLink usage imply a multiplicity of "0..1"; this is an Optional Reference. Multiplicities with a cardinality greater than 1 are represented using a SCA extension, described below; this are called Multi-Reference.
 
The mapping of a partnerLink to SCA components can be done by static analysis and does not have to involve the author of the WS-BPEL process.

Figure 1: A WS-BPEL Process with four partnerLinks
 
Figure 1 illustrates a WS-BPEL process with four partnerLinks. PartnerLink 1 maps to a SCA Service, as it only defines a myRole and can only be used in a receive (or pick or onEvent) activity. PartnerLink2 maps to a SCA Reference, since only a partnerRole is defined and can only be used in an invoke activity. The initializePartnerRole is yes, so the cardinality of this SCA Reference is 1..1. PartnerLink 3 maps to a SCA Reference as either the WS-BPEL process or the partner may initiate the first interaction. The cardinality is 0..1 since the initializePartnerRole is no. Finally, partnerLink 4 maps to a SCA Reference as the partneRole is assigned to before it is used. The cardinality is 0..1 and the attribute wiredByImpl is  "true to indicate that the SCA runtime should not initialize this value, as the WS-BPEL process is initializing the value.
 
Since the PartnerLink concept from WS-BPEL maps very well to the SCA mechanisms, an additional SCA interface type is defined that directly represents a PartnerLink, <interface.partnerLinkType.../>.  Either this simplified form or the <interface.wsdl.../> forms described above can be used in defining the interface for a service or a reference.

Extensions

SCA WS-BPEL extensions are defined that allows the BPEL process designer to leverage some SCA specific features within a WS-BPEL process definition or to expose the process definition as an SCA component in a more precise fashion. Two extensions are currently defined, one for SCA properties and one for a multi-reference partner link.
 
An SCA property can be represented in WS-BPEL in a variable declaration and defined as an SCA property.  At runtime, the variable will be initialized with the value provided by the SCA component definition. This capability is provided as an additional attribute that is applied to a BPEL variable declaration: sca:property="yes".
 
In SCA, component types may declare references with a multiplicity that allows a single reference to be wired to multiple target services.  An example use of this capability is a purchasing component wired to a list of accepted vendors.  PartnerLinks in WS-BPEL allow only one target to be defined. The SCA BPEL C+I defines a sca:multiReference extension element that declares that the variable represents a multi-valued reference.   This is a list of multiple endpoint references for a partnerLink, which can reference many partners of the same type. This is very useful when a process needs to perform the same interaction over a set of similar partners, such as in a Request For Quote (RFQ) process. When this sca:multiReference extension is used, it is typically used with another extension sca:multiRefFrom that couples this kind of multi-valued reference list with an actual partnerLink declared.
 

Abstract Process in WS-BPEL

The SCA BPEL C+I only covers executable processes since an abstract process cannot by definition be executed. However, an abstract process definition that is compatible with an SCA BPEL component can provide additional semantics to users of the component above and beyond the WSDL definitions. Thus, an abstract BPEL process definition of a particular profile may be potentially associated with a component definition as part of its behavior contract; how this is done is outside the scope of SCA
 

References

 
[1] SCA Client and Implementation Specification for BPEL
[2] WS-BPEL Specification