From DAML-S processes to BPEL4WS

From DAML-S Processes to BPEL4WS Sisi Liu Massachusetts Institute of Technology Cambridge, MA [email protected] Abstract BPEL4WS is a process modeling language for composing Web services. On the other hand, DAML-S is an ontology for defining Semantic Web services that includes a process model. We present a one-way mapping from the DAML-S process model to BPEL4WS, focusing on their common aspect: providing a specification of a service’s interaction protocol. The mapping clarifies their relation to each other, and enables DAML-S described services to be used by Web services requestors that are not semantically-enabled. A prototype translator was created, and examples are provided.

1. Introduction The Web services framework [7, 4] has emerged to enable applications created by different enterprises to interact in a loosely coupled manner regardless of their location on the network. Web services is based on a modular, open stack of XML specifications for service description, discovery, interaction and composition. BPEL4WS [5] is a process modeling language for Web services that are defined using the Web Services Description Language, WSDL [2]. In a parallel stream, the Semantic Web has emerged to enhance Web artifacts with well-defined semantic information so they may be reasoned about by machines and people. DAML-S [1] is an ontology for describing Web services by providing semantic information regarding their use. One of its capabilities is to define a process model describing how the service works. It was not long before people realized that one may gain from adding semantic information to Web Services, leading to Semantic Web Services [8, 18]. Since both DAML-S and BPEL4WS contain process modeling capabilities, it is natural to consider the relation between the two. We present a one-way mapping from DAML-S processes to BPEL4WS processes. One goal is to allow services defined in DAML-S to expose their interaction protocol using pure Web services specifications such

Rania Khalaf IBM Research Hawthorne, NY [email protected]

Francisco Curbera IBM Research Hawthorne, NY [email protected]

that they may be consumed by clients and tools that are not DAML-S enabled. These tools/clients will not be able to reason about or otherwise use the semantic information provided in the original DAML-S definition. A second goal is to clarify the similarities and differences between the two models. The two process models are partially overlapping; we do not claim that BPEL4WS may fully replace a DAMLS description. Instead, we concentrate on their common aspect: the ability to provide a specification of the functionality of a Web service. The next section of this paper describes DAML-S and BPEL4WS in more detail. This is followed by a discussion of the two approaches.Then, we derive a one-way mapping from DAML-S to abstract BPEL4WS processes. We finalize with a discussion and identification of the open issues.

1.1. Background 1.1.1. The DAML-S Process Model DAML-S is a DAML+OIL ontology for describing Web services by providing semantic information on their use. A DAML-S description consists of three parts: a service profile containing the semantically rich description of the service’s capabilities, a process model describing how a service works, and a grounding to concrete specifications of the elements needed to realize an interaction. The process model in DAML-S consists of atomic and composite processes. Composite processes provide control semantics on a set of atomic and/or other composite processes contained within them. Processes may have a set of inputs, outputs, preconditions and effects; however, only the atomic processes are considered invocable. Additionally, a dataflow may be provided to declare that certain pieces of data from different parts of the process model should have the same value throughout the interaction. There are plans in place to also provide a Process Control Ontology for monitoring a process’ execution. Each atomic process is invocable and must therefore be grounded to a WSDL operation and its inputs/outputs grounded to the appropriate WSDL messages. Composite

Proceedings of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04) 0-7695-2095-2/04 $20.00 © 2004 IEEE

processes are not grounded to WSDL operations. The preconditions and effects have no WSDL counterpart and thus play no part in the grouding [17]. 1.1.2. BPEL4WS BPEL4WS, BPEL for short, is a workflow–based language for composing Web services that enables the specification of control and data logic around a set of Web services interactions. The resulting process is exposed as a Web service using WSDL. The unit of composition in BPEL is the activity. Primitive activities perform actions such as invoking other services (“invoke”), receiving and replying to messages (“receive”,“reply”), manipulating data (“assign”), waiting (“wait”), or doing nothing (“empty”). These may be nested in structured activitites imposing control constructs on activities they contain such as executing in a sequence (“sequence”), in parallel (“flow”), or loops (“while”). Within a “flow”, additional control dependencies may be specified using links that may cross boundaries of most structured activities. Data is saved in scoped variables shared between activities. Correlation is used to declare that pieces of data touched by different activities must have the same value after having been initialized. This may then be used to route messages to the correct running process instance at runtime. BPEL also contains sophisticated event handling, fault handling, and roll-back capabilities. The entities the process interacts with are modeled using a “partnerLink” for each. This specifies the portType provided to that entity by the process (by “receive” or “receive” and “reply”), as well as the portType whose operations the process itself will invoke on that entity (by“invoke”). BPEL can define both executable and abstract processes. An executable process uses an expanded vocabulary that provides a complete definition of a process model such that it may be interpreted. On the other hand, an abstract process aims to provide 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.

2. Related Work A large body of work is accumulating regarding both Web Services and the Semantic Web, and particularly regarding either BPEL [6, 10]or DAML-S [15, 9]. Here, we address works that present a combination of the two areas. Concentrating directly on the relation between the DAMLS process model and BPEL4WS, [14] presents a preliminary high–level discussion comparing the two. In this paper, we provide a concrete mapping between the constructs of the two languages and a discussion of the issues. Work on using semantic information in conjunction with Web services process models (such as BPEL) has concen-

trated mainly on composition. [12] integrates semantic analysis with existing BPEL processes to take user constraints into account when finding and binding to services during an interaction. For example, a service that can adapt to mismatches may be included in the chain between the BPEL process and the ultimate service provider. In [11], semantics are used to add necessary steps to an existing BPEL process based on reasoning about the preconditions and effects of available providers. In [19], a process is partially defined and then annotated with semantic information (not using DAML-S) that may be analyzed at runtime to fill the missing pieces and derive a complete executable BPEL process. However, none of these papers directly addresses the DAML-S process model in their usage of BPEL4WS.

3. Comparison of BPEL4WS and DAML-S 3.1. Objectives: Differences and Overlap BPEL4WS is aimed at defining Web services compositions and business processes. DAML-S is aimed at providing a service description that facilitates the automation of Web service discovery, invocation, interoperation and composition. Its unit of composition is a level of abstraction above BPEL’s: where BPEL directly refers to WSDL operations, DAML-S atomic processes provide a less concrete description of the process’s side effects and goals which is later bound to a WSDL operations. While composition is a target of both, BPEL itself is directly concerned with defining multi-party compositions, while the DAML-S process mdoel currently defines a two–party interaction with a service provider and a service requestor. In [18], the “language allows the specification of the interaction protocol of the provider”; in BPEL, this same specification is called the “business protocol” [5] and is usually defined using an abstract BPEL process. While each is able to do more in itself - DAML-S process model includes information about consequences and requirements; BPEL contains an executable variant, fault handling, concerned with multi-service composition etc. - the protocol specification is where most of the overlap lies.

3.2. Process Structure In BPEL, the process model is derived from a combination of algebraic and graph–based models: Activities may be nested in structured control constructs, yet control links may be used both within and across the structured activities [6]. The interaction activities with partners directly use Web services operations, enabling an execution mechanism. In DAML-S, the process structure is algebraic, with strictly nested activities. The ontological structure of DAML-S allows classes to draw properties from hier-

Proceedings of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04) 0-7695-2095-2/04 $20.00 © 2004 IEEE

archical inheritance and through relationships to other classes[1]. It is not meant to be executable.

3.3. Process Specification McIlraith and Mandell [14] point out a set of key differences between the two process models: DAML-S encodes the side-effects of services thereby enabling higher level reasoning about their use; it is capable of expressing relationships such as inheritance between classes; BPEL contains fault and compensation handling capabilities not present in the DAML-S Process Model; neither directly exposes an execution monitoring capability. In this section, other key relevant differences are laid out. • Control Constructs With structured activities, links, event handling and timers, BPEL has a powerful set of control constructs to implement arbitrary flow of control with flexible branching semantics. Without links, timers, or events, DAML-S has limited branching capabilities. Additionally, DAML-S lacks support for conditional expressions at this time. • Data BPEL allows sharing and copying of data through variables, and supports XPath expressions and function for data handling and querying. DAML-S includes concepts of computedInput/computedOutput in its process ontology, but support for expressions is missing. This is more natural in BPEL because data is already expressed as WSDL messages with an XML structure, whereas the DAML-S process model is a level of abstraction above that. • Lifecycle BPEL uses a well-defined correlation mechanism to route messages to the correct process instance when it is maintaining multiple conversations with its partners. The DAML-S dataflow concept is able to define that different properties must have the same value. This information may be used to identify the conversation, similar to the use of properties and correlation in BPEL; however, this is not specified as its aim. • Multi-party interactions BPEL allows the specification of an arbitrary number of parties that interact with the service, relating interactions with the same party to each other using the partnerLink concept and a builtin correlation mechanism. The separation between the operations offered by the service to each party and those offered by that party to the service itself is clear. In DAML-S, the current specification addresses only a requestor and provider scenario. A placeholder for “participants” has been created to move towards multiparty capabilities (see section 5). Regarding their stability, neither specification is final. DAML-S, at version 0.9 beta, contains several placeholders and is undergoing significant

changes such as moving to OWL. BPEL, at version 1.1, has several implementations available in industry and research, but is still under standardization in OASIS. Since it was released as a complete specification, BPEL is presumably closer to its final form than DAML-S.

4. Mapping DAML-S to BPEL4WS The interaction activities in BPEL refer first class to WSDL elements; therefore, the mapping focuses on the DAML-S process model [14] and its grounding to WSDL. Given that the DAML-S process model is not meant to be executable and plays mainly a specification role, it relates most directly to the abstract, not executable, BPEL processes. The semantic information in a DAML-S process, which does not have a corresponding concept in BPEL, is left at the this time to other efforts such as the semantic annotation of Web services[19]. We arrive at the following: DAML-S Process Model (+ Process Grounding) --> BPEL4WS Abstract Process

4.1. Mapping The derived mapping is presented here, deferring the discussion of issues and design decisions to section 5. The DAML-S ProcessModel of a service is mapped to an abstract BPEL process. Each DAML-S process in the process model is mapped to combinations of BPEL activities. Process properties are mapped to variables, partnerLinks, correlation, and other corresponding core BPEL concepts. 4.1.1. Properties Parameters: 1. Inputs The Process Grounding grounds the set of inputs of a DAML-S atomic process to a WSDL message type, grounding each input to a “part” of that message. Therefore, we map the set of inputs to a variable with the message type specified in the grounding. Inputs of a DAML-S composite process are a reflection of the inputs of its subprocesses. If the composite process bottoms out in atomic processes, its inputs can be related to the inputs of that atomic process and consequently mapped to BPEL variables. 2. Outputs Unconditional outputs of a DAML-S process are mapped in the same way as inputs. However, conditional outputs remain unresolved in DAML-S 0.9 beta, due to the problematic grounding of conditional outputs to a single WSDL output message. We suggest typing the output using an XSD Schema complex type with a element. If this is done, DAML-S conditional outputs could then be mapped in the same way as unconditional outputs.

Proceedings of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04) 0-7695-2095-2/04 $20.00 © 2004 IEEE

3. Participants A ”Participant” is currently a place-holder in the DAML-S process model. Once fully specified, one would map it to partnerLink/partner in BPEL. In a two-party world where all the operations are on the provider, the participant property is not necessary since the two parties are implicit in the process as service requester and service provider. When mapping to BPEL, the process represents the service provider and contains a partnerLink for the service requester, along with the corresponding partnerLinkType. Conditions: Conditions (pre/if/while/untilCondition) are widely used in the DAML-S ProcessModel, but are currently underspecified as noted in prior work on mapping DAML-S to executable code [9]. Although DRS Notation [13] has been proposed for representing them, it is not currently supported by the DAML-S condition class. To circumvent this when mapping to BPEL, a boolean variable with an opaque value is created to hold the condition. Evaluating the condition then corresponds to checking the variable’s value, using “bpws:getVariableData(’variableName’)”. ......

The under-specification of conditions in DAML-S is a key stumbling block to mapping to executable BPEL. Once conditions are fully defined in DAML-S, one may map them into corresponding XPath expressions. Preconditions and Effects: We choose not to map any DAML-S precondtions or effects to BPEL elements. A full discussion is presented in section 5.2. Data Flow/SameValues: The sameValues property in DAML-S either relates the inputs and outputs of a composite process to the inputs and outputs of its various component subprocesses, or relates a process’s inputs to its outputs or to parameters of other process components. For the latter case, we map to correlation in BPEL as discussed in section 5.3). For example, consider the following snippet from the CongoBuy example [13]

This results in the following mapping, starting with the WSDL snippet:

and the corresponding BPEL snippet:

... ... ...

4.1.2. Atomic Processes (APs) 1. An AP with inputs and outputs, grounded to a WSDL request-response operation maps to . 2. An AP with inputs, but no outputs, grounded to a WSDL one-way operation maps to . 3. An AP with outputs before the inputs, grounded to WSDL solicit-response operation, maps to . 4. An AP with outputs, but no inputs, grounded to a WSDL notification operation, maps to . 5. An AP with no outputs or inputs, with no corresponding WSDL operation, maps to . In the above mappings, the values of portType/Operation attributes in the activities are retrieved from the DAML-S Process Grounding; the values of variable/inputVariable/outputVariable are retrieved from the mapping of the process’s properties as presented in section 4.1.1. For cases 3 and 4, the portType/operation in the WSDL grounding cannot be used in the since invocation in BPEL cannot refer to the process’s own operations. One must therefore generate the definition of a mirror image of the operation for the invocation. Of the few currently available DAML-S examples, none ground processes to outbound WSDL operations. 4.1.3. Composite Processes A DAML-S Composite process is associated with a control construct and composed of composite or noncomposite subprocesses. Control constructs correspond to BPEL structured activities, with the subprocesses mapped recursively. The mapping of DAMLS controlConstructs is as follows: 1. Sequence to : Both place a sequential order on their components. 2. Split/Fork/Concurrent/Parallel to : The branches of Split are mapped to activities in a construct to be performed concurrently. Split in DAML-S does not specify waiting or synchronization; however, automatic synchronization is forced at the end of a BPEL . 3. Split + Join to : Split + Join requires concurrent execution of components with barrier synchronization, and is thus mapped to . The partial

Proceedings of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04) 0-7695-2095-2/04 $20.00 © 2004 IEEE

synchronization capability of Split + Join is not directly supported by the BPEL but may be done through a sophisticated combination of flows and links which is beyond the scope of this paper. 4. Unordered to : Unordered allows the process components to be executed in some unspecified order or concurrently, provided that all components execute and complete. The mapping is thus again to . 5. Choice to : Choice does not specify the source of the choice, neither does it always specify how many branches may be taken. In the common case of an exclusive choice whose branches are different atomic processes, it is natural to model the requestor as the source of the decision since the branch chosen is based on which operation the requestor calls. This simple case corresponds to a in BPEL. Note that in the mapping of atomic processes inside , the replaces the .

For other use cases of Choice, especially that of nested composite processes, refer to section 5.4. 6. If-Then-Else to

Note from section 4.1.1 that all conditions can now only be mapped to opaquely assigned boolean-typed variables. 7. Repeat-While to