Matchmaking for Business Processes based on Choreographies∗

Andreas Wombacher Peter Fankhauser Bendick MahlekoErich Neuhold

Fraunhofer Gesellschaft, Integrated Publication and Information Systems Institute,64293 Darmstadt, Germany

firstname.lastname@ipsi.fhg.de

Abstract

Web services have a potential to enhance B2B e-commerce over the Internet by allowing companies andorganizations to publish their business processes on ser-vice directories where potential trading partners canfind them. This can give rise to new business paradigmsbased on ad-hoc trading relations as companies, partic-ularly small to medium scale, can cheaply and flexiblyenter into fruitful contracts, e.g., through subcontract-ing from big companies by simply publishing their businessprocesses and the services they offer. More business pro-cess support by the web service infrastructure is howeverneeded before such a paradigm change can material-ize. A service for searching and matchmaking of businessprocesses does not yet exist in the current infrastruc-ture. We believe that such a service is needed and willenable companies and organizations to be able to estab-lish ad-hoc business relations without relying on manu-ally negotiated interorganizational workflows. This papergives a formal semantics to business process matchmak-ing based on finite state automata extended by logicalexpressions associated to states.

1. Introduction

Web services have a potential to enhance B2B e-commerce over the Internet by allowing companies andorganizations to publish their business processes on ser-vice directories where potential trading partners can dis-cover them. This can give rise to new business paradigmsbased on dynamic trading relations as companies, particu-larly small to medium scale, can cheaply and flexibly en-ter into fruitful contracts, e.g., through subcontracting from

∗ This work has been carried out in the framework of the IST-projecteBroker (Electronic Brokering Services for Open Trading Infrastruc-tures, IST /1999-11060).

big companies by simply publishing their business pro-cesses and the services they offer.

To date, loosely coupled business processes are quiterare. Either simple (stateless) web services are used or thebinding of web services is done statically. While statelessservices are not sufficient for implementing business pro-cesses, static binding of services does not use the full poten-tial of loosely coupled systems also known as service ori-ented architectures. Existing standards supporting broker-ing of web services are UDDI [4] and WS-Inspection[5].Both approaches are based on string comparisons, whichare used for searching in classification schemes or t-models(like WSDL). This is not sufficient for business processes,especially if there does not exist any pre-negotiated anduniquely named frame contracts published by standardiza-tion organizations as, for example, RosettaNet.

Other service based infrastructure face the same issue. Inparticular, within the ebXML framework business partnerscan express their business capabilities (including their busi-ness processes) using trading partner profiles (CPPs) with-out providing any means to match these.

This paper presents an approach to more precise servicediscovery using business process descriptions rather thanindividual messages. The next section illustrates limitationsof existing approaches to service discovery by way of sim-ple examples of compatible and incompatible business pro-cesses. Section 3 formalizes a more precise notion of busi-ness processes matching based on annotated deterministicfinite state automata. Section 4 discusses at which level theintroduced techniques can be deployed in existing servicedescription frameworks. Section 5 describes the implemen-tation details including the complexity of the algorithms.Section 6 summarizes related work, and finally, Section 7concludes and outlines future work.

2. Example

Figure 1 depicts two business processes involv-ing two trading parties: a vendorv and a customerc.

Nodes represent the states of a business process; theend states are identified by a double circle. Edges rep-resent state transitions, which are labeled with messagesdenoted asfrom#to#message name, wherefrom rep-resents the message sender,to represents the messagerecipient, andmessage name is the name of the mes-sage.

v#c#Delivery

c#v#PO

c#v#ccPay

c#v#PO

c#v#ccPay

v#c#Delivery

(a) (b)

c#v#invoicePay

Start Start

Figure 1. (a) Vendor Message Sequence. (b) Cus-tomer Message Sequence.

Figure 1(a) shows the vendor business process, wherethe vendor expects to receive a purchase order (c#v#PO)message, followed by a credit card payment (c#v#ccPay)and finally sends back a delivery (v#c#Delivery) mes-sage to the respective customer. The customer process de-picted in Figure 1(b) also initiates the process with a pur-chase order request (c#v#PO). But then it insists ondelivery (v#c#Delivery) before payment by credit card(c#v#ccPay) or by invoice (c#v#invoicePay).

At the level of individual messages these two businessprocesses match. However, because they require a differ-ent order of payment and delivery, they are incompatible,that is, they can not successfully interact. In order to avoidmatching incompatible business processes we thus need totake into account message sequences rather than individualmessages.

Figure 2(a) shows a purchase order business pro-cess provided by a vendor. The process starts with apurchase order (c#v#PO) message, followed by a de-livery (v#c#Delivery) message, and either a creditcard payment (c#v#ccPay) or an invoice payment(c#v#invoicePay) message. In case the ordered prod-uct is not on stock, the vendor may reject a purchase orderby sending a no stock available (v#c#noStock) mes-sage. The vendor process involves two kinds of messages:mandatory and optional ones. On the one hand, it in-sists on the availability of both, thev#c#noStock and thev#c#Delivery message (two mandatory messages) rep-resented as an annotated logical expression. On the other

hand, it supports the two payment options as genuine al-ternatives (optional messages) not requiring any furtherannotation, because this is intended to be standard au-tomata semantics.

c#v#ccPay

c#v#PO

v#c#Delivery

(a)

c#v#invoicePay

v#c#noStock

c#v#PO

c#v#ccPay

v#c#Delivery

v #

c # n

o S

t o c k

(c)

c#v#PO

c#v#ccPay

v#c#Delivery

(b)

c#v#invoicePay

Start Start Start

(v#c#Delivery AND

v#c#noStock)

Figure 2. (a) Vendor Message Sequence insistingon v#c#noStock and v#c#Delivery Messages. (b)Customer Message Sequence. (c) Customer Mes-sage Sequence with optional v#c#noStock Mes-sage.

Figure 2(b)1 depicts a customer business process. Whilethis process matches the vendor process with respect tothe delivery payment order, it can not handle the requiredv#c#noStock message. Therefore, the two business pro-cesses can not reach the end state, if an ordered product isnot on stock.

Conversely, the business process in Figure 2(c) supportsv#c#noStock andv#c#Delivery messages, whereas itsupports only one payment option. This process now satis-fies all conjunctive (mandatory messages) and disjunctive(optional messages) choices of the vendor process. Thus,the vendor process and the customer process are compati-ble that is guarantee a successful business interaction.

In summary, the two examples in Figure 1 and 2 illus-trate that (1) message sequence and (2) conjunctive choicesneed to be taken into account to determine the compatibil-ity of business processes.

3. Approach

Finite state automata [21] constitute a suitable startingpoint to model business processes for the purpose of match-making. Where matchmaking is based on non-empty inter-section of finite state automata. They can represent (pos-sibly infinite) sets of message sequences without consid-ering branching conditions and parallel execution capabil-ities as provided by more expressive approaches such as

1 This process is equivalent to the one depicted in Figure 1(b) and de-scribed above.

2

Petri Nets. While Petri Nets are also closed under inter-section [33], they require a much higher computational andspace complexity compared to finite state automata. In par-ticular, Petri Nets allowing concurrent execution are non-polynomial for reachability and liveness problems [14]. Ifthe Petri Net class is limited to bounded2 nets several poly-nomial results exist. In case of bounded nets the reachabilitygraph can be represented as a finite state automata with highcomplexity, but finite. Thus does not exceed the expressive-ness of finite state automata. There exist approaches [30]addressing matchmaking using some sort of state machineshaving the same expressiveness as finite state automata [33].An in depth investigation of the necessary expressiveness ofthe language required by real business processes and the im-plication on the general computability will be addressed infuture work. So far, the proposed approach will rely on de-terministic finite state automata.

3.1. Deterministic Finite State Automaton

Deterministic Finite State Automata (DFA) are wellstudied. Formally, deterministic finite state automata can berepresented as follows:

Definition 1 (Deterministic Finite State Automata (DFA))A deterministic finite state automaton A is represented as atupleA = (Q, Σ, δ, q0, F ) where :

• Q is a finite set of states,

• Σ ⊆ P × P ×M is a finite set of messages inM sentby a sender inP to a receiver inP , where P representsthe parties being involved,

• δ : Q× Σ → Q represents labeled transitions,

• q0 a start state withq0 ∈ Q, and

• F ⊆ Q a set of final states.

The only difference to the standard definition of DFAs[21] is that the alphabethΣ consists of triples rather than ofatomic tokens. However, for the purpose of matchmakingbusiness processes, these triples can be treated like atomictokens: Two message triples are equal, if their sender, theirreceiver, and the message (with its parameters) are equal.

A DFA A generates a languageL(A) which enumer-ates the (possibly infinite) set of all message sequences sup-ported by a business process. Two DFAs match, if their lan-guages have a non-empty intersection. The intersection oftwo DFAs is again a DFA, which can be determined withthe usual cross product construction [21] :

Definition 2 (Intersection of two DFAs)The intersectionA1 ∩A2 of two automataA1 = (Q1,Σ1, δ1, q10, F1), andA2 = (Q2,Σ2, δ2, q20, F2)

2 A net is bounded if it is has a finite set of possible markings.

is A = (Q, Σ, δ, q0, F ), with Q = Q1 ×Q2,Σ = Σ1 ∩ Σ2, δ((q11, q21), α) = (q12, q22) withδ1(q11, α) = q12 ∧ δ2(q21, α) = q22, q0 = (q10, q20), andF = F1 × F2.

If the resulting automaton does not contain at least onepath (possibly of zero length) between the start state andan end state, its language is the empty language∅. In thiscase, the business processes modeled by the DFAs are in-compatible, because they do not share a common messagesequence.

An emptiness algorithm like in [21] is based on thereachability of states within an automaton starting from thestart stateq0. The automaton accepts an empty language, ifand only if no final state is within the set of reachable states.

A functional definition of an emptiness test is based ona recursive reachability function, wherecurP representsthe current path of the recursion andqi represents the cur-rent state. The function terminates, if a final state has beenreached (first line of definition) or no further non-cyclictransition is available (third line). The function traverses theautomaton in a deep-first manner (second line) seeking forat least one path to a final state. An automaton is empty ifno final state is reachable. A formal definition is given be-low:

Empt(curP, qi) := ¬Reach(curP, qi)

Reach(curP, qi) :=

true ifqi ∈ F∨{ql|δ(qi,l)=ql}

Reach(curP.qi, ql)

ifqi /∈ F ∧ ql /∈ curPfalse otherwise

The standard automaton intersection of the vendor pro-cess in Figure 2(a) and the customer process in Figure 2(b)is equivalent to the customer process. Although this inter-section is not empty, it does not contain the required transi-tion v#c#noStock of the vendor process. The reason forthis false match is that standard DFAs can not distinguishbetween mandatory and optional messages. Usually, a mes-sage in a standard DFA is regarded as an optional one. How-ever, the intended meaning of the vendor process requiresboth, mandatory and optional messages. It is not possible torepresent this semantics in message sequences or DFA di-rectly. Thus, an annotation containing this additional metainformation is required relevant only for matchmaking pur-poses.

3.2. annotated DFA

Based on the above observation, annotated DFA are in-troduced as a standard DFA, where each state might be as-signed a propositional logical term.

3

Definition 3 (annotated DFA (aDFA))An annotated DFA A is represented as a tupleA = (Q, Σ, δ, q0, F,QA) where

• Q is a finite set of states,

• Σ ⊆ P × P ×M is a finite set of messages inM sentby a sender inP to a receiver inP , where P representsthe parties being involved,

• δ : Q× Σ → Q represents transitions,

• q0 a start state withq0 ∈ Q,

• F ⊆ Q a set of final states, and

• QA : Q × E is a finite relation of states and logicalterms within the setE of propositional logic terms.

The terms inE are standard Boolean formulas. Adaptingthe definition in [10]:

Definition 4 definition of termsThe syntax of the supported logical formulas is given as fol-lows:

• the constantstrue andfalse are formulas,

• the variablesv ∈ Σ are formulas,

• if φ is a formula, so is¬φ,

• if φ andψ are formulas, so isφ ∧ ψ andφ ∨ ψ.

The standard semantics of automata is an optional ex-ecution of transitions. This is observable also in the func-tional emptiness test definition given above: a single pathto a final state returns atrue causing the whole disjunctionto returntrue in the reachability function. Thus, the logi-cal mapping of automata to annotated automata is an anno-tation containing a disjunctive expression including all tran-sition labels as depicted in Figure 3. For simplicity reasons,the OR annotations are neglected in the following.

(a)

A B

(b)

A or B

A B

Figure 3. (a) automata (b) annotated automataequivalent to a).

The definition of terms does not enforce a term to con-tain all labels of outgoing transitions of the associated state.Thus, annotations may be incomplete that is not containingall outgoing transition labels. Such incomplete annotationscan be completed by extending them with a disjunction of

all labels not contained yet. This method is best explained,if the expression is in disjunctive normal form as depictedin Figure 4a). The annotation means that the matching pro-cess must support messageB in combination with eithermessageA or C. MessageD is unrelated to messagesA,B, andC, thus represents an independent alternative,whichis combined with the existing term by a disjunction as de-picted in Figure 4b).

(a)

(A and B) or (B and C)

A B C

D

(b)

(A and B) or (B and C) or D

A B C

D

Figure 4. (a) incomplete annotated automata (b)completely annotated automata equivalent to a).

Extending terms of annotated automata is quite impor-tant for defining the emptiness test later on. The set of vari-ablesXqi corresponding to stateqi is defined as the set ofoutgoing transition labels of stateqi. Formally expressed as:

Xqi := {xqi | ∃q′ ∈ Q.δ(qi, xqi) = q′}

Similar to standard Boolean logic definitionsV ar is theset of all variables bound in a termtqi associated to a stateqi with (qi, t

qi) ∈ QA. Be aware, that the formula

V ar(tqi) ⊆ Xqi

is not necessarily true. There might exist variables in aterm associated to a stateqi without a counterpart in outgo-ing transition labels. A counter example is depicted in Fig-ure 5a) and explained in the intersection subsection later on.

As stated above, a termtqi might be incomplete, that is

Xqi\V ar(tqi) 6= ∅

and must be extended. The completed termt̃qi is definedas a disjunction of the annotated termtqi associated to stateqi and all outgoing transition labels not used in the termtqi

so far. A formal definition is given below:

t̃qi := tqi ∨ ( ∨

x∈Xqi\V ar(tqi )

x)

3.3. Intersection of aDFA

Matchmaking business processes has been defined as anon-empty intersection. The intersection automaton of two

4

automata contains the language accepted by both automata.Therefore, the annotation of the result automaton must sup-port the annotation of the first AND the annotation of thesecond automaton. The intersection definition is given be-low:

Definition 5 (Intersection of two aDFAs)The intersectionA1 ∩A2 of two annotated automataA1 = (Q1,Σ1, δ1, q10, F1, QA1), andA2 = (Q2,Σ2, δ2, q20, F2, QA2) isA = (Q, Σ, δ, q0, F,QA), with Q = Q1 ×Q2,Σ = Σ1 ∩ Σ2, δ((q11, q21), α) = (q12, q22) withδ1(q11, α) = q12 ∧ δ2(q21, α) = q22, q0 = (q10, q20),F = F1 × F2, and

QA =⋃

q1 ∈ Q1,q2 ∈ Q2

((q1, q2), e1 ∧ e2)if(q1, e1) ∈ QA1, (q2, e2) ∈ QA2

((q1, q2), e1)if(q1, e1) ∈ QA1, q2 ∈ Q2,6 ∃e′.(q2, e

′) ∈ QA2

((q1, q2), e2)if(q2, e2) ∈ QA2, q1 ∈ Q1,6 ∃e′.(q1, e

′) ∈ QA1

∅ otherwise

The intersection definition above is a slight extension ofstandard automaton intersection definition. In particular, theannotations are maintained independently of the automatonstructure itself. The evaluation of the resulting annotated au-tomaton with regard to matchmaking is done in the empti-ness test.

To illustrate this definition the example in section 2 is re-considered. The minimized intersection automaton of thevendor and customer process in Figure 2(a) and (b) is de-picted in Figure 5(a). The resulting automaton is the stan-dard automaton intersection plus the corresponding anno-tation. The annotation requires ano Stock message, al-though the automaton structure does not provide this tran-sition. Figure 5(b) depicts the intersection automaton of thevendor and the customer process given in Figure 2(a) and(c). The resulting automaton contains both required mes-sages:Delivery andno Stock.

3.4. Emptiness test of annotated DFA

So far, state annotations have been maintained, but notyet been evaluated. Within the emptiness test the annotatedterms are now evaluated. The evaluation of annotated termsis done in accordance to standard logical interpretation ase.g. defined in [10] where an interpretation is based on a val-uationν of variables. While a variable is evaluated astrueif and only if the target state of the transition labeled withthe variable name can reach a final state. Thus, the word as-sociated with the current state concatenated with the vari-

c#v#PO

c#v#ccPay

v#c#Delivery

v #

c # n

o S

t o c k

(b)

c#v#PO

c#v#ccPay

v#c#Delivery

(a)

c#v#invoicePay

Start Start

(v#c#Delivery AND

v#c#noStock) (v#c#Delivery AND

v#c#noStock)

Figure 5. (a) Intersection of vendor and customerprocess with missing no Stock message. (b) In-tersection of vendor and customer process withno Stock message.

able name is a prefix of at least one word accepted by thelanguage of the automaton.

Based on this definition of truth of the annotated termsit is required to first determine whether the target state ofoutgoing transitions of a state can reach a final state be-fore evaluating the annotated term. This may result in cyclicdependencies, like for example observable in a self-loop.Where the truth value of a state can not be determined, be-cause the result depends on its own (not yet defined) truthvalue. This issue can be resolved by using a three-valuedlogic providing the standard truth valuestrue andfalse,and in addition a valueindeterminate used in case of re-cursion. This issue is well known from primitive recursivefunction theory. The formal definition of the emptiness testis based on the Kleene’s system of ”strong connectives”[31]. 3 The corresponding operations of the three valuedlogic are negation¬3, disjunction∨3, and conjunction∧3.The corresponding truth tables are given below for com-pleteness.

¬3

f tt fi i

∨3 f t if f t it t t ti i t i

∧3 f t if f f ft f t ii f i i

The standard interpretation‖.‖ of the logic is based onthe operations defined above, but must consider the currentpathcurP of the evaluation to enable circle detection. Thecharacterst, t1, t2, andc, andx represent terms, constant,and variable symbols respectively.

‖¬t‖νcurP := ¬3‖t‖ν

curP

‖t1 ∨ t2‖νcurP := ‖t1‖ν

curP ∨3 ‖t2‖νcurP

‖t1 ∧ t2‖νcurP := ‖t1‖ν

curP ∧3 ‖t2‖νcurP

‖true‖νcurP := t; ‖false‖ν

curP := f‖x‖ν

curP := vI with vI ∈ {t, f, i}; x ∈ Σ

3 The special definition of implications of this system is not required inthe presented approach.

5

As stated above, the truth value of variables are derivedby checking whether there exists a path to a final state start-ing from the current pathcurP extended by the current stateqi and following the transition labeled with the name of thevariablexqi

j . The valueintermediate i is returned if thetransition labeledxqi

j has a target state contained in the cur-rent pathcurP concatenated with the current stateqi. Thisis, because the evaluation of the variablexqi

j dependents onits own evaluation. In case the target state of the transitionlabeledxqi

j is not contained in the current path nor in thecurrent stateqi, the evaluation ofxqi

j is done by a functioncalled reachR() checking the reachability of a final state.The function is quite similar to theReach() function givenabove and is defined in more detail later on. In case no tran-sition labeled withxqi

j exists the evaluation isfalse f . Theformal definition of the valuation of variables is given be-low:

‖xqi

j ‖νcurP :=

i ifδ(qi, xqi

j ) ∈ curP.qi

R(curP.qi, q′) ifδ(qi, x

qi

j ) /∈ curP.qi

f otherwise

Based on this valuation definition emptiness in anno-tated automata denoted asEmpt′() is false iff the modi-fied reachability functionR() returns truth valuet. Empti-ness is defined by a comparison to ensure a Boolean resultrather than a three-value logical result.

Empt′(curP, qi) := R(curP, qi) 6= t

R(curP, qi) :={

t ifqi ∈ F‖t̃qi‖ν

curP otherwise

The reachability functionReach′() terminates withtruet if the current stateqi is a final state. If the current stateqi

is not a final state the completed annotation must be valu-ated.

3.5. Consistency of Annotations

In subsection 3.2 the extension of annotations has beenintroduced. In the following it is discussed whether thisproperty is also valid with intersection and emptiness test.That is the intersection result of two completely annotatedautomata is equivalent to the intersection automata of thesame two automata structures but with incomplete annota-tions. The discussion focus on a single state, because theannotations are assigned to a particular state. LetA1 andA2 be two annotated automata with annotationst1 and t2respectively. Further, automatonAi has additional transi-tions/variablesXi\V ar(ti) with i ∈ {1, 2}. An exem-plary case is depicted in Figure 6, where a) representsthe incompletely annotated automata and the resulting in-tersection, and b) the corresponding one with completelyannotated automata. The termt1 uses variables A and B(V ar(t1) = {A,B}), while termt2 uses variables A,B,C

and E (V ar(t2) = {A,B,C, E}). The aim is to show thatthe resulting automata in a) and b) are always equivalentwith regard to annotation.

(a)

t 1

A B C D

F

t 2

A B C E

F

t 1 and t

2

A B C F

=

(b)

t 1 or C or D

or F

A B C D

F

t 2 or F

A B C E

F

(t 1 or C or D or F) and (t

2 or F)

A

B

C F =

Var(t 1 ) = {A, B} Var(t

2 ) = {A, B, C, E}

Var(t 1 ) = {A, B} Var(t

2 ) = {A, B, C, E}

B

Figure 6. (a) automata with incomplete annota-tion (b) completely annotated automata equivalentto a).

In particular, it must be shown that the completed exten-sion of the result state in case a) is equivalent to the annota-tion in b). That is

(t1 ∧ t2) ∨ F ≡ (t1 ∨ C ∨D ∨ F ) ∧ (t2 ∨ F )

Taking the right hand side of the formula and applyingdeMorgan rules results in a disjunction of pairwise conjunc-tions as denoted below.

(t1 ∧ t2) ∨ (t1 ∧ F ) ∨ (C ∧ t2) ∨ (C ∧ F )∨(D ∧ t2) ∨ (D ∧ F ) ∨ (F ∧ t2) ∨ (F ∧ F )

The following generic cases may occur:

• a variablex might be inX1\V ar(t1) and neither intermt2 nor inX2\V ar(t2): (like variableD in the ex-ample) in this case automatonA2 in the particular statedoes not have a transition labeledx thus, the intersec-tion also does not contain this transition andx evalu-ates tofalse by definition of evaluation. This meansall conjunctions containingx evaluate tofalse.

• a variablex might be inV ar(t1) and neither in termt2 nor in X2\V ar(t2): (like variable E in the exam-ple) based on the argumentation above, this variablealso evaluates tofalse although the termt1 itself re-mains unchanged.

• a variable x might be in X1\V ar(t1) and inX2\V ar(t2): (like variableF in the example) in thiscase the transition labeledx exists and can be evalu-ated regularly.

6

• a variablex might be inX1\V ar(t1) and inV ar(t2):(like variableC in the example) ifx evaluates totruenothing changes; ifx evaluates tofalse also the par-tial expression in termt2 evaluates tofalse, thust2 be-comestrue only if there exist further variables, whichare either int1 or in X1\V ar(t1) and different fromx.So, the conjunctionx∧ t2 has no effect and can be ne-glected.

• a variablex might be inV ar(t1) and inV ar(t2): (likevariablesA,B in the example) no further action is re-quired; the conjunction remains unchanged

Applying these cases to the expression results in

(t1 ∧ t2) ∨ (t1 ∧ F ) ∨ (C ∧ F ) ∨ (F ∧ t2) ∨ F

The subexpression(t1 ∧ F ) ∨ (C ∧ F ) ∨ (F ∧ t2) ∨ Fis equivalent to F because the additionally introduced con-junctions have no effect. Thus, the expression can be re-duced to

(t1 ∧ t2) ∨ F

which is equivalent to the extended annotation in Figure6a). So, the consistency of annotation with intersection hasbeen illustrated. This property allows the user of annotatedDFAs to keep the annotations as small as possible.

4. Application to Service Definition Lan-guages

This section illustrates how the presented approach tomatchmaking for business processes is related and can beapplied to existing service definition languages. Servicesare typically described at three major levels: Messages, ab-stract processes, and execution processes.

(1) Message descriptions such as WSDL and EDIFACTdescribe the syntax and structure of messages. The Web Ser-vice Definition Language (WSDL) [11] uses XML Schemato describe the input and output of operations supported bya service. These operations can be associated to roles, whichcorrespond to sender and receiver of message descriptionsused in this paper. Thus, WSDL descriptions may be used asone concrete form to encode and match individual messagedescriptions. Alternatively, web based EDI like EDIFACT[13] can be used for this purpose. Such syntactic messagedescriptions can be matched by component wised compari-son. A more ambitious approach is addressed by DAML-Sprofiles [2]: these profiles describe messages by means ofontological concepts such that semantic reasoning can beused to more flexibly match messages.

(2) Abstract processes describe the sequences in whichmessages may be exchanged. There are several propos-als for specifying abstract processes, including WSCL,cpXML, the abstract part of BPEL, and ebXML BPSS.

WSCL [6] uses finite state automata to model abstract busi-ness processes. Conversation Policy XML (cpXML)[18, 19, 20] extends finite state automata with hierarchi-cal states, which encapsulate again a finite state automa-ton. BPEL [12] (synthesized from XLANG [35] and WSFL[27]) and ebXML BPSS [26] also allow for the specifi-cation of branching conditions as well as parallel recur-sive business processes, which can not be described byfinite state automata. Therefore, for the purpose of match-making, parallelism needs to be abstracted away, whichmay introduce false matches.

(3) Execution process description extend abstract pro-cess description with information necessary to execute abusiness process. This includes the binding of the abstractprocess to internal processes, constraints on message pa-rameters and on time. This additional information is usuallyconfidential and therefore not advertised publicly [9, 16].Nevertheless, especially constraints may be deployed forimproving the precision of matchmaking.

5. Implementation

The described annotated automata aDFA has been im-plemented in Java for evaluation purposes. The pack-age can freely be downloaded for non-commercial usageat http://www.ipsi.fhg.de/oasys/ipsi-pf It contains a sim-ple demo application parsing two aDFA from XMLfiles, calculating the intersection automaton, and check-ing emptiness of the result automaton. The main parts ofthis implementation are sketched below due to the limita-tion of space.

5.1. aDFA XML Schema

The aDFA XML Schema definition is strongly related tothe definition in section 3. Thus, the messages, states andtransitions are enumerated, while IDs are added for refer-encing e.g. a source state in a transition to a correspondingstate element in the state enumeration. To guarantee syntac-tical consistency of these references,keyandkeyref rulesare added to the XML Schema. In addition, uniqueness rulesare added for message and state names to guarantee the setproperty within the automaton definition respectively.

5.2. aDFA Algorithms

The implementation of aDFA algorithms is strongly re-lated to the one of standard automata. As stated in subsec-tion 3.3, the intersection algorithm is a slight extension ofthe standard one without influencing the overall complex-ity of the algorithm. While the emptiness test of aDFA dif-fers from standard automata algorithm. An algorithm is pre-

7

sented in pseudo code in addition to the functional definitionof the emptiness test described in subsection 3.4.

The symbols used in pseudo code are taken from the def-inition of aDFA as described in subsection 3.2. The algo-rithm contains a functionisEmptyreturningTRUEif the ac-cepted language is empty,FALSEotherwise. This functioncalls the recursive functionreachablereturning

• TRUE if from the current statec a final state can bereached,

• FALSEif starting from the current statec no path to afinal state exists,

• INTERMEDIATEotherwise

To reduce the number of recursions intermediate resultsare collected in an arrayV al containing a truth value asso-ciated to a state. The set of already visited states is main-tained in the variableV is. Thus,V is contains all index val-ues that can be applied to the arrayV al. The current pathis maintained in variableP , while the current state is rep-resented in variablec. The interpretation of an expressionin three value logic is a standard traversal of the operatortree of the expression and, thus, not presented here. Instead,the formalism introduced in subsection 3.4 is used accord-ingly, whileν = ν∪{(x → v3)}means extending the valu-ation by the assignment of a variable namex to a truth valuev3 of three valued logic.

1: isEmpty(){2: return¬ (reachable({}, {}, q0, {}) =);3: }4:5: reachable(V al, P, c, V is){6: if (c ∈ F ) returnTRUE;7: else{8: for all δ(c, label) = target{9: if (target ∈ P ∪ {c})10: ret =INTERMEDIATE;11: else if(target ∈ V is)12: ret =V al [target];13: else{14: ret = reachable(V al, P ∪ c, target, V is);15: V is = V is ∪ c;16: V al [target] = ret;17: }18: ν = ν ∪ {(label → ret)}19: }// end of for20: // evaluation of the partial results21: ret =FALSE;22: if ((c, expr) ∈ QA)23: ret = ‖expr‖ν

P ;24: if (ret = TRUE)25: returnTRUE;26: else

27: for(l ∈ V ar(expr))28: ν = ν \ {(l → TRUE),

(l → INTERMEDIATE),(l → FALSE)} ;

29: if (∃l.(l → TRUE) ∈ ν)30: returnTRUE;31: else if(ret = INTERMEDIATE∨

∃l.(l → INTERMEDIATE) ∈ ν)32: returnINTERMEDIATE;33: else returnFALSE;34: }35: }

The functionreachable terminates returning TRUE ifthe current state is a final state (line 6). Otherwise, the tran-sitions with source state being the current statec are iterated(line 8) to determine the truth value of all states targeted bytransitions starting from the current state and store it in thevaluationν (line 18). The corresponding truth value is IN-TERMEDIATE in case the target state is either the currentstatec or it is in the pathP (lines 9,10). Or, the truth valuecan be taken from the intermediate results stored in variableV al if the target state has already been visited (lines 11,12).Or, finally, the truth value has to be calculated by callingthe functionreachable recursively and storing the interme-diate results afterwards in variableV al (lines 14-16). Af-ter the valuation has been defined, the truth value associ-ated to the current state can be calculated by evaluating theexpression (lines 21-28). The return value of the functionis the disjunction (lines 29-33) of the expression evaluationand the remaining transitions not considered in the expres-sion (lines 27,28).

The complexity of this algorithm is the one of standardemptiness algorithm plus the complexity for evaluating ex-pressions. The complexity of expression evaluation is linearto the number of elements in the expression operation tree.Let’s assume as a worst case scenario the expression is pro-vided in conjunctive normal form. So, the number of leafnodes of the operation tree is2|Σ| thus the number of to-tal elements in the operation tree is2|Σ|+1− 1. Because ex-pressions are assigned to states, the overall worst case com-plexity of evaluating expressions is| Q | ∗(2|Σ|+1− 1). Webelieve that real business processes have quite limited anno-tations, although no empirical data regarding structure andcomplexity of realistic expressions exists to give a more ap-propriate average estimation of computational cost. Futurework will address this issue.

6. Related Work

Handling processes in inter-organizational cooperationsusually is based on the existence of a global predefinedworkflow split into different parts to be executed locally

8

[37, 17, 25]. Because these approaches are based on a globalworkflow definition, the local workflows are also knownand, thus, they do not require service discovery consideringmessage sequences. If a collaboration is established withouta global pre-defined workflow [15, 38, 23, 22], service dis-covery based on matchmaking message sequences comesinto place. Typically, matchmaking must get along with in-complete information [9, 16], because trading partners willnot publish their business critical information like the high-est price a customer is willing to pay within a negotiationor auction process. The creation of consistent global work-flow from local ones considering this limitation is an openresearch issue.

Other matchmaking approaches are based on seman-tic information [7, 28]. In [34] a language is introduceddescribing the functional aspects as well as the messagesand their parameters based on a domain specific ontology.DAML-S [3] uses workflow aspects as well as the func-tional semantic description of the service within the match-making. In contrast to model the complete service descrip-tion using semantic web technology, the web service offer-ing language (WSOL) provides additional semantic meta-information to increase precision of the service discovery.In particular, classes of services are modeled by specifyingfunctional constraints, QoS, simple access rights, price, andother constraints in addition to a WSDL description [36].An even more simplified approach [8, 24] uses a processontology to improve precision of key word based querying.The main draw back of semantic annotation is the neces-sity of a common ontology used for annotating and query-ing services. Unfortunately, no such ontology currently is inplace.

Logic based approaches addressing service discoveryare Web Service Request Language (WSRL) and ProductLifecycle Management PLMflow. WSRL [32, 1] addressesplanning of an orchestration and composition of servicesto fulfill user requirements. While WSRL performs ser-vice discovery on behalf of temporal and linear constraints,PLMflow [39] is based on rule inferencing using the spec-ified business rules rather than a fixed workflow. Thus,PLMflow is characterized as a rule-based non-deterministicworkflow engine aiming to establish cooperation based onlocal decidability of the trading partners of their involve-ment. These approaches are based on the fact that the localworkflow model/rules are provided to the trading partnersand do not consider the need of hiding business critical in-formation.

The approach presented in the paper is based on mod-eling message sequences derived from a local workflowmodel. As stated above, [30] presents a similar approach,but does not distinguish optional and required transitions. In[29] two e-Services are compatible if every possible trace inone service has got a compatible one in the second one. Un-

fortunately, the description of the compatibility check of thetraces is not described at all.

7. Summary and Future Work

This paper has introduced an approach to match businessprocess descriptions. By explicating message sequence andrequired messages such descriptions allow for more precisematches than current approaches limited to matching onlyindividual messages. Thereby, an implementation of the ex-tended finite state automata has been presented which canbe deployed as a service description language for more pre-cise service discovery.

Currently, the approach is used to implement a businessprocess repository supporting matchmaking and discoverybased on business process descriptions. Next steps are theevaluation of the expressiveness of the approach by investi-gating the mapping from process models like BPEL to an-notated deterministic finite state automata. Because the ex-pressiveness differs the correctness of the matchmaking willbe analyzed. In particular, the percentage of introduced falsematches. Finally, future work will investigate the applica-bility of bilateral matching for business processes to multi-lateral process matchmaking.

References

[1] M. Aiello, M. Papazoglou, J. Yang, M. Pistore, M. Carman,L. Serafini, and P. Traverso. A request language for web ser-vices based on planning and constraint satisfaction. InProc.of 3rd Int. Workshop, Technologies for E-Services (TES),LNCS 2444, pages 76–85. Springer, 2002.

[2] D.-S. C. A. Ankolekar, M. Burstein, J. R. Hobbs,O. Lassila, D. McDermott, D. Martin, S. A. McIlraith,S. Narayanan, M. Paolucci, T. Payne, and K. Sycara. Daml-s: Web service description for the semantic web, 2002.http://citeseer.nj.nec.com/ankolekar02damls.html.

[3] D.-S. C. Anupriya. DAML-S: Web serice description for thesemantic web, 2002.

[4] I. Ariba, I. Corporation, and M. Corporation. Univer-sal description, discovery and integration, September 2000.http://www.uddi.org/.

[5] K. Ballinger, P. Brittenham, A. Malhotra, W. A. Nagy,and S. Pharies. Specification: Web services in-spection language (ws-inspection) 1.0, November2001. http://www.ibm.com/developerworks/library/ws-wsilspec.html.

[6] A. Banerji, C. Bartolini, D. Beringer, V. Chopella, K. Govin-darajan, A. Karp, H. Kuno, M. Lemon, G. Pogossiants,S. Sharma, and S. Williams. Web services conver-sation language (WSCL) 1.0 W3C note, March 2002.http://www.w3.org/TR/wscl10/.

[7] T. Berbers-Lee, J. Hendler, and O. Lassila. The semanticweb. Scientific America, 284(5):34–43, 2001.

[8] A. Bernstein and M. Klein. Discovering services: Towardshigh-precision service retrieval. InProc. of CAiSE Interna-tional Workshop, Web Services, E-Business, and the Seman-tic Web (WES), LNCS 2512, pages 260–275. Springer, 2002.

9

[9] F. Casati and A. Discenza. Modeling and managing inter-actions among business processes. Technical Report HPL-2000-159, Hewlett Packard Laboratories, Dec. 11 2000.

[10] J. Chomicki and G. Saake, editors.Logics for Database andInformation Systems. Kluwer, 1998.

[11] E. Christensen, F. Curbera, G. Meredith, and S. Weer-awarana. Web services description language (WSDL) 1.1W3C note, March 2001. http://www.w3.org/TR/wsdl.

[12] F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller,S. Thatte, and S. Weerawarana. Business process exe-cution language for web services, version 1.0, July 2002.http://www.ibm.com/developerworks/library/ws-bpel/.

[13] EDIFACT. United nations directories for electronic datainterchange for administration, commerce and transport.http://www.unece.org/trade/untdid/welcome.htm.

[14] J. Esparza and M. Nielsen. Decibility issues for Petri nets -a survey.Journal of Informatik Processing and Cybernetics,30(3):143–160, 1994.

[15] T. W. Finin, R. Fritzson, D. McKay, and R. McEntire. Kqmlas an agent communication language. InCIKM 1994, pages456–463, 1994.

[16] D. Georgakopoulos, H. Schuster, A. Cichocki, and D. Baker.Managing process and service fusion in virtual enterprises.Information Systems, 24(6):429–456, 1999.

[17] P. Grefen, K. Aberer, Y. Hoffner, and H. Ludwig. Crossflow:Cross-organizational workflow management in dynamic vir-tual enterprises.International Journal of Computer SystemsScience & Engineering, 15(5):277–290, Sep. 2000. CRLPublishing.

[18] J. E. Hanson. cpxml: Conversation policy xml version 1.0.http://www.research.ibm.com/convsupport/papers/index.html.

[19] J. E. Hanson, P. Nandi, and S. Kumaran. Conversation sup-port for business process integration. InProceedings 6thIEEE International Enterprise Distributed Object Comput-ing Conference (EDOC-2002), pages 65–74. IEEE Press,2002.

[20] J. E. Hanson, P. Nandi, and D. W. Levine. Conversation-enabled web services for agents and e-business. InProceed-ings of the International Conference on Internet Computing(IC-02), pages 791–796. CSREA Press, 2002.

[21] J. E. Hopcroft, R. Motwani, and J. D. Ullman.Introductionto Automata Theory, Languages, and Computation. AddisonWesley, 2001.

[22] E. Kafeza, D. K. W. Chiu, and I. Kafeza. View-based con-tracts in an e-service cross-organizational workflow environ-ment. In F. Casati, D. Georgakopoulos, and M. Shan, editors,TES 2001 LNCS 2193, pages 74–88. Springer, 2001.

[23] S. O. Kimbrough and S. A. Moore. On automated messageprocessing in electronic commerce and work support sys-tems: Speech act theory and expressive felicity.ACM Trans-actions on Information Systems, 15(4):321–367, 1997.

[24] M. Klein and A. Bernstein. Searching for services on the se-mantic web using process ontologies. InProc. of 1st Seman-tic Web Working Symposium (SWWS-1), Stanford, 2001.

[25] J. Klingemann, J. Wsch, and K. Aberer. Adaptive outsourc-ing in cross-organizational workflows. InProceedings of thethe 11th Conference on Advanced Information Systems En-gineering (Caise), Heidelberg, Germany, June 1999.

[26] P. Levine, J. Clark, C. Casanave, K. Kanaskie,B. Harvey, J. Clark, N. Smith, J. Yunker, andK. Riemer. Business process specification schema.www.ebxml.org/specs/ebBPSS.pdf.

[27] F. Leymann. Web services flow lan-guage (WSFL 1.0), May 2001. http://www-3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.

[28] S. McIlraith, T. Son, and H. Zeng. Semantic web ser-vices. IEEE Intelligent Systems (Special Issue on the Se-mantic Web), April 2001.

[29] M. Mecella, B. Pernici, and P. Craca. Compatibility of e-services in a cooperative multi-platform environment. InF. Casati, D. Georgakopoulos, and M. Shan, editors,TES2001 LNCS 2193, pages 44–57. Springer, 2001. Lecturenotes in Computer Science 2193.

[30] C. Molina-Jimenez, S. Shrivastava, E. Solaiman, andJ. Warne. Contract representation for run-time monitoringand enforcement. InProc. of Conf. on Electronic Commerce(CEC). IEEE, 2003.

[31] G. Panti. Multi-valued logics. In D. Gabbay and P. Smets,editors,Handbook of Defeasible Reasoning and UncertaintyManagement Systems, volume 1: Quantified Representationof Uncertainty and Imprecision, chapter 2, pages 25–74.Kluwer, Dordrecht, Oct. 1998.

[32] M. Papazoglou, M. Aiello, M. Pistore, and J. Yang. Planningfor requests against web services.Bulletin of the TechnicalCommitee on Data Engineering, 25(4):41–46, Dec 2002.

[33] J. L. Peterson.Petri Net Theory and the Modeling of Sys-tems. Prentice-Hall, 1981.

[34] K. P. Sycara, M. Klusch, S. Widoff, and J. Lu. Dynamic ser-vice matchmaking among agents in open information envi-ronments.SIGMOD Record, 28(1):47–53, 1999.

[35] S. Thatte. XLANG web services for business process de-sign.

[36] V. Tosic, K. Patel, and B. Pgurek. Wsol - web service offer-ing language. InProc. of CAiSE International Workshop,Web Services, E-Business, and the Semantic Web (WES),LNCS 2512, pages 57–67. Springer, 2002.

[37] W. van der Aalst and M. Weske. The P2P approach to in-terorganizational workflows. InProc. of 13. Int. Conf. on Ad-vanced Information Systems Engeneering (CAISE’01), Inter-laken, Switzerland, 2001.

[38] W. v.d. Aalst. Interorganizational workflows: An approachbased on message sequence charts and petri nets.SystemsAnalysis - Modelling - Simulation, 34(3):335–367, 1999.

[39] L. Zeng, D. Flaxer, H. Chang, and J.-J. Jeng. PLMflow - dy-namic business process composition and execution by ruleinference. InProc. of 3rd Int. Workshop, Technologies for E-Services (TES), LNCS 2444, pages 141–150. Springer, 2002.

10