comparing workflow specification languages: a matter of...
TRANSCRIPT
Comparing Workflow Specification Languages:A Matter of Views∗
Serge Abiteboul Pierre Bourhis
INRIA Saclay, ENS Cachan & U. Paris Sud
Victor Vianu†
U.C. San Diego
ABSTRACT
We address the problem of comparing the expressivenessof workflow specification formalisms using a notion of viewof a workflow. Views allow to compare widely differentworkflow systems by mapping them to a common represen-tation capturing the observables relevant to the compari-son. Using this framework, we compare the expressivenessof several workflow specification mechanisms, including au-tomata, temporal constraints, and pre-and-post conditions,with XML and relational databases as underlying data mod-els. One surprising result shows the considerable power ofstatic constraints to simulate apparently much richer work-flow control mechanisms.
Categories and Subject Descriptors
H.2.3 [Database Management]: Data Manipulation Lan-guages; H.4.1 [Information Systems Applications]: Of-fice Automation—Workflow Management
1. INTRODUCTIONThere has recently been a proliferation of workflow spec-
ification languages, notably data-centric, in response to theneed to support increasingly ubiquitous processes centeredaround databases. Prominent examples include e-commercesystems, enterprise business processes, health-care and sci-entific workflows. Comparing workflow specification lan-guages is intrinsically difficult because of the diversity offormalisms and the lack of a standard yardstick for expres-
∗This work has been partially funded by the European Re-search Council under the European Community’s SeventhFramework Programme (FP7/2007-2013) / ERC grant Web-dam, agreement 226513. It also received partial supportfrom the Future and Emerging Technologies (FET) pro-gramme within the Seventh Framework Programme for Re-search of the European Commission, under the FET-Opengrant agreement FOX, number FP7-ICT-233599.†This author was supported in part by the NSF under awardIII-0916515.
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ICDT 2011, March 21–23, 2011, Uppsala, Sweden.Copyright 2011 ACM 978-1-4503-0529-7/11/0003 ...$10.00
siveness. In this paper, we develop a flexible frameworkfor comparing workflow specification languages, in whichthe pertinent aspects to be taken into account are definedby views. We use it to compare the expressiveness of sev-eral workflow specification mechanisms based on automata,pre/post conditions, and temporal constraints.
Consider a system that evolves in time as a result of inter-nal computations or interactions with the rest of the world.Fundamentally, a workflow specification imposes constraintson this evolution. There are numerous approaches for spec-ifying such constraints. Perhaps the most popular consistsof specifying a set of abstract states of the system and im-posing state transition constraints, in the spirit of a BPELprogram [13]. Another, more declarative approach is to de-fine a set of tasks equipped with pre/post conditions, such asIBM’s Business Artifact model (see Related Work). Artifactsystems may also impose constraints by temporal formulason the history of the run ([26]).
The richness and variety of these approaches renders theircomparison difficult. In particular, little is known of theirrelative expressive power. This is the main focus of thepresent paper.
We argue that a very useful approach for comparing work-flow specification languages is provided by the notion ofworkflow view. More broadly, the notion of view is essentialin the context of workflows, and the need to provide differ-ent views of workflows is pervasive. For example, views canbe used to explain a workflow or provide customized inter-faces for different classes of stakeholders, for convenience orprivacy considerations. The interaction of workflows, andcontractual obligations, are also conveniently specified byviews. The design of complex workflows naturally proceedsby refinement of abstracted views. Views can be used at run-time for surveillance, error detection, diagnosis, or to cap-ture continuous query subscriptions. The abstraction mech-anism provided by views is also essential in static analysisand verification.
Depending on the specific needs, a workflow view mightretain information about some abstract state of the systemand its evolution, about some particular events and theirsequencing, about the entire history of the system so far,or a combination of these and other aspects. Even if notmade explicit, a view is often the starting point in the de-sign of workflow specifications. This further motivates usingviews to bridge the gap between different specification lan-guages. To see how this might be done, consider a workflowW specified by tasks and pre/post conditions and anotherworkflowW ′ specified as a state-transition system, both per-
78
taining to the same application. One way to render the twoworkflows comparable is to define a view of W as a state-transition system compatible with W ′. This can be doneby defining states using queries on the current instance andstate transitions induced by the tasks. To make the com-parison meaningful, the view of W should retain in statesthe information relevant to the semantics of the application,restructured to make it compatible with the representationused inW ′. More generally, views may be used to map givenworkflows models to an entirely different model appropriatefor the comparison. We will formalize the general notionof view and introduce a form of bisimulation over views tocapture the fact that one workflow simulates another.
In our formal development, we mostly use the Active XMLmodel [1], which provides seamless integration of complexdata and processes. To describe system evolution (in theabsence of workflow constraints), we use a core model calledBasic Active XML (BAXML for short). BAXML documentsare abstractions of XML with embedded service calls. ABAXML document is a forest of unordered, unranked trees,whose internal nodes are labeled with tags from a finite al-phabet and whose leaves are labeled with tags, data values,or function symbols. The document evolves as a result offunction calls that initiate new sub-tasks, and returns of re-sults of function calls (using some local rewritings). Thefunctions can be internal or external, the latter modelinginteraction with the environment. For example, a BAXMLdocument is shown in Figure 1. Documents are subject tostatic constraints specified by a DTD and a Boolean com-bination of tree-patterns. Note that this already providessome form of control on the execution flow, since a functioncall can be activated, or its result returned, only if the result-ing instance does not violate the static constraints. Indeed,we will see that this already provides very powerful meansto enforce workflow constraints.
BAXML provides a very natural framework for specify-ing runs of systems in which tasks correspond to evolvingdocuments, and function calls are seen as requests to carryout sub-tasks. With the core model in place, we considerthree ways of augmenting BAXML with explicit workflowcontrol, corresponding to three important workflow specifi-cation paradigms:
Automata The automata are non-deterministic finite-statetransition systems, in which states have associated treepattern formulas with free variables acting as param-eters. A transition into a state can only occur if itsassociated formula is true. In addition, the automatonmay constrain the values of the parameters in consec-utive states.
Guards These are pre-conditions controlling the firing offunction calls and the return of their answers. Thiscontrol mechanism was introduced in [5], where theresults concern verification of temporal properties ofsuch systems.
Temporal properties These are expressed in a temporallogic with tree patterns and Past LTL operators. Atemporal formula constrains the next instance basedon the history of the run.
Although presented here in the context of BAXML, theseextensions capture the essential aspects of the three specifi-cation paradigms regardless of the specific underlying datamodel.
Our main results concern the relative power of BAXMLand its extensions as workflow specification languages. Whenwe insist that they generate exactly the same runs, the threeextensions turn out to be incomparable. More interestingly,we then consider a more permissive and realistic notion ofequivalence in which a view allows to hide portions of thedata and some of the functions, thus providing more leewayin simulating one workflow by another. Surprisingly, weshow that the core BAXML alone is largely capable to sim-ulate the three specification mechanisms based on guards,automata, and temporal properties. This indicates the con-siderable power of static constraints to simulate apparentlymuch richer workflow control mechanisms. Of course, spec-ifications using guards, automata, and temporal propertiesare typically much more readable than their equivalent spec-ifications in BAXML using hidden functions and static con-straints.
The above results show the usefulness of seeing a workflowabstractly as a constraint on the runs of an underlying sys-tem, decoupled from the specific approach for defining theconstraint. It also demonstrates the effectiveness of views incomparing workflows and worklow specification languages.Although the above languages are formalized in a specificActive XML context, we believe that the results demon-strate the wide applicability of the approach beyond thisparticular setting. In particular, the proofs provide generalinsight into when and how specifications based on automata,guards, and temporal constraints can simulate each other.
After settling the relative expressiveness of the languagesusing BAXML as a common core, we finally consider IBM’sbusiness artifact model, which uses a different paradigmbased on the relational model and services equipped withfirst-order pre/post conditions. Relying once again on theviews framework, we compare BAXML to the business ar-tifact model, as formalized in [16]. We prove that BAXMLcan simulate artifacts, but the converse is false. The firstresult uses views mapping XML to relations and functionsto services, so that artifacts become views of BAXML sys-tems. For the negative result we use views retaining justthe trace of function and service calls from the BAXMLand the artifact system. This is a powerful result, since itextends to any views exposing more information than thefunction/service traces. The latter results demonstrate onceagain the flexibility and power of the views approach to com-paring workflows.
Related work.Workflowmodeling and specification has traditionally been
process centric (e.g., [22, 39]). This has been captured in theworkflows community by flowcharts, Petri nets [40, 41, 7],and state charts [25, 32]. The comparison of such systemsusing the notion of bisimulation is considered in [31, 38].More recently, data-centric workflows have been consideredin [42], and in particular the artifact model of IBM [35]. Ver-ification for such models is considered in [23, 24, 11, 16, 21].The comparison of such systems is considered in [14] usingthe notion of dominance, which focuses on the input/outputpairs of the workflows. Other models in the same spirit in-clude the Vortex workflow framework [28, 18, 27], the OWL-S proposal [30, 29] as well as some work on semantic Webservices [33]. The article [17] (building on [37, 6]), consid-ers the verification of properties of data-centric workflowsspecified in LTL-FO, first-order logic extended with linear-
79
time temporal logic operators. Similar extensions have beenpreviously used in various contexts [19, 3, 37]. Apart fromthe work on verification of BAXML with guards mentionedabove [5], most other work on static analysis on XML (withdata values) deals with documents that do not evolve intime, e.g., [20, 10, 8]. This motivated studies of automataand logics on strings and trees over infinite alphabets [34,15, 12]. See [36] for a survey on related issues.
A survey on Active XML may be found in [1]. In [2],active XML documents are used to capture data and work-flow management activities in distributed settings, in thespirit of the artifact approach. The study of the interplaybetween queries and sequencing in the artifact approach wasthe driving motivation of the present work.
Organization.The paper is organized as follows. We introduce the view-
based framework for comparing workflow languages in Sec-tion 2. The BAXML model and the workflow languages arepresented in Sections 3 and 4. Their expressive power withrespect to different views is compared in Section 5. In Sec-tion 6 we compare BAXML with a variant of IBM’s businessartifacts, and show that BAXML can simulate artifacts, butthe converse is false. We end with brief conclusions. Due tospace limitations, most proofs are omitted.
2. VIEWS AND SIMULATIONSIn this section, we introduce an abstract framework for
workflows and views of workflows. We then use it to compareworkflows.
Workflow Systems and Languages
The model for workflows we consider is quite general. In-tuitively, a workflow system describes the tree of the possi-ble runs of a particular system. More formally, the nodesof a workflow system are labeled by states from an infiniteset Q∞ and the edges by events from an infinite set E∞
(Q∞ ∩ E∞ = ∅). For example, a state of a workflow sys-tem may be an instance of a relational database or an XMLdocument. It may also include various other relevant infor-mation such as the state of an automaton controlling theworkflow, or historical information such as the prefix of therun leading up to it. A typical event may consist of theactivation of a task, including its parameters. The presenceof data explains why the sets Q∞ and E∞ are taken to beinfinite.
The workflow systems we consider include two particu-lar events, namely block and ǫ, both in E∞, whose role weexplain briefly. First consider block. For uniformity, it isconvenient to assume that all runs are infinite. To this end,we use the distinguished event block to signal that the sys-tem has reached a terminal state that repeats forever (soonce a system blocks, it remains blocked).
On the other hand, the ǫ event corresponds to the classicalnotion of silent transition. Its meaning is best explainedin the context of a view (to be formally defined further),which defines the observable portion of states and events.In particular, it may hide information about states as wellas events in the source system. For a transition in the sourcesystem, if the event is (even partially) visible in the view orif the state of the view changes, the transition is observablein the view. On the other hand, it may be the case that both
the event and the state change are invisible in the view. So,although there has been a transition in the workflow system,nothing can be observed in the view. This is modeled by asilent transition, indicated by the special event ǫ. Observethat, unlike for blocking transitions, an ǫ transition may befollowed in the view by non-ǫ (visible) transitions, in whichthe state may change.
More formally:
Definition 1 (Workflow System). A workflow sys-tem is a tuple (N,n0, δ, q0, λN , λδ) where:
• (N,n0, δ) is a tree with root n0, nodes N , edges δ.
• all maximal paths from n0 are infinite.
• λN is a function from N to Q∞, and λN(n0) = q0.
• λδ is a function from δ to E∞.
• for each (n, n′) ∈ δ, if λδ((n, n′)) = ǫ then λN(n) =
λN(n′).
• for each (n, n′) ∈ δ, if λδ((n, n′)) = block then n′ is
the only child of n and λN (n) = λN (n′). Moreover, n′
has only one outgoing edge also labeled block.
The edges in δ are also called transitions of the workflow,and q0 is called its initial state.
Finally, a workflow language W consists of an infinite setof expressions, called workflow specifications. For example,BAXML, and its extensions with guards, automata, andtemporal constraints, are all workflow languages. Given aworkflow language W and W ∈ W, the semantics of W is aworkflow system (i.e., the tree of runs defined by W ) and isdenoted by [W ]W, or [W ] when W is understood.
Views of Workflow Systems
We next formalize the notion of view of a workflow system.We will argue that this is an essential unifying tool for un-derstanding diverse workflow models. In the present paper,we rely heavily on the notion of view in order to compareworkflows languages.
A view V is a mapping on Q∞ ∪E∞, such that V (Q∞) ⊆Q∞, V (E∞) ⊆ E∞, V (ǫ) = ǫ, and V (e) = block iff e =block. This mapping is extended to workflow systems asfollows. Let WS = (N,n0, δ, q0, λN , λδ) and V be a view.Then V (WS) is defined1 as (N,n0, δ, V (q0), λN ◦ V, λδ ◦ V ).We say that the view V is well-defined for WS if V (WS) isa workflow system.
Note that, by definition of the mapping, the propertiesof blocking transitions are automatically preserved. Notealso that, by definition of well-defined workflow system, foreach (n, n′) ∈ δ, if V (λδ((n, n
′))) = ǫ then V (λN(n)) =V (λN(n′)).
Simulation of Workflows
We next consider the comparison of workflow systems andworkflow languages based on the concept of view. We use avariant of bisimulation [31] (that we call w-bisimulation). Ofcourse, many other semantics for comparison are possible.We refrain from attempting a taxonomy of such semantics,and instead settle on one definition that is quite general andadequate for our purposes.
1Composition is applied left-to-right.
80
In our semantics, we wish to be able to capture silenttransitions as well as infinite branches of such transitions.Given a workflow system as above, for each e ∈ E − {ǫ},
we define the relatione→ on nodes by n
e→ m if there is a
sequence of transitions from n to m, all of which are silentexcept for the last one, which is labeled e.
Informally, the silent transitions are seen as partial inter-nal computation that do not have impact for the possibleobservable reachable events. The choices made during theinternal computation may be different, but the visible tran-sitions at the end of sequences of silent transitions are thesame.
Definition 2 (w-bisimulation). Let
WSi = (N i, ni0, δ
i, q0, λiN , λ
iδ)
i ∈ {1, 2}, be two workflow systems (with the same initialstate). A relation B from N1 to N2 is a w-bisimulation ofWS1 and WS2 if B(n1
0, n20) and for each n1, n2 such that
B(n1, n2) the following hold:
• λ1N (n1) = λ2
N(n2).
• For each event e 6= ǫ, if n1e→ n′
1 in WS1 then thereexists n′
2 such that n2e→ n′
2 in WS2 and B(n′1, n
′2),
and conversely.
• there is an infinite path of silent transitions from n1
in WS1 iff there is an infinite path of silent transitionsfrom n2 in WS2.
We denote by WS1 ∼ WS2 the fact that there exists a w-bisimulation of WS1 and WS2.
We note that there are well-known notions of bisimulationrelated to ours, such as weak-bisimulation and observation-congruence equivalence, motivated by distributed algebra[31]. These differ from w-bisimulation in their treatment ofsilent transitions. For example, infinite paths of silent tran-sitions are relevant to w-simulation but are ignored in weakbisimulation. It can be seen that observation-congruenceequivalence implies w-bisimulation, but weak bisimulationand w-bisimulation are incomparable.
Clearly, ∼ is an equivalence relation. Observe that viewspreserve w-bisimulation. More precisely, let WS1 ∼ WS2.Then for each view V ,
(*) V (WS1) is well-defined iff V (WS2) is well-defined, inwhich case V (WS1) ∼ V (WS2).
Equivalence of workflow systems as previously defined es-sentially requires the two systems to have the same set ofstates and events. However, in general we wish to compareworkflow systems whose states and events may be very dif-ferent. In order to make them comparable, we use viewsmapping the states and events of each system to a com-mon, possibly new set of states and events. Intuitively, theserepresent abstractions extracting the observable informationrelevant to the comparison. The views may also involvesubstantial restructuring, thus extending classical databaseviews.
Suppose we wish to compare languages W1 and W2. Tocompare workflow specifications in W1 and W2, we use setsof views V1 and V2 that map the states and events of W1
and W2 to a common set.
Definition 3 (Simulation). Let W1,W2 be workflowlanguages and V1,V2 be sets of views. The language W2
simulates W1 with respect to (V1,V2), denoted W1 →(V1,V2)
W2, if for each W1 ∈ W1 and V1 ∈ V1 such that V1(W1) iswell-defined, there exist W2 ∈ W2 and V2 ∈ V2 such V2(W2)is well-defined and V1(W1) ∼ V2(W2).
Remark 1. Note that the definition of simulation doesnot require effective construction of the simulating workflowspecification. However, all our positive simulation resultsare constructive. The negative result in Theorem 11 alsoconcerns effective simulation.
For sets of views V,V′, we define V ◦ V′ = {V ◦ V ′ | V ∈
V, V ′ ∈ V′}. Intuitively, a view V ◦ V ′ is coarser than V (or
equivalently, V is more refined than V ◦ V ′).The following key lemma is a straightforward consequence
of (*). It states that the relation → is stable under compo-sition of views.
Lemma 1 (Composition). Let W1 and W2 be work-flow languages and V1,V2 and V be sets of views. IfW1 →(V1,V2) W2 then W1 →(V1◦V,V2◦V) W2.
The Composition Lemma allows to relate simulations rel-ative to different classes of views. It says that simulationrelative to given views implies simulation relative to anycoarser views. This provides a tool for proving both posi-tive and negative simulation results.
A useful version of the above lemma is the following, com-bining composition and transitivity.
Lemma 2. Let W1,W2,W3 be workflow languages, andV1,V2,V3 and V be sets of views. If W1 →(V1,V2◦V) W2
and W2 →(V2,V3) W3, then W1 →(V1,V3◦V) W3.
As we will see, the version of transitivity provided bythe above is routinely used in proofs that combine multi-ple stages of simulation.
3. THE BASIC AXMLMODELIn this section we present BAXML, theBasic AXML model.
This is essentially a simplified version of the GAXML modelof [5], obtained by stripping it of the control provided bycall and return guards of functions (all such guards are setto true). We consider such control later as one of the work-flow specification mechanisms. The section may be skippedby readers familiar with the GAXML model. Due to spaceconstraints, and to limit duplication, the description is in-formal.
To illustrate our definitions, we use a simplified versionof the Mail Order example of [5]. The purpose of the MailOrder system is to fetch and process individual mail orders.The system accesses a catalog subtree providing the price foreach product. Each order follows a simple workflow wherebya customer is first billed, a payment is received and, if thepayment is in the right amount, the ordered product is de-livered.
In the model, trees are unranked and unordered. We as-sume given the following disjoint infinite sets: nodes N (de-noted n,m), tags Σ (denoted a, b, c, . . .), function names F,data values D (denoted α, β, . . .) data variables V (denotedX,Y, Z, . . .), possibly with subscripts.
81
For each function name f , we also use the symbols !fand ?f , called function symbols, and denote by F
! the set{!f | f ∈ F} and by F
? the set {?f | f ∈ F}. Intuitively,!f labels a node where a call to function f can be made(possible call), and ?f labels a node where a call to f hasbeen made and some result is expected (running call). Afterthe answer of a call at node x is returned, the call maybe kept or the node x may be deleted. If calls to !f arekept, f is called continuous, otherwise it is non-continuous.For example, the role of the MailOrder function in Figure 1is to indefinitely fetch new mail orders from customers, soMailOrder is specified to be continuous. On the other hand,the function !Bill occurring in a MailOrder is meant to becalled only once, in order to carry out the billing task. Oncethe task is finished, the call can be removed. Therefore, Billis specified to be non-continuous.
A BAXML document is a tree whose internal nodes arelabeled with tags in Σ and whose leaves are labeled by eithertags, function symbols, or data values. A BAXML forest isa set of BAXML trees. An example of BAXML documentis given in Figure 1.
To avoid repetitions of isomorphic sibling subtrees, we de-fine the notion of reduced tree. A tree is reduced if it containsno distinct isomorphic sibling subtrees without running calls?f . We henceforth assume that all trees considered are re-duced, unless stated otherwise. However, note that the for-est of an instance may generally contain multiple isomorphictrees.
Patterns. We use patterns as the basis for our query lan-guage, and later in the specification of workflow constraintsand temporal properties. A pattern is a forest of tree-patterns.A tree-pattern is a tree whose edges are labeled by child (/)or descendant (//), where, as in XPath, descendant is re-flexive. Nodes are labeled by tags if they are internal, andby tags, function symbols, or variables if they are leafs. Inaddition, nodes may be labeled by wildcard (*), which canmap to any tag. A constraint consisting of a Boolean com-bination of (in)equalities between the variables and/or dataconstants may also be given. In particular, we can specifyjoins (equality of data values). A tree-pattern is evaluatedover a tree in the straightforward way. The definition of theevaluation of patterns over forests extends the above in thenatural way. An example is given in Figure 2 (a). The pat-tern shown there expresses the fact that the value Order-Idis not a key. It does not hold on the BAXML document ofFigure 1. (Indeed, we want Order-Id to be a key).
We sometimes use patterns that are evaluated relative to aspecified node in the tree. More precisely, a relative patternis a pair (P , self ) where P is a pattern and self is a node ofP . A relative pattern (P , self ) is evaluated on a pair (F, n)where F is a forest and n is a node of F . Such a patternforces the node self in the pattern to be mapped to n. Figure2 (b) provides an example of relative pattern. The patternshown there checks that a product that has been orderedoccurs in the catalog. It holds in the BAXML document ofFigure 1 when evaluated at the unique node labeled !Bill.
We also consider Boolean combinations of (relative) pat-terns. The (relative) patterns are matched independently ofeach other and the Boolean operators have their standardmeaning. If a variable X occurs in two different patternsP and P ′ of the Boolean combination then it is treated asquantified existentially for P and independently quantifiedfor P ′.
It will be useful to occasionally consider parameterizedpatterns, in which some variables are designated as free. LetP (X) be a pattern with free variables X, and ν an assign-ment of data values to X. A BAXML forest I satisfies P (X)for assignment ν, denoted I, ν |= P (X), if I satisfies the pat-tern P (ν(X)) obtained by replacing each variable in X byits value under ν.
Main
MailOrder
Order-Id
X
Cname
Y
Pname
Z
MailOrder
Order-Id
X
Cname
Y’
Pname
Z’
Y 6= Y’ or Z 6= Z’
(a)
Main
Product
Pname
X
MailOrder
Pname
X
self
(b)
Figure 2: Two patterns
Queries. As previously mentioned, patterns are used inqueries, as shown next. A query is a finite union of rules ofthe form Body → Head , where Body and Head are patternsand Head contains no descendant edges and no constants,and all its variables occur in Body. In each tree of Head, allvariables occur under a designated constructor node, spec-ifying a form of nesting. When evaluated on a forest, thematchings of Body define a set of valuations of the variables.The answer for the rule is obtained by replacing, in each treeof Head, the subtree rooted at the constructor node with theforest obtained by instantiating the variables in the subtreewith all their matchings provided by the Body. The answerto the query is the union of the answers for each rule. Asfor patterns, we may consider queries evaluated relative to aspecified node in the input tree. A relative query is definedlike a query, except that the bodies of its rules are relativepatterns (P , self ). An example of relative query (with a sin-gle rule) is given in Figure 3. The label of the constructornode (indicated by brackets) is Process-bill.
Main
Catalog
Product
Pname
X
Price
Y
MailOrder
Pname
X
self: !Bill
{Process-bill}
Pname
X
Amount
Y
!Invoice
Figure 3: Example of a relative query
Consider the evaluation of the query of Figure 3 on theBAXML document of Figure 1 at the unique node labeled!Bill. There is a unique matching of the Body pattern andthe result is the Head pattern of the query with X replacedby Nikon and Y by 199 (without brackets for Process-
bill).
DTD. Trees used by a BAXML system may be constrainedusing DTDs and Boolean combinations of patterns. ForDTDs, we use a typing mechanism that restricts, for each
82
Main
Catalog
Product
Pname
Canon
Price
120
Product
Pname
Nikon
Price
199
Product
Pname
Sony
Price
175
!Mailorder MailOrder
Order-Id
1234567
Cname
Serge
Pname
Nikon
!Bill !Deliver !Reject
Figure 1: A BAXML document.
tag a ∈ Σ, the labels of children that a-nodes may have.As our trees are unordered we use Boolean combinations ofstatements of the form |b| ≥ k for b ∈ Σ ∪ F! ∪ F? ∪ {dom}and k a non-negative integer. Validity of trees and of forestsrelative to a DTD is defined in the standard way.
Schemas and instances. A BAXML schema S is a tuple(Φint,Φext,∆) where (i) the set Φint contains a finite setof internal function specifications, (ii) the set Φext containsa finite set of external function specifications, and (iii) ∆provides static constraints on instances of the schema. Itconsists of a DTD and a Boolean combination of patterns.For instance, the negation of the pattern in Figure 2 (b)states that Order-Id uniquely determines the mail order.
We next detail Φint and Φext. For each f ∈ F, let af be anew distinct label in Σ. Intuitively, af will be the root of asubtree where a call to f is being evaluated. (This subtreemay be seen as a task initiated by the function call.) Thespecification of a function f of Φint indicates whether f iscontinuous or not, provides its argument query (a relativequery), and return query (a query rooted at af ). When theargument query is evaluated, self binds to the node at whichthe call !f is made. The role of the argument query is todefine the argument of a call to f , which is also the initialstate of the task corresponding to f .
Example 1 We continue with our running example. Thefunction Bill used in Figure 1 is specified as follows. Itis internal and non-continuous. The argument query is thequery in Figure 3. Assuming that Invoice is an externalfunction eventually returning Payment (with product andamount paid) the return guard query of Bill is:
aBill
Payment
Pname
X
Amount
Y
−→ {Paid}
Pname
X
Amount
Y
Each function f in Φext is specified similarly, except thatthe return query is missing. In addition, a DTD ∆f con-strains the answers returned by f (the DTD assumes a vir-tual root under which the answer forest is placed). Intu-itively, an external call can return any answer satisfying ∆f
at any time, as long as the resulting instance also satisfiesthe global static constraints ∆. For example, MailOrder isexternal, since its role is to fetch orders from an externaluser.
An instance I over a BAXML schema S = (Φint,Φext,∆)is a pair (T, eval), where T is a BAXML forest and eval aninjective function over the set of nodes in T labeled with ?ffor some f ∈ Φint such that: (i) for each n with label ?f ,eval(n) is a tree in T with root label af (its workspace), and
(ii) every tree in T with root label af is eval(n) for some nlabeled ?f . An instance of S is valid if it satisfies ∆.
Runs. Let I = (T, eval) and I ′ = (T′, eval’) be instances ofa BAXML schema S = (Φint,Φext,∆). The instance I ′ is apossible next instance of I iff I ′ is obtained from I by makinga function call or by receiving the answer to an existing call.We refer to the latter as an event. More precisely, an eventis an expression of the form !f(F ) or ?f(F ), where f is afunction, and F is the forest consisting of the argument,resp. answer to the function call. For technical reasons,we also use two special events, init that only generates theinitial instance, and block, whose use will be clear shortly.We denote by I ⊢e I ′ the fact that I ′ is a possible nextinstance of I caused by event e.
We now provide more details. When a call to !f is madeat node n, the label of n is changed to ?f . If f is internal,we additionally add to the graph of eval the pair (n, T ′)where T ′ is a tree consisting of a root af connected to theforest that is the result of evaluating the argument queryof f on input (T, n). When an answer to call ?f at node nis received, the trees in the answer are added as siblings ofn, and n is deleted (if f is non-continuous) or its label isreset to !f (if f is continuous). If f is external, its answeris a forest satisfying ∆f . If f is internal, the answer canbe returned only if eval(n) contains no running calls ?g, inwhich case the answer consists of the result of evaluatingthe return query of f on eval(n), after which (n, eval(n)) isremoved from the graph of eval.
Figure 4 shows a possible next instance for the instanceof Figure 1 after an internal call has been made to !Bill.Recall the specification of Bill from Example 1. As !Billis an internal call, the subtree aBill contains the result ofthe query defining !Bill (see Figure 3). The dotted arrowindicates the function eval.
We will typically be interested in runs of such systems. Aninitial instance of schema S is an instance of S consisting ofa single tree whose root is not a function call and for whichthere is no running call. For runs, we use a variation of themodel of [5]. A prerun of a schema S is a finite sequence{(Ii, ei)}0≤i≤n, such that (i) for each i, Ii satisfies the staticconstraints ∆, (ii) e0 = init, and (iii) for each i > 0, Ii−1 ⊢ei
Ii. A run is an infinite sequence ρ = {(Ii, ei)}i≥0 such that:
nonblocking each finite prefix of ρ is a prerun of S, or
blocking there is a finite prefix (I0, e0), ..., (In, en) of ρ thatis a maximal prerun2 of S; and for each i > n, Ii = Inand ei = block.
2There is no (I ′, e′) for which (I0, e0), ..., (In, en)(I′, e′) is a
prerun of S.
83
Main
Catalog
· · ·
!Mailorder MailOrder
Order-Id
1234567
Cname
Serge
Pname
Nikon
?Bill !Deliver !Reject
aBill
Process-bill
Pname
Nikon
Amount
199
!Invoice
Figure 4: An instance with an eval link
Thus, we force all runs to be infinite by repeating forever ablocking instance from which no legal transition is possible,if such an instance is reached.
Semantics with and without aborts
We next discuss a subtle difference between the semanticsadopted here and that of [5]. According to our semantics, if aprerun reaches an instance from which every transition leadsto a violation of the static constraints, the prerun blocks for-ever in that instance, generating a blocking run. In contrast,the semantics of [5] allows blocking runs only if no transitionexists at all (whether leading to a valid instance or not). Ifthere are possible transitions but they all lead to constraintviolations, the prerun is discarded. Intuitively, this amountsto aborting the run. We refer to this as the semantics of runswith aborts, and to the one we follow in this paper as thesemantics of runs (without aborts). Note that in our seman-tics, every prerun is extensible to a (possibly blocking) run,whereas this is not the case in the semantics with aborts.Furthermore, as shown next, in the semantics with abortsit is undecidable if a given prerun can be extended to aninfinite run. This is a main motivation for our choice of thesemantics without aborts.
Theorem 2. Let S be a BAXML schema and ρ a prerunof S. Under the semantics with aborts, it is undecidablewhether ρ is the prefix of a run of S. Furthermore, thisremains undecidable even for nonrecursive3 DTDs.
The proof for arbitrary DTDs is trivial by the undecidabil-ity of satisfiability of static constraints. The proof for non-recursive DTDs is by reduction of the implication problemfor functional and inclusion dependencies (FDs and IDs),known to be undecidable (see [4]).
4. WORKFLOWCONSTRAINTSIn this section, we introduce three ways of enriching the
BAXML model with workflow constraints: (i) function calland return guards (yielding the GAXML model), (ii) anautomaton model, and (iii) temporal constraints. Each cor-responds to a very natural way of expressing constraints onthe evolution of a system. We study and compare thesemechanisms in the next sections.
We begin by considering an abstract notion of workflowconstraint. A workflow constraint W over a BAXML schemaS is a prefix-closed property of preruns of S. For a prerunρ of S, we denote by ρ |= W the fact that ρ satisfies W .We denote by S|W the workflow specification defined by Sconstrained by W . A run of S|W is an infinite sequenceρ = {(Ii, ei)}i≥0 such that:
3A DTD is recursive is there is a cycle in the graph that hasan edge from tag a to b if the DTD allows b to label a childof a node labeled a.
nonblocking each finite prefix of ρ is a prerun of S thatsatisfies W.
blocking there is a finite prefix (I0, e0), ..., (In, en) of ρ thatis a maximal prerun of S satisfying W ; and for eachi > n, Ii = In and ei = block.
Observe that nonblocking runs of S|W are particular non-blocking runs of S. Also, a sequence {(Ii, ei)}i≥0 may be ablocking run of S|W but not a blocking run of S. (This isbecause all transitions that are possible according to S areforbiddent by W .) The set of runs of S|W is denoted byruns(S|W ).
A main goal of the paper is to compare the descriptivepower of different formalisms for specifying workflow con-straints. To this end, we consider the workflow languagesG (for call guards), A (for automata), and T (for temporalformulas), defined next.
Call and return guards. Recall the Mail Order example,in which processing an order requires executing some tasksin a desired sequence (order, bill, pay, deliver). Since tasks inBAXML are initiated by function calls, one convenient work-flow specification mechanism is to attach guards to functioncalls. For instance, the guard of !Deliver, shown in Figure5, might require that the ordered product must have beenpaid in the correct amount. Similarly, it is useful to controlwhen the answer of an internal function may be returned.This can be done by providing return guards.
Let S be a BAXML schema. A guard assignment over Sis a pair γ = (γc, γr), where:
• γc, the call guard assignment, is a mapping from thefunctions of S to Boolean combinations of relative pat-terns over S. A call to f can only be activated if γc(f)holds.
• γr, the return guard assignment, is a mapping fromthe functions of S which is true for external functionsand a Boolean combination of tree patterns rooted ataf for each internal function f . The result of a callto f is returned only when γr(f) guard is satisfied onits current workspace. Return guards constrain onlyinternal functions.
A prerun ρ = (I0, e0), ..., (In, en) of S satisfies γ = (γc, γr),denoted ρ |= γ, if for each transition Ii−1 ⊢ei Ii, if the tran-sition results from a function call to !f at node u the guardγc(f) holds in (Ii−1, u), and if the transition results fromthe return of an internal function call ?f at node u, γr(f)holds in evali−1(u). Observe that these constraints involveconsecutive instances only.
The set of all guard workflow constraints is denoted G. AGAXML schema is an expression S|γ, for some γ ∈ G.
84
Example 3 Figure 5 shows call guards for some functionsin the Mail Order example. The call guard of function Bill
is given in Figure 2(b) (this checks that the ordered productis available). The call guard of Invoice is true. In the same
Main
Product
Pname
X
Price
Y
MailOrder
Paid
Pname
X
Amount
Y’
self
Y 6= Y’
γc(Reject)
Main
Product
Pname
X
Price
Y
MailOrder
Paid
Pname
X
Amount
Y
self
γc(Deliver)
Figure 5: Call guards of Reject and Deliver.
example, the return guard of function Bill is:
aBill
Payment
indicating that payment has been received, so billing is com-pleted.
Pattern automata. We next consider workflows based onautomata. The states of the automaton are defined usingpattern queries. The automaton has no final states, sinceBAXML (like AXML) does not have a built-in notion ofsuccessful computation.
A pattern automaton is a tuple (Q, qinit, δ,Υ) where:
• Q is a finite set of states, qinit ∈ Q, and each q ∈ Qhas an associated set of variables Xq;
• For each q, Υ(q) is a Boolean combination of parame-terized patterns whose set of free variables equals Xq ;
• the transition function δ is a partial function over Q×Q; for each q, q′, δ(q, q′) is a Boolean combination ofequalities of variables in Xq and Xq′ .
To simplify the presentation, we assume without loss ofgenerality that Xq and Xq′ have no variables in common.
LetA be the set of pattern automata. An AAXML schemais an expression S|A for a BAXML schema S and A ∈A. A prerun ρ = {(Ii, ei)}i≤n of S satisfies an automa-ton constraint A, denoted ρ |= A, if there exists a sequence{(qi, νi)}i≤n, where q0 = qinit and νi is a valuation of Xqi ,such that for each i ≤ n:
1. Ii, νi |= Υ(qi),
2. νi(Xqi) ∪ νi+1(Xqi+1) |= δ(qi, qi+1).
Intuitively, the state of such an automaton after readinga finite sequence ρ of instances is a pair (q, ν) where ν is avaluation of the variables in Xq. Note that the automaton
qinit p(x1) pe(x2)
d(x3) de(x4)
r(x5) re(x6)
x1 = x1
x1 = x2
x2 = x3
x2 = x5
x3 = x4
x5 = x6
Figure 6: Example of pattern automaton
is non-deterministic both with respect to the state and thevaluation of its variables.
An automaton for our running example is represented inFigure 6. The edges represent the pairs for which δ is de-fined, and the patterns in Υ check the following:
• Υ(qinit) checks nothing.
• Υ(p)(x1) checks that the call to Bill of the MailOrderof Order-Id x1 has been activated and the product isin the catalog. The calls to Deliver and to Reject arestill not activated.
• Υ(pe)(x2) checks that the call to Bill of the MailOrderof Order-Id x2 has returned a payment.
• Υ(d)(x3) checks that the call to Deliver of the MailOrderof Order-Id x3 is activated and the amount broughtby Bill is the same as the price of the item that hasbeen ordered.
• Υ(de)(x4) checks that the call to Deliver of the MailOrderof Order-Id x4 has been returned.
• Υ(r)(x5) checks that the call to Rejection of the MailOrderof Order-Id x5 is activated and the amount broughtby !Bill is different from the price of the item thathas been ordered.
• Υ(re)(x6) checks that the call to Rejection has beenreturned for the MailOrder of Order-Id x6.
We note that in some specification models, such as state-charts [25], states are defined in a hierarchical manner, i.e.entering a state may trigger a more refined state-transitionsub-system. Other systems further extend this with recur-sion [9]. Although not done here, one could extend ourformalism to capture such hierarchical or recursive states.
Past-Tree-LTL. Finally, we consider workflow constraintsspecified using temporal formulas. Intuitively, these state,given a particular history, whether a given transition is al-lowed. The language is a variant of Tree-LTL [5] using onlypast LTL operators, that we call Past-Tree-LTL. It is ob-tained from classical propositional LTL (e.g., see [19]) byinterpreting each proposition as a parameterized tree pat-tern P (X) where X is a subset of its variables, designated asglobal. All global variables are treated as free in the patternsand are quantified existentially at the end. The past tempo-ral operators are X−1 (previously) and S (since), with thestandard semantics. Specifically, X−1ϕ holds for a prerun(I0, e0) . . . , (In, en) if ϕ holds at (I0, e0) . . . , (In−1, en−1); ϕSψholds at (I0, e0) . . . , (In, en) if ψ holds in (I0, e0) . . . , (Ij , ej)
85
for some j ≤ n and ϕ holds in (I0, e0) . . . , (Ik, ek) for everyk, j < k ≤ n. In summary, a Past-Tree-LTL formula is ofthe form ∃Xψ(X) where ψ uses only the temporal operatorsX−1 and S, and X is the set of global variables of the pa-rameterized patterns interpreting the propositions. The setof Past-Tree-LTL formulas is denoted T. A TAXML schemais an expression S|θ for S a BAXML schema and θ ∈ T. Aprerun ρ satisfies ∃Xψ(X) if ρ satisfies ψ(ν(X)) for somevaluation ν of the global variables X in the active domainof ρ.
The choice to existentially quantify the global free vari-ables appears natural for specifying workflow transition con-straints. Observe that such variables are quantified univer-sally in the language Tree-LTL of [5], used to specify prop-erties of all runs. However, the model checking approachof [5] is based on checking unsatisfiability of the negationof Tree-LTL formulas, whose global variables then becomeexistentially quantified.
To illustrate Past-Tree-LTL constraints, consider the de-scription of valid transitions in the MailOrder example. Thiscan be specified by a Past-Tree-LTL disjunctive formula.One of its disjuncts is the following:
∃y(
ψ?Bill(y) ∧X−1ψ!Bill(y) ∧X
−1ψγc(Bill)(y))
stating the existence of an order id y for which ?Bill ispresent in the current instance, !Bill is present in the pre-vious instance, and the guard of Bill is true in the previousinstance. This is done using appropriate parameterized pat-terns4 ψ?Bill (y), ψ!Bill (y) and ψγc(Bill)(y).
Checking workflow constraints
The following establishes the complexity of testing workflowconstraints.
Theorem 4. Let S|W be a fixed workflow schema, forW ∈ {G,A,T}, and ρ a prerun of S. Checking whether ρsatisfies W can be done in ptime with respect to |ρ|.
A more difficult decision problem is checking the existenceof a valid transition extending the current prerun. Indeed,this is undecidable even for BAXML schemas with no work-flow constraints (with either flavor of the abort semantics).The difficulty arises from the power of external functions.Indeed, without external functions it suffices to test all pos-sible call activations and returns. However, the problembecomes decidable for bounded trees.
Theorem 5. (i) Given a BAXML schema S and a pre-run ρ of S, it is undecidable whether ρ is blocking. (ii) Givena BAXML schema S with non-recursive DTD and a prerunρ of S, it is decidable whether ρ is blocking.
5. EXPRESSIVENESSIn this section we compare the expressive power of BAXML,
GAXML, AAXML, and TAXML, using the framework de-veloped in Section 2. We begin by comparing the languagesrelative to views retaining full information about the cur-rent BAXML document, that we refer to as identity views.We then consider a more permissive version allowing to hidesome of the data and functions, thus providing more leewayfor simulations.4The parametrized pattern formula ψγc(Bill)(y) is obtainedby replacing in γc(Bill) each label self by !Bill and mappingy to the Order-Id of the MailOrder to which !Bill belongs.
Workflow system semantics
We begin by casting the semantics of BAXML, GAXML,AAXML, and TAXML in terms of the workflow systems de-scribed in Section 2. For each specification S (for BAXML)or S|W (for GAXML, AAXML and TAXML), the nodes ofthe workflow system are the finite prefixes of runs of S orS|W . The state label for each node is the last instance inthe prefix. The root is the empty prerun, denoted Φ. Thereis an edge labeled e from node ν to ν′ if ν′ extends ν witha single instance by event e that is a function call or the re-turn of a such a call. Note that the infinite paths in the treestarting from Φ correspond to the runs of S|W . Because ofthe semantics of blocking runs, each path is extensible to aninfinite path.
Note that there are alternative choice of workflow systemsemantics, and different goals may require different choices.For example, for AAXML it may be natural to retain inthe state, information on the current state of the associatedautomaton together with the valuation of its parameters.This would simplify defining views where such states areincluded in the observables.
Comparison with identity views
We first compare BAXML, GAXML, AAXML, and TAXMLrelative to the identity view on the states and events of theworkflow system (denoted id), thus preserving full informa-tion on the system. Observe that if a language W2 simu-lates W1 with respect to (id, id), this means that for eachW1 in W1, there exists W2 in W2, such that W1 ∼ W2,i.e., W1 and W2 have exactly the same runs. So, this isa very strong requirement. Note also, that since id is themost refined possible view of a workflow system, existenceof simulation with respect to id would imply, by Lemma 1,the existence of simulation with respect to any coarser view.Unfortunately (but not surprisingly), the three extensionsof BAXML models are incomparable relative to the identityview.
Theorem 6. The workflow languages GAXML, AAXMLand TAXML are incomparable relative to →(id,id).
Comparison with projection views
Given the negative result of Theorem 6, we next considersimulation relative to views allowing more leeway in the sim-ulating system. Specifically, the view remains the identityon the simulated system, but allows the simulating systemto use additional data and functions. We refer to the latteras a projection view and denote the class of projection viewsby π.
Specifically, let S be a BAXML schema and Σ0 and F0 besubsets of the tags and functions of S (the visible symbols)such that, in every instance satisfying the DTD of S, when-ever a node has tag a 6∈ Σ0, none of its descendants has alabel in Σ0 or in F0. The projection πΣ0,F0
([S]) is definedas follows. For a state I of [S] (and for any instance), theprojection is obtained by removing all nodes whose label isa tag not in Σ0 or a function not in F0 and their descen-dants. We also remove the workspaces whose correspond-ing function calls have been projected out. The projectionof an event !f(F ) is ǫ for f 6∈ F0 and !f(πΣ0,F0
(F )) forf ∈ F0, and similarly for ?f(F ). The projection view isdefined in the same way for BAXML augmented with con-straints (GAXML, AAXML, and TAXML).
86
Simulation Schema blowup Instance blowup Silent transitionsGAXML →(id,π) BAXML exponential linear in instance linear in prerunAAXMLsib →(id,π) BAXML exponential polynomial in instance polynomial in prerunTAXMLsib →(id,π) BAXML exponential polynomial in prerun polynomial in prerunTAXML →(id,π) AAXML exponential polynomial in prerun polynomial in prerunAAXML →(id,π) TAXML polynomial polynomial in instance O(1)
Figure 7: Cost of various simulations from Theorems 7 and 8
Our main result is that, with projection views, the pow-erful control mechanisms of GAXML can be simulated byBAXML alone. For AAXML and TAXML, we need a mi-nor restriction forbidding the presence of sibling calls to thesame external function (this can be enforced by the DTD).We denote these restrictions by AAXMLsib and TAXMLsib.
Theorem 7. W →(id,π) BAXML
for W ∈ {GAXML,TAXMLsib,AAXMLsib}.
Since BAXML is included in GAXML, TAXMLsib, andAAXMLsib, it follows that the four languages can simulateeach other relative to projection views.
For AAXML and TAXML, we have the following.
Theorem 8. AAXML →(id,π) TAXML andTAXML →(id,π) AAXML.
The proofs of the above results (omitted) provide insightinto the simulations of the four languages by each other, andin particular into the power of imposing control using staticconstraints. In terms of the cost of each simulation, severalparameters can be considered: (i) the blowup in the schemasize, (ii) the blowup in the instance size, (iii) the number ofsilent transitions needed to simulate a single transition. Forthe simulations considered here, the blowup in the schemasize varies from polynomial to exponential, the blowup in theinstance size from polynomial with respect to the instanceto polynomial with respect to the entire prerun, and thenumber of silent transitions from constant to polynomialin the prerun (for fixed schemas). The costs for varioussimulations are spelled out in more detail in Figure 7.
The difficulty of simulating AAXML and TAXML withsibling external function calls by BAXML (or GAXML) liesin the fact that the constraints of AAXML and TAXMLmust be checked after every transition, and GAXML can-not prevent multiple returns from sibling external functioncalls that skip validity checks. Indeed, as shown below, thisdifficulty cannot be circumvented.
Theorem 9. W 6 →(id,π) GAXMLfor W ∈ {TAXML, AAXML}.
Comparison with coarser views
Theorem 7 shows that BAXML, GAXML, TAXMLsib andAAXMLsib can simulate each other relative to projectionviews. This result turns out to be quite powerful. Indeed,by Lemma 1 it implies that the simulation results can beextended to any views that are coarser than such views. Forexample, one may wish to focus on the sequence of events(function calls and returns, together with their arguments),ignoring state information. This information can be cap-tured by composing the views in id and π with a view V
that is the identity on events and maps every state to a fixedconstant. By Lemma 1, BAXML, GAXML, TAXMLsib andAAXMLsib can simulate each other relative to (id◦V, π◦V ).Similar remarks apply to TAXML and AAXML.
Conversely, one may be interested in observing certaincharacteristics of the states in the tree of runs, ignoring eventinformation. Once again, this can be captured by coarserviews than (id, π) so the four languages can simulate eachother relative to such views.
6. BAXML AND TUPLE ARTIFACTSIn the previous section, we compared the expressiveness
of several workflow languages centered around the commoncore provided by BAXML. In this section, we illustrate howviews can be used to reconcile models that are otherwise in-comparable. For this, we use the views framework to com-pare BAXML workflows with tuple artifacts workflows, avariant of IBM’s Business Artifacts, which uses relationaldatabases as its underlying model. The main result is thatBAXML can simulate tuple artifacts. Indeed, tuple artifactscan be seen as views of BAXML. We will also see that tu-ple artifacts cannot simulate BAXML even with respect tocoarse views retaining just the traces of service and functioncalls.
We first review informally the tuple artifact model, as pre-sented in [16] (see Appendix for the formal definition). Wedenote the model by TA. We assume an infinite data do-main D. An artifact system consists of a set of artifacts anda set of services acting on the artifacts. An artifact consistsof an artifact tuple and a set of state relations. In addition,an artifact system has an underlying database shared by allartifacts and services, that is fixed throughout a run of thesystem.
Each service causes a modification of one or several cur-rent artifacts. Intuitively, the focus is on the evolution ofthe artifact tuples, while the state relations are used to carryauxiliary information needed by the services. A service con-sists of the following:
• a pre-condition, which is an FO formula on the set ofartifacts of the system and the underlying database;
• a post-condition, which is an FO formula on the setof artifacts and the database, defining, for each arti-fact tuple, the values allowed in the next instance; freevariables range over the infinite domain D, so may takenew values not present in the current instance;
• for each state relation, two FO formulas defining thesets of tuples to be inserted and deleted from the state.The formulas take as input the current artifact in-stance and the database, and are interpreted with ac-tive domain semantics. Thus, their result is alwaysfinite.
87
Services are applied non-deterministically. At any giventime, a service can be applied to the current instance if itspre-condition holds and if the post-condition is satisfiable.Thus, there are two forms of non-determinism in a transi-tion: one stemming from the choice of service, and anotherfrom the choice of values for the next artifact tuples, fromamong those satisfying the post-condition. A run of an ar-tifact system is a sequence of consecutive instances togetherwith the name of the service applied at each transition. (Forinitial instance, we take any instance whose artifact statesare empty.) As for BAXML, blocking runs are extendedby repeating forever the last configuration, with the corre-sponding transitions labeled by the special event block. See[16] for a detailed example of an artifact system.
In order to simulate TA with BAXML, we must defineviews that render the two compatible. For TA, we sim-ply take the identity views id. For BAXML, we considerschemas of a special form, that represent the artifact tuplesand relations (states and database) of TA. A relation R withattributes A1 . . . Am is naturally represented in BAXML bya subtree rooted at R, satisfying the DTD:
R → |tupR| ≥ 0tupR → ∧m
i=1|Ai| = 1Ai → |dom| = 1
We will have to record several instances of a state relationR. To distinguish the current one, it will be adorned bya function call !current just placed under its root, i.e., anR-labeled node. Artifact tuples are handled similarly. Eachservice of the artifact system is modeled in BAXML by acorresponding function with the same name. The call of aservice is captured in BAXML by a call to the correspondingfunction. Given a BAXML instance as described, the viewis defined as follows. On states of the BAXML workflowsystem, the view maps the subtrees representing databaseand state relations, and artifact tuples, to the correspond-ing relations and tuples. Events consisting of activations offunctions corresponding to services are mapped to the cor-responding service name, and all others are mapped to ǫ.We denote this class of views by VTA. The main result isthe following.
Theorem 10. TA →(id,VTA) BAXML.
Thus, BAXML can simulate TA. In fact, since the viewused for TA is the identity, tuple artifacts themselves canbe seen as views of BAXML systems. The simulation yieldsa BAXML schema polynomial in the TA schema, BAXMLinstances polynomial in the TA instances, and polynomi-ally many silent transitions (with respect to the current in-stance), to simulate in BAXML one transition of TA.
Conversely, we will show that, in a strong sense, TA can-not effectively simulate BAXML. We use coarse views thatretain just the names of function calls in BAXML and of ser-vice calls in TA (modulo a projection). Such views are nat-ural because the traces of function and service calls largelycapture the sequencing of events central to workflows. Wewill prove a strong negative result for such views. Intuitively,the problem in simulating BAXML with TA is due to thefact that BAXML can read a large structure (for examplean entire relation represented as an XML document) by asingle function call. On the other hand, tuple artifacts canonly read one tuple at a time, so the simulation requires
a loop. This loop may lead to an infinite sequence of ǫ-transitions (imagine a denial-of-service attack in which theattacker keeps sending new tuples). But if no such sequenceof ǫ-transitions occurs in the BAXML system, this is not acorrect simulation.
More precisely, the views we use are defined as follows:
states for both BAXML and TA, all states are mapped toa constant state (so all information about the states islost);
events for BAXML, active calls ?g are mapped to ǫ andcalls !g are mapped to g or to ǫ (so some function callscan be hidden); for TA, a service σ is mapped to σ orto ǫ (so again, some services can be hidden).
We denote the above class of views of BAXML systemsby Vfun and of TA systems by Vserv.
Recall that the definition of simulation does not requireeffective construction of the simulating schema (even thoughall our positive simulation results are constructive). We canshow that one cannot effectively construct a TA specifica-tion simulating a given BAXML schema, with respect tothe above views.
Theorem 11. There is no algorithm that, given as inputa BAXML schema W1 and a view V1 ∈ Vfun produces a TA
schema W2 with a view V2 ∈ Vserv such that V1([W1]) ∼V2([W2]). Moreover, this holds even for BAXML schemasof bounded depth.
The proof (using only BAXML schemas of bounded depth)relies on the undecidability of implication for FDs and IDs.
Remark 2. By Lemma 1 (applied to effective simulations),the negative result of Theorem 11 extends to any views thatexpose more information than those above.
7. CONCLUSIONThis paper makes a dual contribution. First, it proposes
a flexible framework for comparing distinct workflow mod-els by means of views extracting a common set of observ-able states and events, and a natural notion of simulation.Second, it uses this framework to compare concrete lan-guages capturing some of the main workflow specificationparadigms: automata, temporal constraints, and pre-and-post conditions. These were first investigated using as acommon core BAXML, where the integration of XML andembedded function calls allows to naturally support a widerange of data-centered tasks. We proved the surprising re-sult that the static constraints of BAXML are alone suf-ficient to simulate the three apparently much richer work-flow specification languages mentioned earlier. Beyond thespecifics of the XML-based model, the results provide in-sight into the power of the various workflow specificationparadigms, the trade-offs involved in choosing one over an-other, and the relation to static constraints. Finally, we com-pared BAXML to tuple artifacts, a variant of IBM’s Busi-ness Artifact model using relational databases. We showedthat BAXML can simulate tuple artifacts whereas the con-verse is false. To compare these very different models, weused again the views framework to render them compatible.This illustrates the usefulness of the view-based frameworkto reconcile seemingly incomparable workflow models.
88
8. REFERENCES
[1] S. Abiteboul, O. Benjelloun, and T. Milo. The ActiveXML project: an overview. VLDB J., 17(5), 2008.
[2] S. Abiteboul, P. Bourhis, A. Galland, andB. Marinoiu. The axml artifact model. In Time, 2009.
[3] S. Abiteboul, L. Herr, and J. V. den Bussche.Temporal versus first-order logic to query temporaldatabases. In PODS, 1996.
[4] S. Abiteboul, R. Hull, and V. Vianu. Foundations ofDatabases. Addison-Wesley, 1995.
[5] S. Abiteboul, L. Segoufin, and V. Vianu. Staticanalysis of Active XML systems. In TODS, 2009.Extended abstract in PODS 08.
[6] S. Abiteboul, V. Vianu, B. Fordham, and Y. Yesha.Relational transducers for electronic commerce. JCSS,61(2):236–269, 2000. Extended abstract in PODS 98.
[7] N. Adam, V. Atluri, and W. Huang. Modeling andanalysis of workflows using Petri nets. Journal ofIntelligent Information Systems, 10(2):131–158, 1998.
[8] N. Alon, T. Milo, F. Neven, D. Suciu, and V. Vianu.XML with data values: typechecking revisited. JCSS,66(4):688–727, 2003.
[9] R. Alur, M. Benedikt, K. Etessami, P. Godefroid,T. W. Reps, and M. Yannakakis. Analysis of recursivestate machines. ACM Trans. Program. Lang. Syst.,27(4):786–818, 2005.
[10] M. Arenas, W. Fan, and L. Libkin. Consistency ofXML specifications. In PODS, 2002.
[11] K. Bhattacharya, C. E. Gerede, R. Hull, R. Liu, andJ. Su. Towards formal analysis of artifact-centricbusiness process models. In BPM, 2007.
[12] M. Bojanczyk, A. Muscholl, T. Schwentick,L. Segoufin, and C. David. Two-variable logic onwords with data. In LICS, 2006.
[13] BPEL. http://bpel.xml.org/.
[14] D. Calvanese, G. D. Giacomo, R. Hull, and J. Su.Artifact-centric workflow dominance. InICSOC/ServiceWave, pages 130–143, 2009.
[15] S. Demri and R. Lazic. Ltl with the freeze quantifierand register automata. ACM Trans. Comput. Logic,10(3):1–30, 2009.
[16] A. Deutsch, R. Hull, F. Patrizi, and V. Vianu.Automatic verification of data-centric businessprocesses. In ICDT, 2009.
[17] A. Deutsch, L. Sui, and V. Vianu. Specification andverification of data-driven web applications. JCSS,73(3):442–474, 2007.
[18] G. Dong, R. Hull, B. Kumar, J. Su, and G. Zhou. Aframework for optimizing distributed workflowexecutions. In DBLP, 1999.
[19] E. A. Emerson. Temporal and modal logic. In J. V.Leeuwen, editor, Handbook of Theoretical ComputerScience, Volume B: Formal Models and Sematics,pages 995–1072. MIT Press, 1990.
[20] W. Fan and L. Libkin. On XML integrity constraintsin the presence of dtds. In PODS, 2001.
[21] C. Fritz, R. Hull, and J. Su. Automatic constructionof simple artifact-based business processes. In ICDT,2009.
[22] D. Georgakopoulos, M. Hornick, and A. Sheth. Anoverview of workflow management: From process
modeling to workflow infrastructure management.Distributed and Parallel Databases, 3:119–153, 1995.
[23] C. E. Gerede, K. Bhattacharya, and J. Su. Staticanalysis of business artifact-centric operationalmodels. In IEEE International Conference onService-Oriented Computing and Applications, 2007.
[24] C. E. Gerede and J. Su. Specification and verificationof artifact behaviors in business process models. InICSOC, 2007.
[25] D. Harel. Statecharts: A visual formulation forcomplex systems. Sci. Comput. Program,8(3):231–274, 1987.
[26] R. Hull. Personal communication, 2009.
[27] R. Hull, F. Llirbat, B. Kumar, G. Zhou, G. Dong, andJ. Su. Optimization techniques for data-intensivedecision flows. In ICDE, 2000.
[28] R. Hull, F. Llirbat, E. Simon, J. Su, G. Dong,B. Kumar, and G. Zhou. Declarative workflows thatsupport easy modification and dynamic browsing. InProc. Int. Joint Conf. on Work ActivitiesCoordination and Collaboration, 1999.
[29] D. Martin et al. OWL-S: Semantic markup for webservices, W3C Member Submission, November 2003.
[30] S. A. McIlraith, T. C. Son, and H. Zeng. Semantic webservices. IEEE Intelligent Systems, 16(2):46–53, 2001.
[31] R. Milner. Communication and concurrency.Prentice-Hall, Inc., 1989.
[32] W. Mok and D. Paper. Using Harel’s statecharts tomodel business workflows. J. of DatabaseManagement, 13(3):17–34, 2002.
[33] S. Narayanan and S. McIlraith. Simulation,verification and automated composition of webservices. In WWW, 2002.
[34] F. Neven, T. Schwentick, and V. Vianu. Finite statemachines for strings over infinite alphabets. ACMTrans. Comput. Logic, 5(3):403–435, 2004.
[35] A. Nigam and N. S. Caswell. Business artifacts: Anapproach to operational specification. IBM SystemsJournal, 42(3):428–445, 2003.
[36] L. Segoufin. Static analysis of XML processing withdata values. SIGMOD Record, 36(1):31–38, 2007.
[37] M. Spielmann. Verification of relational transducersfor electronic commerce. JCSS, 66(1):40–65, 2003.
[38] J. van Benthem. Modal correspondence theory. PhDthesis, Mathematish Instituut & Instituut voorGrondslagenonderzoek, Univ. of Amsterdam, 1976.
[39] W. van der Aalst. Business process managementdemystified: A tutorial on models, systems andstandards for workflow management, 2004. In Lectureson Concurrency and Petri Nets.
[40] W. M. P. van der Aalst. The application of petri netsto workflow management. Journal of Circuits,Systems, and Computers, 8(1):21–66, 1998.
[41] W. M. P. van der Aalst and A. H. M. ter Hofstede.Workflow patterns: On the expressive power of(petri-net-based) workflow languages. In Proc. of theFourth International Workshop on Practical Use ofColoured Petri Nets and the CPN Tools, 2002, 2002.
[42] J. Wang and A. Kumar. A framework fordocument-driven workflow systems. In BusinessProcess Management, pages 285–301, 2005.
89