Structural Matching of BPEL Processes - CiteSeerX

Structural Matching of BPEL Processes Rik Eshuis Paul Grefen Eindhoven University of Technology, Department of Technology Management P.O. Box 513, 5600 MB Eindhoven, The Netherlands {h.eshuis|p.w.p.j.grefen}@tue.nl Abstract

cess view to monitor and control the progress of service execution [16]. BPEL [2] is emerging as standard language for modelling behavioral aspects of services, i.e. their business protocols, and is therefore a good choice for representing such process views. To support this service integration approach, partners should be able to search for services exhibiting a certain desired behavior. The retrieved services need not match the service request exactly; for example, an organization may be willing to adjust its intended way of working if it finds a cheap service whose behavior differs slightly from the specified behavior. Thus, multiple services with different behaviors can be relevant for a certain request. Retrieved services should be ranked according to their degree of similarity with the service request. Matching behavioral aspects of services can be done in various ways. One approach is to match the behavior (for example state spaces) of different processes [19]. However, this requires a formal semantics, which is lacking for BPEL. Different formalizations have been proposed [12, 20], but it is unclear which one is intended by the informal BPEL standard. Another serious drawback of this approach is that due to parallelism, the state space can increase exponentially in the size of the process definition (called the state explosion problem). Thus, this approach is not scalable and only feasible for simple processes. Another way to support matching is to look at BPEL syntax only. However, drawback of such an approach is that different syntactic constructs typically mean the same. So two processes may not be matched even though they are equivalent. For example, BPEL allows sequential behavior to specified using sequence nodes or using links. As another example, any BPEL process is equivalent to the same process with an overarching sequence node added on top. Therefore, a more sophisticated, yet efficient approach for matching BPEL processes is needed. The goal of this paper is to define an efficient approach for matching BPEL processes that takes into account relevant behavioral interaction aspects of BPEL processes, but abstracts from irrelevant syntactic structures and from internal computational

BPEL has emerged as the industrial standard language for modelling behavioral aspects of web services. To support business partners in dynamically and flexibly binding their services together, different BPEL processes need to be efficiently matched. This paper identifies and defines various types of structural matching for BPEL processes. The matching definitions are based on heuristics: they take behavioral interaction aspects of the compared services into account, but abstract from irrelevant syntactical differences. Since the definitions are structural, they can be efficiently computed, and thus are useful to support dynamic and flexible binding of services. The approach is illustrated with an example from an existing business scenario.

1

Introduction

Web services [1] enable organizations to cooperate with each other in a dynamic and flexible way. Organizations can publish services they offer at public repositories, maintained by brokers. Potential business partners can search these repositories and contact the retrieved potential partners for doing business. This approach is supported by the publish-find-bind mechanism which is key part of any web service architecture. Currently, this collaboration approach is only supported for black-box services, i.e. services having input and output parameters and optional pre and post conditions [10, 22, 24, 27, 31]. Such black-box services do not provide any information on the internal operation of the service. WSDL [7], in combination with languages like OWL-S [25] and WSMO [28], has emerged as standard language for modelling black-box services. However, due to business trends like mass customization and end-to-end business optimization [13], services also need to expose some details of the internal process in a process view [6, 11, 15]. Service consumers can use the pro1

details. To this end, we map each BPEL process into a tree structure, the leaves of which are interactions with partner services, so either sending a message to invoke an operation of a partner service or receiving an invoke message for some provided operation. For each pair of leaves we compute their least common ancestor, which can be done in linear time [18]. The type of this ancestor specifies how the interactions specified at the leaves relate to each other. There are three types of relation: before, parallel, and exclusive. So an interaction can be before or after, in parallel, or exclusive to another interaction. This way, we derive for each process tree its process type: the set of relations between the interactions. Process types are purely structural but nevertheless they incorporate behavioral aspects. Next, we compare two BPEL processes by comparing their process types. Inspired by work on matchmaking black box services [21, 24, 31], we identify exact, plugin and relaxed matching types. Though our approach uses BPEL, process types apply to any process language whose behavior is tree-structured. In particular, the matching definitions can be used in the context of OWL-S [25]. This paper focuses on the process aspects of BPEL models, and is not concerned with matching (WSDL) operations that underly a BPEL process. For this paper, we simply use a name matching of operations. But actually any existing approach on matching WSDL operations, e.g. [10], can be used in combination with our approach. The remainder of this paper is organized as follows. Section 2 motivates the matching approach followed in this paper. Section 3 gives preliminaries for the matching definitions of the next section. First, it introduces BPEL, then it defines process trees as an abstraction of BPEL syntax, and finally it defines process types, which capture ordering relations between operations. We consider full BPEL, including loops and links. Section 4 first gives several matching definitions based on process types. The different definitions are needed for the different matching types identified in Section 2. Next, it applies the matching approach to a business scenario from a recently completed project on cross-organizational process integration in the automotive industry. Section 5 discusses related work. The paper ends with conclusions in Section 6.

2

taNet [29]. Does the process prescribed by the virtual network match the offered behavior of the organization? • An organization wants to outsource part of its business process to a provider. It does not need to synchronize with the outsourced part, but it does wish to monitor the progress at the provider site (glass box view [16]). Therefore, it is not interested in having an exact substitute provider process; a close match (in combination with a low price) is sufficient for a provider to get selected. • An organization wants to interact with a service provider, for example to arrange it logistics. Crosssynchronization between the main process and the service process is needed at several points (open box view [16]). To prevent deadlock, the provider process must be able to replace the desired requested process. However, an exact match is not needed; for example the provider may implement an extra quality check that the consumer can ignore. Based on these scenarios, we identify the following requirements on matchmaking: Relevance. Matchmaking should ignore irrelevant differences in syntax. An activity ordering relation can typically be specified in many different ways. For example, inside a BPEL flow activity sequence can be expressed with either sequence nodes or link constructs. Ideally, a matching definition identifies BPEL processes having the ordering constraints, even though the processes may use different syntax to express the actual orderings. Efficiency. Matching should be done efficiently. In many scenarios, matching is done on-the-fly. To guarantee a good performance for such scenarios, the matching procedure should be tractable, so there exists a polynomial algorithm implementing it. Unfortunately, many existing process matching procedures compare state spaces of processes [19]. Due to parallelism, the state space grows exponential in the size of the process model. Therefore, these matching approaches are non-tractable, and they can only be used when the processes are rather small or do not contain parallelism. Therefore, heuristics are needed to improve the efficiency. However, using heuristics may not give as high quality as an approach based on state space comparison. This tradeoff beween quality and efficiency is well known from other matchmaking approaches [31].

Motivation

Based on our experience in projects on crossorganizational process integration [14, 17] and existing literature on matching semantic web services [21, 24, 31], we list a few sample scenarios that motivate requirements on matching definitions:

Diversity. As illustrated by the scenarios, various kinds of matching are useful:

• An organization wants to join a virtual network having certain process standards, for example based on Roset2

• Exact matching is useful when the offered process should be equivalent to the requested process, as in the first scenario.

< t a r g e t linkName =” s h i p −t o−s c h e d u l i n g ” />

• Plugin matching is useful when the offered process is used as substitute for the requested process. Then the offered process inherits from the requested process. This matching type is useful for the third scenario. • Inexact matching is useful when the request only indicates the main features of the process flow and the requesting party accepts process flows that are not equivalent but do resemble the requested process. Inexact matching is useful for the second scenario, but also in cases when the service consumer is willing to adjust its own intended way of working. • Failure occurs when no inexact matching is possible, even though the two processes may share some activities. Then the processes do not match.

3

Preliminaries

First we introduce BPEL. Next, we define process trees as an abstraction of the BPEL syntax. Finally, based on process trees, we define process types, which capture ordering relations between operations.

3.1

Figure 1. BPEL snippet

BPEL branches of the form event/activity: the first event arriving triggers the corresponding activity. Links can be used to express synchronization dependencies inside a flow activity. A link from activity A to B means that B can only start if A has completed or has been skipped. To illustrate these concepts, Figure 1 shows a simplified snippet of BPEL code, adapted from an example of [2]. Parameters have been omitted.

A BPEL process model [2] specifies ordering constraints on interactions between a service and its partner services. An interaction is either invoking an operation at a partner process, receiving a request for invoking an operation, or replying to an earlier invocation request. These interactions occur along partner links, which relate ports of different partners to each other. Interactions are typically implemented as message exchanges between WSDL services [7]. More precisely, a BPEL process consists of activities, that are either basic or structured. Basic activities specify either the interaction between the process and its partner services or some atomic action (assign, wait) of the process. As explained in the introduction, we focus on interactions. An invoke activity calls an operation at some partner service by sending a message, a receive activity waits for an invocation message from a partner, and a reply activity returns the result of a synchronously invoked operation to the caller. A structured activity specifies ordering constraints on its child activities, which are either other structured activities or primitive activities. Structured activities include sequence, for specifying sequential execution, flow for concurrent execution, switch for conditional execution, while for structured loops, and pick, which specifies a set of

3.2

Process trees

Each BPEL process specifies a tree. Leaves of the tree are the basic activities while internal nodes correspond to structured activities. Formally, a process tree P is a tuple (A, N, children, type, mult, link, label) where • A is a set of basic activities. As we explained in the previous section, we focus on interaction activities. Therefore, A is partitioned into sets In, Rc, Rp where – In the set of invoke activities, – Rc the set of receive activities, – Rp the set of reply activities, 3

Non-interaction activities are abstracted into an internal (τ ) step (see the definition of label below).

the same parent that has type SEQ. We require that two different nodes with the same parent have different ranks, and that for a node n with l children, for any child c of n, rank(c) ∈ {0, . ., l − 1}. Using an overloading of notation, we write rank(n, i), where 0 ≤ i ≤ l − 1, to indicate the unique child c of n for which rank(c) = i. Since a BPEL process is structured as a tree, mapping a BPEL process to a process tree is straightforward. The only non-trivial translation concerns the pick construct, since it combines features of choice (switch) and receive. Therefore, pick translates into a XOR node with a set of BASIC child nodes labelled with receive activities. Figure 2 shows two sample process trees. The lined arrows indicate links. All nodes have multiplicity 1 (not shown). Figure 2(a) is the process tree for Figure 1.




• N is a set of nodes, N is a function that defines for each • children : N node its set of child nodes. For a leaf node, this set is empty. • type : N {BASIC, SEQ, AND, XOR} is a function that assigns to each node its type. A BASIC node is a leaf node, so it does not have any children. A SEQ node specifies sequential behavior, an AND node parallel behavior, and a XOR node exclusive behavior. • mult : N {1,∗ } specifies how many times each node and its subnodes is executed. Multiplicity * indicates a while-do loop. We require that each loop node has either more than one child node or is a BASIC node. If the BPEL process contains a compound loop node with one child, the loop can be “pushed down” to the child. By repeating this procedure, eventually either a BASIC node or a compound node with more than one child is reached.

3.3

Process types

The process type of a process tree specifies the behavioral relations between the interactions. To define process types, we will make use of some auxiliary functions on the syntax of process models. For a set X of nodes, the least common ancestor of X, denoted lca(X), is the node x such that x is ancestor of each node in X, and every other node y which is ancestor of each node in X is ancestor of x:

• link ⊆ N × N is the set of synchronization links. According to the BPEL specification [2], links must not cross the boundaries of loops and the link structure must not cause a cycle in the control flow relation.

• X ⊆ children∗ (x)

A∪{τ } is a function labeling a basic node • label : N with a basic activity or τ . The τ symbol is used to denote a basic non-interaction activity1 . To simplify the formalization of matching definitions, we require that different nodes have different labels, i.e. there are no duplicate labels. Most BPEL processes used in practice seem to satisfy this constraint. This constraint will be lifted in future work.

• For every y ∈ N such that X ⊆ children∗ (x), we have that x ∈ children∗ (y). Since nodes are arranged in a tree, every set of node has a unique least common ancestor. For example, in Fig. 2(a) the lca of Invoke Initiate Production Scheduling and Invoke Send Shipping Schedule is Sequence1 whereas the lca of Invoke Initiate Production Scheduling and Receive Shipping Schedule is Flow. Based on the notion of lca, we define some behavioral relations on nodes. Sequential behavior is specified using SEQ nodes and link constructs. SEQ nodes induce the