Web Services Reengineering: Finishing Touches - Advanced Considerations
(Page 3 of 4 )
In addition to the concepts we've introduced, BPEL provides advanced capabilities. Let's examine abstract processes and language extensibility in more detail.
Abstract Processes
So far, we've concentrated on using BPEL to specify executable business processes. In addition, BPEL supports the definition of business protocols through the notion of abstract processes. A business protocol specifies the interaction of business partners via messages and their potential sequence—that is, the order in which messages between partners need to be exchanged to achieve a certain business goal. The details of what else happens internally at each partner to fulfill this goal are omitted. Typically, these messages result from internal business processes.
How are business protocols specified using abstract processes, and what distinguishes the definition of an abstract process from process definitions we have discussed so far? In general, business protocols aren't executable. An abstract process specifies the business protocol from the perspective of a partner's internal business process; however, it only provides a view of it. Business logic that describes, for example, how messages are constructed or how conditions are defined may not be part of the specification of the abstract process. An abstract process deliberately hides the details and complexity of the internal business process. It can omit variable specifications in receive, reply, invoke, and pick activities. The use of correlation sets in such cases is based on assumptions about their implicit initialization. BPEL also provides the notion of a special opaque assignment (<from opaque="yes">) that can only be used for abstract processes. Setting the process-level attribute abstractProcess to "yes" specifies that a BPEL process is of an abstract nature.
The constructs for specifying abstract processes are a subset of the constructs used to specify executable processes (with the one exception of the special assignment). This lets you specify an internal, executable business process and its views with the same language. It also provides for outside-in as well as inside-out approaches: You can start with the business partner's view and refine the process to become an executable process or vice versa.
SkatesTown uses an abstract process to precisely define the business protocol with its supplier. This specification is part of the contract between the two business partners. It provides the supplier with the information it needs in order to properly interact with SkatesTown. How SkatesTown actually realizes its business process isn't shared with the supplier.
Let's briefly revisit the interaction between the two partners. When SkatesTown needs to order additional supplies, it invokes the supplier's Web service operation orderSupplies and waits for a response from the supplier—either orderSuppliesOK or orderSuppliesFailed. If the response isn't received within a given timeframe, SkatesTown stops waiting for a response.
The example of an abstract process in Listing 12.9 expresses this interaction using a sequence that consists of an invoke activity (orderSupplies) followed by a pick activity (orderSuppliesOK, orderSuppliesFailed, or timeout). Details of what happened before the request was submitted to the supplier, or between the request and its response, or after the response was received, aren't of interest for the specification of this business protocol.
Listing 12.9 Abstract Process Describing Business Protocol with Supplier
<process name="orderSupplies"
targetNamespace="http://www.skatestown.com/
processes/purchaseOrderProcess"
abstractProcess="yes"
xmlns:pop="http://www.skatestown.com/services/
purchaseOrder"
xmlns:sup="http://www.wheelsandboards.com/
services/orderSupplies"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/
business-process/"
xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance">
<partnerLinks>
<partnerLink name="supplier"
partnerLinkType=
"orderSuppliesPartnerLinkType"
myRole="seller"
partnerRole="supplier"/>
</partnerLinks>
<partners>
<partner name="skatestownSupplier">
<partnerLink name="supplier"/>
</partner>
</partners>
<correlationSets>
<correlationSet name="orderCorrelationSet"
properties="customerID orderNumber"/>
</correlationSets>
<sequence>
<invoke partnerLink="supplier"
portType="orderSuppliesPortType"
operation="orderSupplies">
<correlations>
<correlation set="orderCorrelationSet"/>
</correlations>
</invoke>
<pick>
<onMessage partnerLink="supplier"
portType=
"orderSuppliesCallbackPortType"
operation="orderSuppliesOk">
<correlations>
<correlation set="orderCorrelationSet"/>
</correlations>
<empty/>
</onMessage>
<onMessage partnerLink="supplier"
portType=
"orderSuppliesCallbackPortType"
operation="orderSuppliesFailed">
<correlations>
<correlation set="orderCorrelationSet"/>
</correlations>
<empty/>
</onMessage>
<onAlarm for="P1M">
<empty/>
</onAlarm>
</pick>
</sequence>
</process>
Language Extensibility
The BPEL language may be extended by elements of other XML namespaces. You can add XML attributes and nested elements to standard BPEL elements. BPEL requires that such extensions must not change the semantics of existing BPEL elements.
We can envision a number of reasons to extend the language. However, you must be aware of the fact that every language extension may break the portability of processes or cause interoperability problems. Sample scenarios that may require BPEL extensions include
Attributes of the BPEL process definition let you specify the query language and expression language used, for example, in assignments or conditions.
Language elements can be added for features that have not yet been addressed by the current BPEL specification. The BPEL specification separates the notion of a core language and additional language elements for specific purposes.
In order to accommodate new versions of other standards (for example, new versions of WSDL), elements can be added to the BPEL language.
Elements for different types of interactions with other entities can be added. An example is the execution of inline code written in a standard programming language. Another extension would be an activity type that defines interactions with human users. Such activity types can be found in existing workflow management systems, but have not yet been provided by BPEL.
Next: Summary >>
More Web Services Articles
More By Sams Publishing
|
 This article 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). Check it out today at your favorite bookstore. Buy this book now.
|
|
