From RosettaNet PIPs to BPEL Processes: A Three Level Approach for ...

From RosettaNet PIPs to BPEL Processes: A Three Level Approach for Business Protocols Rania Khalaf IBM TJ Watson Research Center, Hawthorne, NY 10532, USA [email protected]

Abstract. Business protocols in n-party interactions often require centralized protocol design but decentralized execution without the intervention of the designing party. In this paper, we tackle the problem for RosettaNet PIPs by creating a BPEL solution. We do so using a three– level approach, based on BPEL, for defining such multi–party protocols: templating for high–level patterns, specialization for particular protocols, and implementation for particular realizations of a protocol.

1

Introduction

Business protocols in n-party interactions often require the design of the protocol to be centralized but the execution to be done without the intervention of the designing party. In such cases it is desirable that instead of distributing one description from a global (neutral) point of view, or one description from a single point of view that mediates with all (hub-and-spokes), to distribute a package with an abstract business process for each party involved in the interaction and that defines its own required behavior. When plugged together, these processes show the complete behavior of all involved parties. It is also desirable to easily derive compliant implementations at each party from the abstract definition. This lowers the bar for parties to participate, basically shifting the burden from the participating party to the protocol designer. In such a set-up, the latter’s task now includes checking whether the created processes are in fact compatible while the participant, which may be a small business, has very little to do. We present the mapping RosettaNet Partner Interface Processes (PIPs) [4], which match our target environment above, to BPEL processes using a three– level approach for creating such protocol definitions. For details on mapping the quality of service requirements of PIPs that are not at the business process level by using the appropriate additional Web services specifications, see [1].

2 2.1

Background RosettaNet

RosettaNet (http://rosettanet.org) is a consortium of companies from the Electronics industry that defines an open e-business environment using an open– standards approach for the requirements and behavior of business partners. The W.M.P. van der Aalst et al. (Eds.): BPM 2005, LNCS 3649, pp. 364–373, 2005. c Springer-Verlag Berlin Heidelberg 2005


From RosettaNet PIPs to BPEL Processes

365

RosettaNet Implementation Framework (RNIF) represents requirements of a middleware infrastructure that supports the RosettaNet approach. Partner Interface Processes (PIPs) [4] are RosettaNet documents specifying two-party interactions to meet a business goal, such as processing a purchase order (PIP 3A4) or inquiring about a price (PIP 3A2). A PIP definition consists of a text document describing the expected requirements of the involved parties, including Message Sequence Charts (MSCs), DTD definitions of these messages, and quality of service requirements such as time-outs, security considerations, nonrepudiation, and retries. 2.2

BPEL

The Business Process Execution Language for Web Services, BPEL for short [2], is an XML workflow-based composition language for Web services. A BPEL process is exposed as one or more Web services with WSDL portTypes (interfaces), with typed “partnerLinks” defining its connections with other parties. BPEL activities are of two types: Primitive activities with pre–defined behavior like invoking a Web service(invoke), receiving and replying to invocations(receive/reply), waiting (wait), throwing faults(throw); Structured activities impose control on activities nested within them, such as strict sequencing (sequence), or parallelism (flow). Conditional control links may impose additional ordering within a “flow”. “Scopes” provide additional capabilities to their activities, such as data scoping, fault handling (detailed in [3]), compensation handling, and event handling. Instance management is done using “correlation sets”, basically using fields in incoming messages to route the messages to one of possibly several running instances of the same process. BPEL Processes can be either abstract and executable. A BPEL “abstract process” provides a specification of a service’s behavior and may hide private information that is not relevant to the other participants in the interaction. For example, an abstract process may initialize a variable with an opaque value. The abstract process then only has the other parties it interacts with in the interaction protocol as partners. On the other hand, the executable variant provides a process definition with enough information to be interpreted.

3

Premise

We propose a “templating-specialization-implementation” approach for the design and implementation of processes that follow patterns, such PIPs: 1. Templating: Creating BPEL abstract “templates” that capture the message exchange and behavioral pattern of each party involved. 2. Specialization: Making use of such patterns by creating full valid abstract BPEL processes from these templates that represent a specialization of that pattern. For RosettaNet, these constitute the definition of a particular PIP. 3. Implementation: Creating executable artifacts from these abstract BPEL processes so that each party can have an implementation of the PIP with

366

R. Khalaf

minimal effort and low adoption barrier. Simple derivation rules are provided by the designing party for participants to follow.

4

Related Work

[6,14,5] provide “neutral” models of interaction protocols. BPSS[5] has been used to map PIPs. Drawbacks include: no tie–in to back–end systems, requiring a translation, limited fault handling, lack of separation of concerns where one party can get only its own requirements for participation. A hub–and–spokes model (single mediating process) is also clearly undesirable for our scenarios. Approaches combining a neutral definition with individual behavior definitions are in [12] and [7]. There does not seem to be a straight–forward mechanism to derive a fully executable processes from these abstractions. [9] use “RosettaNet Controls”, Java entities that simplify process creation, to encode PIP patterns. They can exchange messages as prescribed by RNIF, but seem to be proprietary to BEA’s products. We presented a demo of part of this approach to the RosettaNet board and the BPEL Committee in Dec. 2003, focusing on combining multiple PIPs using a master proces. Each run kicked off 7 executable BPEL processes. These were manually created from abstract process, in turn manually created from the PIP definitions. It was a motivator for a RosettaNet working–group for PIPs over Web Services, and provided input to the BPEL standardization committee for abstract processes in V2.0. This paper adds to the demo and [1] in that they did not go into the details of deriving executables and did not use templates for process patterns.

5

Creating the Process Templates

A template consists of a single “pseudo-abstractBPEL” file for each partner involved. These are similar to abstract BPEL files, except for highlighting points of variability that a full abstract BPEL process would have to include. These are specified by omitting the BPEL elements/attributes required to be filled in. A schema validation of the process quickly shows where those points are, and could be done by a graphical editor. One should also provide any additional information needed in order to interpret hints about missing information, such as how to know which reply and receive activities match if the operation name is omitted. Ongoing work such as [10] and [8] addresses the challenges of proving compatibility when starting with behavioral definitions of each partner separately. 5.1

Creating the Templates for Two–Action PIPs

PIPs can be separated into several patterns. We focus on “asynchronous twoaction PIPs”.In a two-action PIP party A sends a message to party B. Party B then sends a response back to party A. Business level acknowledgements for both

From RosettaNet PIPs to BPEL Processes

variables: (respValid, xsd:boolean), (respAck, ?)

faultHandler: “ns:failedValidation”

faultHandler: “ns:timeoutAck”

Alarm Handler: Event Handler name=“failure” faultName= “ns:timeoutAll>”

variables: (reqValid, xsd:boolean), (respVar, ?) faultHandler: faultHandler: “ns:timeoutAck” “ns:failedValidation” Event Handler name=“failure”

rcvPO

from opaque=“yes” to reqValid reqValid reqValid

sendPO Alarm Handler

from opaque=“yes” to reqAck



confirm



367

from opaque=“yes” to respValid respValid

respValid



provider

from opaque=“yes” to respVar

invoke name=“PIPResponse” inputVariable=“respVar”/>

from opaque=“yes” to respAck Alarm Handler

sendPO

PIP Requestor





PIP Provider

Fig. 1. Template of all asynchronous two-action PIPs

messages must also occur within a given time-frame. Based on this information and RosettaNet’s message handling framework(RNIF), we can create a template for all asynchronous two-action PIPs and illustrated in Figure 1. The points of variability between PIPs of this class, shown in the figure, are: – PartnerLinks the process would be easier to read if these had names from the specific PIP definitions. Since PIPs are always two-party (except for 0A1, but the interactions with that are clear), it is straight–forward to know the activities with the other party. – Operation names based on the portType and operation on the WSDL files created from the PIP. – Variables with Message Types come from the mapping of the specific PIP’s DTDs to schema and the resulting WSDL files. – Timer values on the alarm handlers. – Correlation sets. These will depend on the messages in the WSDL. Since the names of the operations and portTypes are dependent on the specific PIP, we use the names of “receive” and “invoke” activities to hint that activities on

368

R. Khalaf

the different processes must match. For example, the invoke named “PIPRequest” sends a message from the PIPRequestor to be received by PIPProvider’s receive named “PIPRequest”. The next section show how this is used to create the full BPEL abstract processes for each type of PIP from these templates. Validation placeholders are seen at the conditions named *Valid. This validation is optional for some PIPs, going beyond the usual schema/XML validation. Retries are not in the business processes, because PIP retries are at the network level in RNIF. However, acknowledgements are business level since they are used not for “message received” but “message received and processed”, for example after having done an external dictionary validation. To faithfully represent the PIP, we require that any implementing system have a reliable delivery mechanism with configurable retry intervals. Alternate approaches for handling retries are discussed in [1]. Time-outs are represented as alarm handlers on scopes containing the corresponding receive activity, and throwing the relevant fault if time runs out. The fault is caught at the process level, sending failure notification to all parties involved so they don’t block. The fault is then rethrown. A message handler is defined for each of the processes that can receive this fault message and react accordingly. The fault rethrow and the message handler provide plugpoints for implementations created from this to react to the fault and perform any necessary clean–up with back–end systems. Note the ’invokes’ to “0A1”, the “Notification of Failure PIP”. This PIP is used if the partner to be notified of failure may have stopped executing. It receives a single error notification message that is supposed to come out of band, and is modeled here as a separate Web service.

6

Creating the Abstract BPEL Processes from a Template

In this step, one creates the complete abstract BPEL files that together encode the behavior of a subclass of the protocols represented by the template. The templates must be filled in using the information about these protocols. We will use the Purchase Order PIP, PIP3A4, to illustrate modeling of a two–action PIP from the template above. The resulting abstract processes are shown in Figure 2. 6.1

Abstract BPEL for PIP3A4 from Above Templates

The 3A4 has two parties: a buyer and a seller. The buyer sends a purchase order, expecting an acknowledgement and a confirmation that the order has been processed both within given time-frames. Upon receiving the confirmation, the buyer acknowledges its receipt. One WSDL portType is created for each party, to exchange the PIP messages. Add two more portTypes: one to be used by the external initiator of the processes, and the other for the 0A1 PIP. For 3A4, we create a sellerPortType with three operations: purchaseOrderRequest, failure, and purchaseOrderAcknowledgment. On the other side, we have a buyerPortType that will have

From RosettaNet PIPs to BPEL Processes

369

0A1 0A1

Initiator Initiator variables: (respValid, xsd:boolean), (respAck, ns:poAckMsg), (POVar, ns:po), (confVar, ns:confMsg) partnerLinks: sellerPL,0a1PL,initializerPL correlationSets: (RN_IDs, properties: PIP_ID, PIP_INSTANCE_ID) faultHandler …

faultHandler …

Alarm Handler: …



Event Handler: …



Alarm Handler For 8 hours

confirm

from opaque=“yes” to respValid respValid

respValid from opaque=“yes” to respAck



variables: (reqValid, xsd:boolean), (POVar, ns:po), (reqAck, ns:confAckMsg), (confVar, ns:confMsg) partnerLinks: buyerPL,0a1PL correlationSets: (RN_IDs, properties: PIP_ID, PIP_INSTANCE_ID)



faultHandler …

faultHandler …

Event Handler: …

from opaque=“yes” to reqValid reqValid reqValid

from opaque=“yes” to reqAck



from opaque=“yes” to respVar

Alarm Handler For 8 hours

PIP Requestor: Buyer



PIP Provider: Seller

Fig. 2. Abstract processes of 3A4 PIP

another three operations: purchaseOrderInitiate, failure, and purchaseOrderConfirmation. These operations are all one–way. Now we have the information to define the BPEL partnerLinks in our templates. For each of the two process templates: – Add a partnerLink for interacting with the other PIP participant, with a ’myRole’ with the portType the process offers to the other participant, and a ’partnerRole’ with the portType it requires from that participant. • Add this partnerLink, along with the corresponding portType, on all the activities that interact with the other participant. For example, in the buyer process add the partnerLink attribute with value “sellerPL” to the invoke named PIPRequest. – Add a partnerLink on the PIP requestor with a myRole with the portType offered to the external initiator that will kick–off the process. • Add this partnerLink and its corresponding “myRole” portType to the receive named outsideInit.

370

R. Khalaf 0A1 0A1

fault Handler: faultName=“ns:failedValidation” faultHandler: faultName=“ns:timeoutAck”

Alarm Handler: for 24 hours Event Handler: partnerLink=“sellerPL” operation=“failure”

faultHandler: faultName=“ns:timeoutAck” fault Handler: faultName=“ns:failedValidation” Event Handler: partnerLink=“buyerPL” operation=“failure”



PIP Requestor: Buyer

PIP Provider: Seller

Fig. 3. Handlers on the scope

An example of a partnerLink for the seller is: partnerLink name=’’buyerPL’’ partnerLinkType=’’ns:PIP3A4plt’’ myRole=’’seller’ partnerRole=’’buyer’’

Then, add the operations. The PIPRequest is the message with the main business document. The invoke on the PIPRequestor and the receive on the PIPProvider will therefore refer to the operations and messages that deal with the PurchaseOrder. Variables come next. Each message that will be exchanged results in one variable with that message type, with the corresponding interaction activity(ies) adding the variable attribute. Also, if the PIP does not require dictionary validation, we replace the assignment into one that copies “true” instead of an opaque value into the validation variable in each of the two processes. Consider the wait times for the alarm handlers. The global handler gets its value directly from the PIP document (24 hours for the 3A4 buyer). The other time-outs are on the acknowledgements. Since we assume a reliable messaging infrastructure, these values are the result of multiplying the ’retry count’ in the PIP document by the interval between retries (8 hours for 3A4). Such a failure would terminate the PIP, kicking off the 0A1. Finally, we need to choose the correlation sets. In RosettaNet PIPs, two values uniquely identify a PIP instance: the PIP Code and the PIP Instance ID. We use these as our correlation tokens.initiator). Note that correlations and portType names are not in the figure to lessen clutter.

From RosettaNet PIPs to BPEL Processes

7

371

Creating Compliant Executable BPEL Processes

Up to here, the definitions are created by the designing party which is expected to have experienced business process designers. However, implementations are created by customers, who may be small and medium businesses whose core business is not technology and possibly lack expensive business modeling expertise or tools. The abstract processes created above enable protocol implementers to generate compliant BPEL implementations simply by following an easy set of completion rules defined by the designers. This leverages the fact that BPEL abstract and executable processes share the same semantic and syntactic base. These compliant BPEL processes can be executed in any product supporting BPEL, thereby lowering the bar for an entity to participate. Creating compliant executables is one of the main complexities of such approaches. By providing simple but strict rules for creating the executables from the abstract processes, we ensure that an entry level user can create compliant executables without much difficulty. 7.1

Creating the Executables for Our Class of PIPs

The real work is forwarded from the executable to the company’s back–end systems, exposed as Web services. The partnerLink joining these systems to the process has the same type as that joining the two PIP processes together, but with roles reversed. The rules for creating the executables for our PIP are provided below. Adding anything else (ie: new links, lifecycle activities, ...) is prohibited. – flip the abstractProcess attribute to “false”. – replace all opaque assign activities with a sequence activity containing either: • Interactions (invoke, invoke+receive) with backend systems for necessary data: In our asynchronous case, a one way invoke followed by a receive activity. The partnerLink on both these activities is that of the back–end systems.Added invokes are not allowed to throw faults. Or, • Any assignment activities to any necessary data adaptation or copying of values (except endpoint references), especially those to propagate correlation set fields. – Add, in the handlers only, any assigns (in sequence) required for setting values of the variables used by activities in the handlers. – Add any variables and correlation sets that are needed for the new activities and partnerLink, and for the activities in the handlers. – Optionally add fault handlers at the top process level to do any required clean–up and notification of one’s back–end systems in case of process errors. 7.2

Compliance of the Executables

Different notions of equivalence between artifacts [13] have been proposed based on the class of problems addressed. In this section, we show that the executable

372

R. Khalaf

processes created by the steps above are equivalent to the abstract processes at hand according to a notion of conformance by Martens [11]. Martens states that the behavior of two processes is equivalent if an executable model could replace the abstract one without requiring changes to the environment in which the process operates. This is done by comparing “Communication Graphs” containing each process’s externally visible behavior. It simple to show that this is true: The additions provided above are one–to–one replacements of existing activities. The new activities do not affect lifecycle since they cannot throw faults, and do not affect control because they are contained inside “sequence”. Consider the externally visible behavior for the communication graph. The original (assign) activities did not have externally visible behavior. New invokes and receives may only interact with new partnerLinks not in the abstract process, and are therefore not visible to the environment(other PIP process). The communication graph of the executable is hence identical to that of the abstract making the processes equivalent with respect to the other PIP party.

8

Discussion and Future Work

BPEL abstract processes in V1.1 were created with ‘observable behavior’ in mind, leading to the current restrictions on syntax and semantics. The templates we define in section 5 are not valid abstract BPEL processes: They omit information essential for specifying full message exchanges. In response to requests for enabling a syntactic fill–in–the–blank templating usage, the BPEL committee is considering proposals for more ‘opaque’ tokens, and syntactic completion rules for the next version . The RosettaNet case shows that there are legitimate, simple cases where one needs a mix between purely the externally observable behavior or pure fill–in– the–blank templating. For example, one must not change the timer values, but should still be allowed add new partnerlinks and fault handlers. Neither of these would be acceptable for this case. Future work topics include wiring BPEL processes together (particularly relevant in more than 2 party interactions), looking into other classes of protocols for which this approach can be generalized, how each step can be generalized or parameterized, and expanding the approach for multiple parties.

9

Conclusion

This paper presents BPEL processes for RosettaNet PIPs, using a three–level approach that can generalize to similar environments with multi–party processes. We cover the creation from overall design, to specialization, to implementation. We highlight two main challenges in creating such bottom–up approaches, namely compatibility of the different processes and compliance between the abstract and executable artifacts. We focused on the usage of multiple levels of refinement using BPEL processes, levaraging a single language with wide–spread industry support (BPEL) due to the proliferation of tools and its abstract and

From RosettaNet PIPs to BPEL Processes

373

executable variants with related semantics. We provide a real and practical illustrative example of using the BPEL abstract–executable continuum and show how it one can express various levels of abstractions through iterative refinement. Acknowledgments. Paul Bunter and Sreedhar Janaswamy especially. Also Keeranoor Kumar, Ralph Hertlein, Peter Williams, Shishir Saxena for work on project. Francisco Curbera, Axel Martens and Frank Leymann for advice.

References 1. P. Bunter, R. Hertlein, R. Khalaf, and A. Nadalin. An approach to moving industry business messagung standards to web services. To appear online on IBM DeveloperWorks. 2. F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, and S. Weerawarana. Business Process Execution Language for Web Service v1.1. Online at http://www.ibm.com/developerworks/library/ws-bpel, May 2003. 3. F. Curbera, R. Khalaf, F. Leymann, and S. Weerawarana. Exception handling in the BPEL4WS language. In Proc. of BPM 2003, LNCS 2678, Eindhoven, the Netherlands, June 2003. Springer. 4. S. Damodaran. B2B integration over the internet with XML: RosettaNet successes and challenges. In Proc. of WWW 2004, Alternate Track Papers and Posters, pages 188–195, New York, NY, May 2004. ACM Press. 5. ebXML. ebXML business process specification schema version 1.01. Online at http://www.ebxml.org/specs/ebBPSS.pdf, May 2001. 6. X. Fu, T. Bultan, and J. Su. Conversation specification: A new approach to design and analysis of e-service composition. In Proc.WWW2003, Budapest, Hungary, May 2003. 7. X. Fu, T. Bultan, and J. Su. A top-down approach to modeling global behaviors of web services. In Requirements Engineering for Open Systems Workshop (REOS 2003), Monterey, California, sep 2003. 8. X. Fu, T. Bultan, and J. Su. Analysis of interacting bpel web services. In Proc. of WWW 2004, New York, NY, May 2004. ACM Press. 9. BEA Systems Inc. BEA weblogic workshop help online: Building RosettaNet participant business processes. Technical report, dec 2003. 10. A. Martens. On compatibility of web services. Petri Net Newsletter, 65:12–20, October 2003. 11. A. Martens. Consistency between executable and abstract processes. In Proc. of the IEEE Conference on e-Technology, e-Commerce and e-Service (EEE 2005), Hong Kong, Mar 2005. 12. W.M.P. van der Aalst and M. Weske. The P2P approach to interorganizational workflow. In Proc. of the Conference On Advanced Information Systems Engineering (CAiSE 2001), volume 2068 of LNCS, Berlin, Germany, 2001. Springer. 13. R. J. van Glabbeek. The linear time - branching time spectrum. In Proc. of CONCUR 90, number 458 in LNCS. Springer-Verlag, 1990. 14. W3C. Web Service Choreography Interface (WSCI) 1.0. Online at http://wwws. sun.com/software/xml/developers/wsci/wsci-spec-10.pdf.