Bpel4 Ws 1.1 To Ws Bpel 2.0

Bpel4 Ws 1.1 To Ws Bpel 2.0

• 1.
  Close Window Print Story BPEL4WS 1.1 To WS-BPEL 2.0 - An SOA Migration Path BPEL4WS V1.1 is a public draft release of the "Business Process Execution Language for Web Services" specification dated May 3, 2003. BPEL4WS V1.1 is arguably the de facto standard for Business Process Management (BPM); however, because it's a draft release, BPEL4WS V1.1 has several shortcomings that will be addressed by the next release of the specification (named WS-BPEL 2.0), which is targeted to be released either toward the end of this year or during the beginning of 2006. WS-BPEL 2.0, henceforth referenced as BPEL 2.0, is considerably different from the previous V1.1 draft release. The article will address these changes and demonstrate how to attempt to migrate a V1.1 business process to be compatible with a BPEL 2.0 engine. Sometimes this migration is simple and can be accomplished by means of syntactic changes to the process; sometimes the migration is not so easy, and mostly results in the rewrite of the process or process fragment. We will start with the simple cases and move toward the more complicated ones. It is not the intention of this article to explain BPEL 1.1 or to explain the new features of BPEL 2.0, so it is highly recommended that the reader have a good familiarity with the BPEL language. BPEL 1.1 Features That No Longer Exist We will first address those features that have been removed from BPEL 1.1. The concept of "partner" is no longer available for BPEL 2.0. A "partner" groups several "partnerLinks," and in doing so represents a common endpoint. Aside from being descriptive, the "partner" concept did not have any executable property, so it was decided that the language did not need this concept. The XML element "compensationHandler" and the XML attribute "enableInstanceCompensation" in the top-level "process" element have been removed. Instance (process) level compensation handlers never had any mechanism for being invoked; therefore, because they could not be used instance level compensation handling is no longer supported. Since it is very unlikely that any BPEL 1.1 engine made use of either of these concepts, it is generally safe enough to just remove them from the process definition when migrating to BPEL 2.0. Syntactic Changes The following changes are just syntactic. You can simply do a simple find-and-replace to migrate to BPEL 2.0: Replace the XML attribute "variableAccessSerializable" with "isolated" Replace the XML tag "terminate" with "exit" Replace the XML attribute "onMessage" of event handlers with "onEvent" Move the XML attribute "joinCondition" that is present in BPEL activities to be a child element of
• 2.
  "targets," as inthe following XML fragment: <invoke name="settleTrade"> <targets> <joinCondition> $buyToSettle and $sellToSettle </joinCondition> <target linkName="buyToSettle"/> </targets> </invoke> Replace the XML attribute value "rendezvous" of the attribute "initiate" with the attribute value "join" The schema type "tRole" no longer has a child element representing the port type; instead, the port type is now specified as an attribute directly in the role itself, as demonstrated in the following fragment: <plnk:partnerLinkType name="shippingLT"> <plnk:role name="shippingService"portType="shippingServicePT"/> </plnk:partnerLinkType> The attribute "portType" of messaging activities such as "receive," "invoke," "reply," "pick," and "onEvent" is no longer mandatory and can be omitted The URI used to specify XPath 1.0 as the expression/query language of choice has been changed, so replace the attribute value "http://www.w3.org/TR/1999/REC-xpath-19991116" of the attributes "expressionLanguage" and "queryLanguage" with the attribute value "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0" In addition to these, the syntax for assignments has been changed, but we will discuss this in a separate section. Extensibility of Expression/Query Languages In BPEL 1.1 expressions are used by switch conditions, while conditions and assignments such as XPath expressions are constrained as being an XML attribute value. Although this is not generally a problem for XPath 1.0 expressions, it is awkward for more complex languages such as XPath 2.0 or XQuery 1.0. XML attributes do not provide enough "real estate" for complicated expressions and also do not allow for the use of other XML features such as CDATA, or to write XML itself as the expression. Hence, to allow for better extensibility of BPEL using external languages, the authoring of expressions and queries are now realized within XML tags (elements) instead of attributes. In practice this means that the XML attributes "for," "until," "joinCondition," "transitionCondition," "expression," "query," and "condition" must all be changed to be XML elements, which would then contain the expressions (the expressions are the former attribute values). The following snippet shows an example of this conversion for XPath 1.0. Note that the attribute "expressionLanguage" is optional. <while> <condition expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"> $itemsShipped < bpws:getVariableProperty('shipRequest','sns:itemsTotal') </condition> <sequence> <!- do something --> </sequence> </while>
• 3.
  Listing 1 showsan example of a nonstandard usage of XQuery 1.0 as the expression language. BPEL 2.0 has thus far only standardized the usage of XPath 1.0. Links Links are used to specify synchronization dependencies between nested activities within a flow. In BPEL 1.1, links could not cross the boundary of structured activities such as "while," "isolated scope," "event handler," and "compensation handler." In BPEL 2.0, this restriction has been made stronger. Links that create a reentrant control path in scopes are no longer permitted. The reason for this tightening is to simplify the semantic of compensation handling. Figure 1 illustrates this banned scenario. Messaging Several aspects of messaging for BPEL 1.1 are unspecified. For example, there is no defined behavior for a process that receives a message for a request-response operation and finishes without replying. In BPEL 2.0, such a scenario would have trigged a new BPEL standard fault called "missingReply" fault. Another example has to do with event handlers. In BPEL 1.1 global event handlers are enabled as soon as the process starts, but the specification does not go into details to define exactly what that entails. Would an event handler instance be executed concurrently with the execution of the start activity that created the process instance? If so, what if the event handler instance is accessing some variable that would have been initialized by the start activity? All of these issues are left for the vendor implementation to answer. In contrast, BPEL 2.0 explicitly states that the global event handler is only enabled after the start activity has completed its execution, thus decreasing any chances for race conditions. However, what if there are multiple event handler instances? Do they operate on the same input variable? In BPEL 2.0, an "onEvent" activity declares its own input variable, hence each event handler instance works with its own local copy of the input data. The following snippet provides an example of a BPEL 2.0 event handler declaration: <onEvent partnerLink="eventLink" operation="event1" variable="inputVar" messageType="tns:eventMessage"> <correlations> <correlation set="id" initiate="no"/> </correlations> <sequence> <!-do something --> </sequence> </onEvent> BPEL does not allow a process instance to have multiple outstanding replies for the same request- response operation. This restriction prevents concurrent event handler instances for the same request- response operations from being supported. BPEL 2.0 solves this problem by allowing "correlationSets" to be declared in an "onEvent," thereby disambiguating the event handler instances. However, because this is a common user scenario, it is expected that vendors solved this specification shortcoming of BPEL 1.1 by providing their own vendor-specific mechanism that will likely differ from the BPEL 2.0 solution. There is no automatic way of migrating a business process to address these issues. People will have to understand how the vendor-specific behavior of the BPEL 1.1 engine being used is different from the BPEL 2.0-compliant behavior and take the appropriate actions. For example, consider the issue of the new BPEL fault "missingReply." It may be that one vendor-specific behavior prior to BPEL 2.0 was to raise a vendor-specific fault, i.e., "vendor:myFault," in which case the migration consists of replacing the vendor-specific fault with the new BPEL standard fault "missingReply." Compensation Handling
• 4.
  Compensation handling isone of the distinguishing features of BPEL. It allows business processes to support long-running activities. In BPEL 1.1, a compensation handler is executed with a frozen snapshot of the BPEL variables made at the time that the compensation handler was installed. In contrast, compensation handlers in BPEL 2.0 work off live data; that is, they use the current value of the BPEL variables. One way of mitigating this difference by guaranteeing that the BPEL variables are not changed is to declare them local to the scope that may be compensated. Compensation handlers declared within isolated scopes are not themselves isolated in BPEL 1.1. This is changed in BPEL 2.0: compensation handlers within isolated scopes also have isolated behavior. Note however that the scope and the compensation handler do not share the same isolation domain. In BPEL 2.0, attempts to invoke the same compensation handler more than once result in a no-op operation, as a replacement for raising the BPEL standard fault "repeatedCompensation," which has been removed. This makes sense because it seems unlikely that a business process would have a need to handle such a fault. Data Manipulation Data manipulation has changed significantly in BPEL 2.0. There are two parts to understanding these changes. First, BPEL 2.0 defines a data model to represent the BPEL variables. Second, BPEL 2.0 defines rules for mapping this data model to the different languages, such as XPath 1.0. The BPEL 2.0 data model is based upon XML infoset. Each BPEL variable is conceptually a separate set of XML documents. In the case of BPEL variables of WSDL message types, each WSDL message part is mapped into a separate XML document of the set. BPEL 2.0 data model mapping to XPath 1.0 is simplified, the BPEL XPath extended functions "getLinkStatus()" and "getVariableData()" were removed, and propagation of application data is done using XPath variables. Let's look at the first case. Instead of using "getLinkStatus(linkName)" to access the status of a link, one can just reference the link directly as an XPath variable, that is, by adding the "$" character to the link name, as shown in the following fragment: <joinCondition> $buyToSettle </joinCondition> The same idea applies to accessing BPEL variables. Instead of using "getVariableData(varName, partName)," one would reference the variable by using the "$varName" convention. However, in case of variables of WSDL messages, a part is referenced by appending the "." character and the part name to the variable name, as illustrated in the following snippet: <assign> <copy> <from variable="value"/> <to>$outputVar.value</to> </copy> </assign> Queries on property aliases also make use of the same concept. In this case, a BPEL predefined variable
• 5.
  named "source" mustbe used to reference the BPEL variable in question, as demonstrated below: <bpws:propertyAlias propertyName="tns:phoneNumber" messageType="tns:outputMessage"> <bpws:query>$source.value</bpws:query> </bpws:propertyAlias> In BPEL 1.1 it is not clear what the result of "getVariableData()" is. Is it an XML document fragment? Is it just character data? BPEL 2.0 tightens the definition by specifying that the XPath variable referencing a BPEL variable resolves to the document element of the appropriate XML document. Thus it becomes clear what can or cannot be accessed in the resulting document. For example, you are able to access the XML attributes and child elements of a BPEL variable using XPath 1.0 expressions, however you will not be able to navigate to a parent node to try to access a different WSDL message part using XPath 1.0, since we have seen that each WSDL message part is contained in a separate XML document. There is one caveat to this rule: when used in the context of an expression (in contrast to being used in the context of a query), BPEL variables of simple type return the simple type content itself (character data) instead of the document element. This is done to simplify common usage scenarios. Listing 2 shows XPath 1.0 expressions being used to access multiple BPEL variables of different Schema types. Finally, the BPEL "assign" construct itself has changed. Aside from the changes to the "expression" and "query" attributes that we have seen previously, literal assignments must now be authored within a "literal" element, as shown below: <assign> <copy> <from> <literal> <addr:phoneNumbertype="work"> <addr:countryCode>1</addr:countryCode> <addr:areaCode>408</addr:areaCode> <addr:number>570-8000</addr:number> </addr:phoneNumber> </literal> </from> <to variable="phoneNumber" /> </copy> </assign> Conclusion The issues that have been presented here are not final. Specifically, issues related to data manipulation are still undergoing changes in the BPEL 2.0 specification to be released. Neither is this article exhaustive in its listings of migration issues.
• 6.
  Furthermore, not allissues are likely to be addressed and corrected in time for the upcoming release. It is expected that issues, such as filtering of EPRs, inclusion of Business Process Transaction Management (BTM) constructions, and accessibility to transport (i.e., SOAP) headers will be handled in a future version of the specification. For all but the simplest business processes, migration from BPEL 1.1 to BPEL 2.0 is not an easy task. Some of the syntactic changes can be automated as shown in this article, however the semantic differences, especially when dealing with links, messaging, compensation handling, and data manipulation, will demand a comprehensive and time-consuming process. Nonetheless, BPEL 2.0 is a huge step forward from BPEL 1.1. Whereas BPEL 1.1 provided a framework for BPM, BPEL 2.0 is moving towards allowing for the portability of execution of business processes across vendors, and as such, is an important hallmark in the industry. References Business Process Execution Language for Web Services V1.1: http://dev2dev.bea.com/webservices/BPEL4WS.html Web Services Business Process Execution Language: www.oasis- open.org/committees/tc_home.php?wg_abbrev=wsbpel XML Information Set: www.w3.org/TR/xml-infoset/ XML Path Language (XPath) Version 1.0: www.w3.org/TR/xpath XQuery 1.0: An XML Query Language: www.w3.org/TR/xquery/ © 2008 SYS-CON Media Inc.