entity that either relates to the composite WS specification (e.g., a process, .... The op in the di«erent OR varies and depends on the aggregation patterns the ...
Dependability and Flexibility Centered Approach for Composite Web Services Modeling Neila Ben Lakhal1, Takashi Kobayashi2, and Haruo Yokota1 2 1
2
Tokyo Institute of Technology, Department of Computer Science Tokyo Institute of Technology, Global Scientific Information, and Computing Center Abstract. The interest surrounding the Web services (WS) composition issue has been growing tremendously. In the near future, it is awaited to prompt a veritable shift in the distributed computing history, by making the Service-Oriented Architecture (SOA) a reality. Yet, the way ahead is still long. A careful investigation of a major part of the solutions proposed so far reveals that they follow a workflow-like composition approach and that they view failures as exceptional situations that need not to be a primary concern. In this paper, we claim that obeying these assumptions in the WS realm may constrain critically the chances to achieve a high-dependability level and may hamper significantly flexibility. Motivated with these arguments, we propose a WS composition modeling approach that accepts failures inevitability and enriches the composition with concepts that can add flexibility and dependability but that are not part from the WS architecture pillars, namely, the state, the transactional behavior, the vitality degree, and the failure recovery. In addition, we describe a WS composition in terms of definition rules, composability rules, and ordering rules, and we introduce a graphical and a formal notation to ensure that a WS composition is easily and dynamically adaptable to best suit the requirements of a continuously changing environment. Our approach can be seen as a higher level of abstraction of many of the current solutions, since it extends them with the required support to achieve higher flexibility, dependability, and expressiveness power.
1 Introduction The interest surrounding the Web services composition (WSC) issue has been growing tremendously. To date, it has triggered a substantial amount of research e orts. A significant progress exemplified with the emergence of a myriad of specification languages (e.g., BPEL [1] and OWL-S [2]) and of a whole panoply of WSC strategies including dynamic WSC models (e.g., eFlow [3]), declarative WSC models (e.g., SELF-SERV [4]), and semantic WSC models (e.g., SHOP2 [5]), has been noticed. Nevertheless, the WSC technology is still regarded as not mature enough and much more must happen before it reaches its apogee. A careful investigation of major part of the available solutions reveals that they share two limitations that preclude them from being solutions that meet modern IT environment requirements (i.e., high dependability and flexibility, automated discovery, composition, and enactment). The first limitation is that the Workflow-based WSC approach is at the core of the majority of the current solutions. Representative examples are eFlow platform [3], R. Meersman, Z. Tari et al. (Eds.): OTM 2006, LNCS 4275, pp. 163–182, 2006. c Springer-Verlag Berlin Heidelberg 2006
164
N. Ben Lakhal, T. Kobayashi, and H. Yokota
BPEL [1], and SELF-SERF framework [4]; all of these enable the composition of WS as Workflows. Actually, this was the direct consequence of the prevailing current of thought that the only major di erence between Workflows and WSC is that the latter aims chiefly at taking XML-based standards (e.g., WSDL, SOAP), yet to reach the same goals. This line of thinking has yielded solutions that obey to restrictions that apply in the field of Workflow systems but that are not accounted for in the WS realm since: – In Workflow systems, the cooperating parts are set a priori, and only those parts can cooperate within well-defined and closed boundaries with predefined policies and Service Level Agreements (SLAs). However, the WS environment is widely known for its heterogeneity, dynamism, and loose coupling, where di erent parts may interact beyond their boundaries, and where the interacting parts change even at runtime. Therefore, the possibility to continue the process enactment without interruption with the new changes is highly desired. Moreover, dealing with SLA in such a dynamic environment gets very complex since each WS may interact with many others simultaneously; if each interaction is governed by an SLA, managing the di erent SLAs becomes an overwhelming task [6]. – In Workflow systems, the definition of the process logic (i.e., decomposition of the process among participants) is rarely subject to changes. However, the ability to adapt easily, rapidly, and dynamically to changes without having to require the developer manual intervention to re-generate the overall WSC, is fundamental in the WS context. Otherwise, failure possibilities will be critical and the chances to succeed in doing the best matchmaking between process components and WS that are most likely to show better quality of execution will be seriously constrained. As for the second limitation, many of the current WSC approaches, they only focus on how to interleave pre-existing WS into a WSC and they consider WS failures as exceptional situations that need not to be a primary concern. In fact, only very few cases provide simple failure handling mechanisms [1] [7]. We claim that in the WS realm, relying heavily on the Internet makes failures unavoidable. Adding to the Internet unreliability, a whole set of characteristics of the modern computing environments (e.g., unpredictability, heterogeneity, autonomy, dynamism, etc.) in which the deployed WS subsist, makes the most unexpected failure a normal part of the life of any WS. Furthermore, with assembling WS into WSC, failure frequency is more important than ever. In this paper, we opt for a radically di erent approach and we propose a novel WSC modeling approach that can be seen as a higher layer of abstraction of the solutions proposed so far, since it can extend them to support WSC in more powerful way, with an increasing level of flexibility and dependability. The first key strategy in our approach to add expressiveness power and the required flexibility and dependability is to enrich the WSC model with concepts that are required but are not yet part from the WS architecture pillars. We emphasize that these concepts should be carefully selected to not restrict in any respect the WS architecture capabilities. In our approach, we build mainly on the state (i.e., component behavior), vitality degree, and transactional behavior concepts, widely recognized by the database community to have contributed in achieving significant improvements in dependability [8]. The second key strategy to realize the desired flexibility is based on allowing the process definition (i.e., components order of execution, components nesting) changing
Dependability and Flexibility Centered Approach
165
and the process components dynamic composition andor decomposition in view of the WS availabilityquality of execution. This will guarantee that the best matchmaking between the process components and the available WS could be done, and will ensure that the obtained WSC are easily adaptable to the environment change. We identify a process in terms of Definition Rules(DR) to provide the di erent components description, Composability Rules(CR) to inform about the relation between the components, and Ordering Rule(OR) to define the ordering relation between the components. This paper is organized as follows. In Section 2, we introduce the limitations of adapting a workflow-based WSC approach, then, we discuss the key requirements for a flexible and dependable WSC. In Section 3, we define our model key concepts. In Section 4, we describe how our approach can be applied to an illustrative example. In Section 5, we discuss our approach contributions and show how the limitations identified in Section 2 can be addressed. In Section 6, we discuss several related work. In Section 7, we conclude our paper and introduce several future directions.
2 Motivating Example and Key Requirements We describe a motivating example and discuss several specific enactment scenarios of a loan request process. In the light of this example, we will show the limitations of a Workflow-based WSC approach. In particular, we intend to show first, to what extent a such an approach may hamper significantly interoperation and leave no room for a dynamic process change to increase flexibility. Second, how such an approach may a ect critically the dependability level of the overall composition. Throughout those scenarios, we identify the key requirements that a typical WSC approach must satisfy to achieve a higher level of flexibility and dependability. Specifically, we consider the case of BPEL. We emphasize that we are perfectly aware that BPEL remains only a specification language, yet, in this paper, we propose a modeling approach, which would be assimilated more to proposals like [4] [7]. Our justification is that BPEL is the current defacto language and many are familiar with it. Thus, explaining our motivating example on the base of a BPEL description would be straightforward and clearer. Moreover, as we shall show later in this paper, our model can perfectly extend BPEL and can constitute a higher level of abstraction. Therefore, the discussion that will follow is not restricted to BPEL but it can be generalized to a wide range of solutions that share the same workflow-like WSC approach. 1 2.1 Illustrative Example Description We consider the case of a process where a customer requests a bank for a loan. The bank passes a subset of the customer information on to a credit rating agency that comes back with a credit report. The bank bases its decision on this data and responds to the customer, quoting an interest rate for the desired loan. The customer can then confirm the acceptance based on those terms or reject it. For illustration, the listing in (Appendix A.) 1
For space limitation, we only added a comparison with [3] [4] [7]in the related work section.
166
N. Ben Lakhal, T. Kobayashi, and H. Yokota
shows the BPEL syntax for the process from [9]. Each BPEL composition is a workflow that interacts with a set of WS to achieve a certain goal. BPEL WSC are called ; the WS the process interacts with are called [10]. In the case of the process, the WSC weaves together two WS — the and the . 2.2 Limitations of a Workflow-Like Composition A workflow-like composition does not support dynamic changes. For instance, in the BPEL listing of (Appendix A.), the only way to adapt the WSC to new changes in the process logic (e.g., new business rule, new management policy, etc.) is by reviewing all the interaction logic between the di erent and rewriting all the . In the case of the above-described and simplified process, regenerating the overall process specification can be somehow accepted; however, since processes tend to be complex, regenerating to overall process every time will be a timeconsuming and costly task, and make such approach not satisfactory. The second limitation of a Workflow-like composition is the limited support for dynamic binding. We take again the case of BPEL. In a BPEL process, when a WSC is designed, it does not contain any reference to any specific WS; it only lists partner port types, thereby the abstract process appellation. To construct an executable process, the first alternative is when concrete WS are mapped to the partners. Once this mapping is defined, it is fixed for all invocations and cannot be changed automatically as the process runs. Even though this feature can allow some flexibility since it o ers the possibility of assigning to the di erent partners di erent WS, this is far from being enough since the mapping is done statically before the WSC is invoked. The interaction between the di erent partners is only defined in one way and it presumes that the partners in question are always available. Since it is very likely that any of the partners become unavailable for any reason, the overall WSC success might be comprised. Adding the WS high-failure tendency, the WSC invocation failures rate will be unacceptable. The second alternative introduced in BPEL is the possibility to select and assign actual partner services dynamically, and BPEL provides the mechanisms to do so via assignment of endpoint references. Even though this adds some form of dynamic binding, still it is not possible to change the assigned values to the activity as the process runs, to allow for instance, the execution with another alternative endpoint, in case of failure. So far, this mechanism was only added to extend the service endpoint information with instance-specific information to support the case of stateful partners. 2.3 Motivating Scenarios Actually, there are many scenarios that a workflow-based composition can hardly support but that are highly desired to be feasible. We describe some of them in what follow, using the above BPEL example, and we point out the requirements that a typical WSC model must satisfy to support these scenarios: Scenario 1. Based on the developer’s decision, two WS are mapped to the two roles
, . If an error occurs at the WS bound statically to the role , a compensation handler is invoked, and all the completed activities
Dependability and Flexibility Centered Approach
167
will be compensated for. By providing the fault handlers and the compensation, BPEL allows to add some reliability support. However, declaring the process as failed should be the last resort if a successful execution is impossible. Envisaging the possibility of dynamically binding failed partners to other WS is more promising, especially in the WS context, since the probability of seeing a WS failing is high, and that WS providers o er their WS to several clients and clients can switch their providers. To this end, we introduce the forward recovery and backward recovery. Scenario 2. When a BPEL process is to invoked, a mapping between WS and partners is set, and this mapping is fixed for all the executions. As the process runs, there is no mean to know the execution progress, since WS are generally stateless and BPEL provides only a correlation-based stateful interaction that allows only identifying instances. Another mechanism is required to identify the interacting parts progress as the process runs, and to derive the process instances progress. To fulfill this requirement, we propose to attach a state to each of the partners; we will detail its functioning later. Scenario 3. BPEL assumes that there are imperatively two that must be defined a priori to enact the above process. However, knowing that the WS environment dynamism, it is very probable that new (WS) that can satisfy at the same time the functionalities of both of the two together are made available. For instance, assume that a WS that o ers both of the two capabilities and is available. The way the WSC is defined in BPEL precludes from dynamically and transparently switching from two to only one without the process developers intervention to completely regenerate the BPEL process definition. Invoking the process with two instead of only one
, will entail an unnecessary message exchange cost and a doubled failure risk. This can be avoided if the process definition is enriched with clauses that inform about the possibility of combining partners together, or exploding a partner in a set of partners and so forth, and dynamically taking such decision in view of the WS availability, without requiring the developer’s intervention. Scenario 4. Suppose that one of the process components is actually the execution of more than one operation; for instance, in partner , instead of having only one operation, two operations are invoked: and . Suppose also that in all the previous invocations of the service , a rather high failure tendency was noticed, and that in all these invocations, was almost always behind the failure. In the other hand, assume that there are WS that can perform separately the functionalities of the two operations and with higher quality of execution. If the BPEL process definition can switch dynamically, and select two partners for and , then failure rate can be ameliorated and better results from the overall performance point of view can be acquired. Scenario 5. Assume that a customer would like only to make a simulation of the loan process, that is, he only wants to have an idea about the credit rating and term, but does not desire to see its request considered for approval or rejection for the moment being. In the shown listing in (Appendix A.), the di erent activities in
168
N. Ben Lakhal, T. Kobayashi, and H. Yokota
are combined in the structured activity . Thus, a correct execution of the process requires the successful enactment of all the di erent combined primitive activities in the sequence. If any of those primitive activities will fail, a fault handler will be triggered. Adding a mechanism that will permit both, a loan simulation and a real loan request and decision, will increase the potential range of possible customers. To satisfy this requirement, we introduce the concepts of vitality degree where some partners are identified as optional whether the others are tailored as crucial for the overall process they compose. We shall detail the vitality degree in the following section. To fulfill the requirements we identified using the above-described scenarios, and to make a composition suited in an ever-changing distributed environment, we present in detail how we address these requirements in the following section.
3 Composite Web Service Specification Model In this section, we introduce the model we tailored to answer the need of a specification especially made to fit the specificities of the WS architecture. We first introduce the salient features of our model: the process and the element concepts, the transactional behavior, the state, the vitality degree, the failure recovery, and finally, the flexibility support. Then, we describe how we depict a WSC in terms of Definition Rules, Composability Rules, and Ordering Rules, how these rules are determined and noted. 3.1 Model Salient Features Description Process and Element. The underpinning logic of a process (noted Pi ) is depicted as a composite WS (noted CWS i ), with i ranging over the set of natural numbers IN to designate di erent processes. Since we target a dynamic execution, where the process components are mapped on the fly to WS, instead of orchestrating a set of WS statically, we introduce the concept of element and use it as a unit of composition. Each process Pi is composed of di erent elements (noted Ei k ), where k is ranging over [1 Pi ] and Pi is the cardinality of Pi , that is, the number of elements composing Pi . On executing composite WS, WS are to be mapped to the di erent elements. The possibility of choosing every time di erent WS and of composing andor decomposing the process in various ways according to the WS availability, will increase the chances to achieve better quality of execution by doing the best matchmaking between elements and WS.
Transactional Behavior. It is widely recognized that there is a need for a transactional support in the WS world to leverage dependability. There is a number of proposal toward this direction including WS-Transaction [11], and WS-TXM [12]. The main limitation of these proposals is that they define models for centralized and peer-to-peer transactions, which support a two-phase coordination of WS. They do not support applications that involve dynamic composition of heterogeneous services in a peer-to-peer context. Moreover, we are strongly convinced that applying the conventional transaction model [8] would fail, given the loosely coupled nature of the WS environment and the locking mechanisms to preserve ACID properties inappropriateness. There are several advanced transaction models to allow the definition of ACID-like properties. We investigated the applicability of several of them but we found out that
Dependability and Flexibility Centered Approach
169
WSC warrant a particular transactional support specially shaped for them. We propose to inherit features of interest from several advanced transaction models [8], specifically, the arbitrary nesting level, the relaxed ACID properties, the transaction compensation mechanism for the backward recovery; and the vitality degree. Failure Recovery. In our model, we define for each element, when possible, a compensating element. On a failure of an element to commit, we o er two choices: the first is to attempt the element execution retrial where the element is reattempted with another WS. If the first choice is not possible, then, a backward recovery is triggered by either compensating or aborting the element to bring back the overall CWS to a consistent state. To this end, for each compensatable element Ei k , we define a compensating element, denoted Ei¼ k , which will be invoked if a failure later in the execution of Ei k makes it necessary. Ei¼ k occurrence after Ei k will restore the CWS to a state which is an acceptable approximation of the state it had before the execution.
Vitality Degree. To improve the availability of the composite WS and to add flexibility in the way failures cascade through a process Pi , we distinguish a element (Eiv k ) from a element (Eiv¯ k ). The vitality degree obeys the following assumptions:
– A element execution must be successful for its parent process to commit. A element may abort without preventing its parent process commitment; – Aborting a element will induce aborting the whole process it appertains to if there is no alternative WS to retry the failed element. Aborting a element will not be reflected on the execution of the process it appertains to. In the remaining of this paper, the notation (Ei k ) without specifying the vitality degree is used for an element. The distinction between a element (Eiv k ) and a element (Eiv¯ k ) is only done when a special consideration is warranted.
State. Since the reasons behind an occurred failure should be investigated to avoid seeing the same scenario happening again, the WS stateless will make the task diÆcult, our model overcame this limitation by making the elementsprocesses stateful and attaching to each one of them a state. At any given time, the state of every element Ei k is assumed to be exclusively in one of the following predefined six states:
1. 2. 3. 4. 5. 6.
: Ei k is not yet submitted for execution; ! : Ei k is e ectively being executed; ": Ei k has encountered a failure; : Ei k has received a request to abort itself and has obeyed to it; : Ei k has successfully terminated and was committed; : Ei k has been compensated for.
Making the elements stateful helps increasingly to decide how to go forward in a process execution, to tell when a failure happens and the element(s) that isare behind the failure. The state transition diagram is provided in [13].
170
N. Ben Lakhal, T. Kobayashi, and H. Yokota
Process Pi
legend
Textual description of the process underpinning logic
Start
out
formalize process definition
identify ordering rules
identify vital/non vital elements, composite/atomic elements, compensating elements etc. make diagram
Formal CSP-like notation identify composability rules
update
Atomic element
End
in
Composite element Compensating element input data output data Flow between elements Multiple DR, CR, or OR of an element/process
CWS i
identify definition rules
ws ws
State
i.k+1
OR(P) i ...
CR(P ) i ...
update
update
DR(P ) i DR(E ) i.k DR(E i.k+1) ...
State i.k ...
Ei.k
update
ws
...
Ei.k+1 ...
Statei.k E
ws
WSs repositories check WSs availability update graph
i.k+2
Fig. 1. Conceptual overview of the approach
Flexibility Support. We introduce the possibility of process components order changing, that is, we propose to allow the arbitrary nesting notion where the elements processes can be recursively composeddecomposed in order to facilitate and ensure that the best matchmaking between the elements and the candidate WS is done. Yet, this might not be possibleallowed for all kind of processes or it might be restricted to only some of its components. That is why it is essential to have a comprehensive knowledge of the process definition (i.e., its elements full description, distinguish optional from essential elements, in which order they can be interleaved). Since a textual description of the process underpinning logic may become complex and hard to update, we propose to describe a process by identifying three di erent kind of Rules, which share the same tuple-like notation. Yet, their semantics are di erent since the Definition Rules (DR) provide the di erent components description, the Composability Rules (CR) inform about the relationship between the di erent components, and the Ordering Rule (OR) specify the condition to which the relationship between the di erent components must verify. To understand the process logic and how its components relate to each other, we complement our specification model with a graphical notation we shall use later in a running example. 3.2 Definition Rules (DR) Determination To describe a process Pi as composite WS CWS i that follows our specification model, the first step is to identify the di erent DR on the base of the di erent business rules that the process logic defines (see Fig.1). Each DR gives relevant information about an entity that either relates to the composite WS specification (e.g., a process, an element, a component, etc.) or that intervenes in the composite WS execution (e.g., a WS, a coordinator, etc.). We adopt the following tuple-like generic notation to define a DR, where an attribute is an information about an Entity: DR(Entityi ) : attribute1
DR(Entity j ) : attribute2
DR(Entityk ) : attribute3
(1)
Dependability and Flexibility Centered Approach
171
Specifically, in our specification model, we define DR to provide relevant information about two di erent entities: process and element. Definition 1 (Definition Rule of a Process (DR(Pi ))). We define it by an ordered tuple that provides relevant information about Pi , namely its name, description, composability, state, vitality, and finally input and output parameters. Extending the DR with other attributes, such as QoS attributes is possible. The number of DR necessary to define Pi depends on the number of component elements initially identified. The notation of a process DR is a specialization of the generic DR notation in (1) for an Entity:
DR(Pi ) : name description composability state vitality in out
(2)
Where : - name is the name of the process and description is a concise description of the process main functionality; - composability informs about the possibility of decomposing the process into elements. It verifies the condition: DR(Pi ) composability # ; - state informs about the execution progress of the process as a whole. The state of Pi is deduced from the state of its di erent composing elements. - vitality informs about the vitality degree of the process; it is defined according to the vitality degrees of the di erent component elements appertaining to the process. It verifies: DR(Pi ) vitality - . - in is a tuple composed by the di erent input parameters of the process. We denote with in tuples of input parameters; for instance, we may have: in in1 in2 in p , are the di erent output paramfor a process with p input parameters. Similarly, out tuples of output parameters. eters of the process. We denote with out Definition 2 (Definition Rule of an Element (DR(Ei k ))). is an ordered tuple that provides relevant information about an element from a process Pi , with k ranging over [1 Pi ]. For every element, DR(Ei k )is defined in the same way we defined it for a process. The same attributes apply for the element also. For every compensating element, we may define DR(Ei¼ k ) in the same way we defined it for a process element.
»
3.3 Composability Rules (CR) Determination Each CR specifies the relation between the di erent entities defined by the di erent DR (i.e., how the entities are composed together, how the entities interact together, etc.). We adopt the following tuple-like generic notation to define a CR where CR(Entityi ) indicates the relationship that Entityi defines between Entity j and Entityk : CR(Entityi ) Entity j Entityk
(3)
In our model, the di erent CR identify the relationship of composability between the di erent elements and processes: Definition 3 (Composability Rule of a Process (CR(Pi ))). Defines the di erent elements the process is composed of. The CR existence absence depends on the value of the composability attribute in the process corresponding DR: «
»
172
N. Ben Lakhal, T. Kobayashi, and H. Yokota
- If (DR(Pi ) composability # ) then the process is and no CR are defined. It can be assimilated to only one element; - If (DR(Pi ) composability ) then the process is and among the di erent CR, we must have a predefined rule that says how the process can be decomposed in di erent elements and what are those elements; «
«
A CR of a process is a specialization of the entity’s CR described in (3) and it defines that the process Pi logic is composed of a set of m elements with m Pi : CR(Pi ) Ei 1 Ei 2
Ei k Ei k
1 E ik 2
Ei j Ei j
1 E i j 2
Ei m
(4)
A particular CR is the first rule that appears at the head of the list of CR; it describes the process logic as a whole: the set of the di erent elements it is composed by. Any CR can be recursively defined, that is, a particular element Ei k can be part from a process CR, yet, it can also define its own CR, if it is not atomic. «
Definition 4 (Composability Rule of an Element (CR(Ei k ))). The existence of CR depends on the composability attribute. In case it verifies: DR(Ei k ) composability , then, the element can be decomposed and it is defined with CR: it is considered as a particular process that has a parent process. For every element, its CR(Ei k ) is defined in the same way we defined it for a process. For every compensating element Ei¼ k , we may define CR(Ei¼ k ) in the same way we defined it for a process element.
»
3.4 Ordering Rules(OR) Determination Each OR defines the condition that the relationship between the di erent entities defined by the CR must verify (i.e., under which condition entities are composed together, under which condition entities interact together, etc.). We adopt the following tuple-like generic notation to define an OR in which op is the condition that the relation between Entity j and Entityk must verify: OR(Entityi ) Entity j op Entityk . In our model, the di erent OR identify the ordering condition that every relationship of composability between elementsprocess should verify: Definition 5 (Ordering Rule of a Process (OR(Pi ))). It defines the order of execution of the component elements the process defined in its CR(Pi ). For a process Pi , if an OR(Pi ) is not explicitly defined, then the di erent elements order is interchangeable. A typical OR of a process is constructed as follows; op is the operator that connects the elements (e.g., sequence, join, etc.); it can be prefixed, post-fixed, or infixed: «
OR(Pi ) (Ei 1 op Ei 2 ) ((Ei k op Ei k 1 ) op Ei k 2 ) (Ei j op (Ei j 1 op Ei j 2 )) op Ei m
(5)
Definition 6 (Ordering Rule of an Element (OR(Ei k ))). Similarly, it defines the order of execution of the components the element defined in its CR(Ei k ), if it is not . For an element Ei k . For every compensatable element, if it defines an (OR(Ei k )), then we should also define the corresponding OR for its compensating element, OR(Ei¼ k ), in the same way we defined it for a process element.
»
Dependability and Flexibility Centered Approach Statei.k+1
...
Ei.k
out
in
in
Statei.k
Statei.k+1
Statei.k
...
Ei.k+1
Ei.k
...
out
...
Ei.k
Ei.k
...
Statei.k+j
...
...
Statei.k+1 Iterate
in
Ei.k+1 out
λ Times
Iterative aggregation pattern
Ei.k
Statei.k+j ...
. . .
Ei.k
Ei.k
Rendezvous
in
Ei.l
Ei.k+j out RendezVous aggregation pattern
...
. . . Statei.k+j
Ei.k+j
Switch
out
Statei.k+j
Ei.k+j
in
Ei.k+j Switch aggregation pattern Statei.k
Statei.k
Statei.l
Ei.k+1
in
Statei.k ...
Selection aggregation pattern
out
.. .
Statej.k+1
Ei.k+1
Statei.k+j in
Statei.k
out
Select
out
Ei.k+j ...
Parallel aggregation pattern
Statei.k
in
Statei.k
.. .
out
in Sequence aggregation pattern
Ei.k+1
Statei.k+1 ...
173
Ei.k
in
Statei.l Exclusive merge in
out λtimes times
Ei.l λ =1
Exclusive merge aggregation pattern
. . . Statei.k+j
Ei.k+j
in
Statei.l Selective merge in
out λtimes
Ei.l
λ= |Q(Ei.l)pre| λ
Selective merge aggregation pattern
Fig. 2. Aggregation patterns considered by our approach
3.5 Aggregation Patterns The op in the di erent OR varies and depends on the aggregation patterns the process logic follows. To define the di erent aggregation patterns, we build on existing work about Workflow patterns and on an analysis of existing Workflow languages reported in [14]. The following reasons motivated our choice: a) control flow dependencies encountered in Workflow modeling comply well with the WS context, since the situations they capture are also relevant in this domain; b) existing languages for WSC like BPEL and BPML were built on the basis of languages for Workflow modeling [15]. By building on the same patterns, we intend to provide a uniform comparison base. The analysis of existing Workflow languages allowed us to identify the relevant patterns necessary to model the logic of any process, no matter how it is. We identified exactly eight patterns (see Fig.2). In [14], authors introduced twenty patterns, but we limited our study to only eight and we deliberately excluded the others (like the cancellation patterns or the state-based patterns) because, those eight, when combined with the compensation, the state, and the vitality degree, they are enough to express any process in the WS context. Yet, Workflow languages provide only a graphical notation of these patterns, and to date, there is no universal notation. To define the di erent aggregation patterns, we propose to describe a syntax in the spirit of Compensating CSP (Hoare’s Communicating Sequential Processes))[16][17] defined by a grammar in BNF-like notation. This will also allow formalizing our model and verifying its semantics, when required. We have chosen to build on Compensating CSP process algebra (PA) because it has already supports for compensation and for reasoning about long-running transactions. If the atomic events of CSP are used to model the elements in our model, then, the op in the di erent OR can be replaced with the operators provided by the CSP language to support sequence (;), and parallel( ). Besides, in order to support failed transactions, compensation operator () is inherited from Compensating CSP. To support the remaining patterns from all the eight aggregation patterns, we introduce other required operators that CSP does not define. Syntax. To define the di erent aggregation patterns, we describe a syntax in the spirit of CSP defined by the following grammar in BNF-like notation:
174
N. Ben Lakhal, T. Kobayashi, and H. Yokota
E1v k
P1 P2 P3
E1v¯ j
P1 ; P2
P1 P2
P1 (P2 P3 ) P1 (P2 P3 ) (P1 P2 ) P3 (P1 P2 )
P1 P2
P1 P¼1
P1
(P1 P2 ) P3
P
(6)
3
– P1 P2 and P3 designate three di erent process; – E1v k and E1v¯ j represent respectively an atomic element and an atomic element appertaining to the process P1 , with k and j ranging in [1 m] and m is the number of elements composing the process P1 . The vitality degree of P1 is determined according to the vitality degrees’ of its composing elements; – P1 ; P2 represents the sequential construct that combines two processes. In P1 ; P2 , P1 is executed first, and only when P1 terminates successfully can P2 be executed; – P1 P2 represents the parallel composition of two processes P1 and P2 ; – P1 P2 represents the operator for constructing processes where the execution order is arbitrary: it can be in parallel, sequentially, or a conjunction of these two orders; – P1 (P2 P3 ) represents the selective choice done by P1 which selects whichever of P2 andor P3 isare to be enabled. P1 (P2 P3 ) represents a particular case since at least and at most only one is to be enabled; – (P1 P2 ) P3 represents the case where the processes P1 and P2 are synchronized at a particular rendezvous point; that is to execute a particular process P3 that comes directly after them, P1 and P2 must wait each other; P3 represents the case where P1 and P2 converge but without syn– (P1 P2 ) chronization at a particular rendezvous point; that is, P3 is activated every time a P3 is similar since P1 and P2 process reaches the rendezvous point. (P1 P2 ) converge but without synchronization at a particular rendezvous point, the di erence is that the process that comes directly after P1 and P2 is activated only once; – P1 represents iterating a process P1 a number of times (); – P1 P¼1 represents the operator for constructing a compensation pair where P1 is the forward behavior and P¼1 is its associated compensating process.
4 Illustrative Example We consider the case of the same above-described process in BPEL of a customer request of a loan. Figure 3 is the graphical notation of the customer loan request process P1 , specified using our specification model. P1 description as CWS 1 is composed of five elements with their compensating elements: four atomic elements and one composite element: E1v 5 is assimilated to an element in CWS 1 , while it is composed of two elements (E1v 5 1 and E1v 5 2 ).
4.1 Rules Determination A CWS 1 is formed by the triplet combining the list of DR,CR,OR of the process P1 and of its composing elementscompensating elements: – Fourteen DR: DR(P1), DR(E1v 1), DR(E1v 2 ), DR(E1v 3 ), DR(E1v 4 ), DR(E1v 5) DR(E1v 5 1 ), DR(E1v 5 2 ), DR(E1v¼1 ), DR(E1v¼2 ), DR(E1v¯¼4 ), DR(E1v¯¼5 ),DR(E1v¼5 1), and DR(E1v¼5 2 ); – Two CR: CR(P1 ) and CR(E1v 5 ); and two OR: OR(P1 ) and OR(E1v 5 ). For space limitation, in what follow, we only describe some of them, the others can be defined in the same way (see Table.1).
Dependability and Flexibility Centered Approach
175
Loan approval process (P1) State1 v
CWS1
in
out
(loan approval request)
State1.2
State1.1 in
in
v
E1.1
out
v
E1.2
in
(receive loan request)
State1.3
out
in
v'ԍ
v'ԍ
' E1.1
E1.2
flow in
End
out
v
in
E1.4
State1.5
out
in
input data output data
Ev 1.5
E1.4
E element State state v vitality degree (text) description
State1.5.1 in
in
v
E1.5.1
State1.5.2
out
(receive customer decision)
Composite element
Atomic element
out
out
(verify customer decision)
v'ԍ
E1.4
Start
Legend
State1.4
out
(get loan terms) (reply loan response)
(get credit rating)
vԍ
v
E1.3
in
out
out
(reply loan response)
v 'ԍ
v'ԍ
E1.5.1
Compensating element
v
E1.5.2
E1.5.2
Fig. 3. Composition graphical notation: example of a customer loan request process Table 1. Determination of the di erent rules of the loan request process Definition Rules: DR(P1) : name description composability state vitality in out
DR(E1v 2 ) : name description composability ! state vitality in out DR(E1v 5 ) : name description ! composability state vitality in out Composability Rules:
Ordering Rules:
CR(P1) E1v 1 E1v 2 E1v 3 CR(E1v 5 ) E1v 5 1 E1v 5 2
E1v 4
E1v 5
OR(P1 ) E1v 1 ; E1v 2 ; E1v 3 ; E1v 4 ; E1v 5 OR(E1v 5 ) E1v 5 1 ; E1v 5 2
4.2 Formalization The formal notation using the syntax in the spirit of CSP that we defined in (6): P1
(E1v 1 E1v 1 ); (E1v 2 E1v 2 ); (E1v 3 E1v 3 ); (E1v 4 E1v 4); E1v 5 E1v 5 (E1v 5 1 E1v 5 1 ); (E1v 5 2 E1v 5 2 )
¼
¼
¼
¼
¼
¼
4.3 Scenarios Feasibility Verification We will show how the di erent concepts our approach introduces are enough to support a highly flexible and dependable WSC. In particular, we show how the scenarios described in Section 2 can be supported: In scenario 1., as the process runs, a dynamic WS discovery and mapping process is performed for each of the elements E1v 2 and E1 3 , realizing respectively the functionalities of and of in the process P1 . Assume that the
176
N. Ben Lakhal, T. Kobayashi, and H. Yokota
mapped WS to E1v 2 failed, then, instead of stopping the overall execution, or requiring the developer’s intervention to select another WS, a forward recovery is attempted by allocating automatically any of the other candidate WS that satisfy the conditions:
DR(E1v 2 ) description DR(WS ) description (i.e., element functionalities WS capabilities); DR(E1v 2 ) in DR(WS ) in (i.e., element WS input parameters are compliant); DR(WS ) out (i.e., element WS output parameters are compliant). DR(E1v 2 ) out
²
²
The allocated WS is invoked and the overall process execution can transparently resume without interruption. The other extreme possibility is that all the candidate WS are attempted and none of them was committed. Then, in such a case, a backward recovery is triggered by compensating all the committed elements and by aborting all the still-executing elements. In the case of the process P1 , OR(P1 ) indicates that the element E1v 1 , is the only element that preceded E1v 1 , hence, it will be compensated for by executing its compensating element E1v 1 . In scenario 2., we pointed out the importance of making the process stateful and we proposed to attach to the di erent elements a state. If we add a mechanism —like the one we introduced in [13]— that first, it stores in a particular location (i.e., in the entity responsible of the process execution) all the di erent DR. Second, it keeps track of the execution progress of the process by updating it on every change in any of the elements’ state. Then, we can have a history of the di erent executions of all the invoked instances. Furthermore, if we keep the history of all the invoked instances, we can have a stepby-step execution progress of all the process instances that we can analyze later to have valuable data about the failure reasonslocations [18]. The description of the process in terms of DR, CR, and OR provides the exact requirements to realize scenario 3. and scenario 4.. Assume that an analysis of the previous instances execution log has shown that the element E1v 3 is frequently the stage of failure. Assume also that a WS discovery query has shown that there are other newly added WS that satisfy the following conditions:
¼
DR(E1v 2 ) description DR(E1v 3 ) description DR(WS ) description (i.e., functionalities of the two-joined elements WS capabilities); DR(E1v 2 ) in DR(WS ) in (i.e., the input parameters of 1 st element and of the WS are compliant); DR(WS ) out (i.e., the output parameters of 2nd element and of the DR(E1v 3 ) out WS are compliant); DR(WS ) operation op1 op2 (i.e., op1 and op2 have same order semantics as E1v 2 and E1v 3 in OR(P1 )).
»
If these conditions are verified, then, we can transparently select one of the newlydiscovered candidate WS and allocate it to perform instead of (E1v 2 E1v 3 ); a new element’s DR and OR can be added. Similarly, to support scenario 4., we can explode an element transparently and map it to more than one WS, if required. We emphasize here that we are perfectly aware that the above described conditions in scenario 1., scenario 3., and scenario 4., defined for element-WS matchmaking are insuÆcient. We deliberately gave only simplified conditions that can be developed in a future work.
Dependability and Flexibility Centered Approach
177
Table 2. The formal notation of the di erent aggregation patterns Pattern
Notation
Pattern Notation
Sequence Rendezvous Selective merge Exclusive merge
(Ei k ; Ei k1 ) ((Ei k Ei k1 Ei k j ) Ei l ) ((Ei k Ei k j ) Ei l ) ((Ei k Ei k j ) Ei l )
Parallel Switch Selection Iteration
(Ei k ; (Ei k1 Ei k j )) (Ei k (Ei k1 Ei k2 Ei k j )) (Ei k (Ei k1 Ei k2 Ei k j )) (Ei k ; Ei k1 )
Since assessing the similarity of WS to achieve the best matchmaking is an active area of research, we can apply one of the available proposals ranging from keyword-based methods to ontologies and reasoning algorithm enriched methods. The vitality degree concept permits the fulfillment of scenario 5.. If the composite element E1v 5 becomes - , that is, we have: DR(E1 5 ) vitality - , DR(E1 5 1 ) vitality - , and DR(E1 5 2) vitality - , then, as the process runs, even when a customer does not reach the element E1v¯ 5 , the process execution will be committed successfully. With changing transparently the vitality degree, we can have di erent scenarios of the same process. Finally, these scenarios have shown that we can modify more easily and transparently the process logic by only handling its di erent DR, OR, and OR, exploding some rules, and joining others when required.
5 Discussion We discuss the contributions in dependability and flexibility enhancement provided by our approach against the Workflow-based composition approaches. For clarity sake, our discussion is based on a confrontation of the BPEL specification of the loan approval process with the specification of the same process we presented in the previous section. Yet, the same arguments are valid for the other solutions that follow the same Workflowlike composition strategy. Our model is more expressive than BPEL since we define three kind of notations: a textual notation, a graphical notation, and a formal notation. The textual notation can be more easily understood by a business analyst who typically does not have any programming experience and who has to update the business rules embedded in the process, which cannot be said about the syntax of BPEL. Our textual notation can be used as a higher level of abstraction on the top of BPEL. There is no universal graphical notation for a BPEL process but there are several proposals to use UML-like notation for descriptions. However, a standard notation is required to shorten the time necessary for understanding the process. In [19], authors presented an analysis of the di erent Workflow aggregation patterns that BPEL can support. To have a common comparison basis, we considered in this work the same set of patterns. The patterns defined by BPEL are a subset of the patterns supported by our specification model, and that we report in (Table.2); a detailed description of these patterns can be found in [20]. Our di erent notations are rich enough to depict all the di erent patterns that BPEL supports. This can be particularly helpful since the constructs defined by BPEL tend to be complex and their semantics are not always clear and can be sometimes misleading. For verifying the correctness of the WSC,
178
N. Ben Lakhal, T. Kobayashi, and H. Yokota
BPEL provides no way to verify correctness. Several tentative work have tried so far to formalize BPEL and they employ formalisms based on Pas [21]. However, BPEL is dealing more with implementation than specification. Thus, it is diÆcult to provide a formalism to verify the correctness of BPEL flows. To allow the analysis of our model, similarly, we introduced the CSP-like notation. We emphasize that the verification of our model is beyond the scope of this paper, and that we intended to provide a solid ground of comparison of our work with others proposal that use similar formalisms. The vitality degree concept allows introducing a higher flexibility. For instance, consider the listed BPEL process in (appendix A). The following listing shows how the vitality degree can be added: ”
” state”waiting” vitality”vital” ¡¡¡
” ” state”waiting” vitality”vital” ¡¡¡
” ” state”waiting” vitality”non vital” ¡¡¡
” ” state”waiting” vitality”non vital” ¡¡¡
If we change the vitality degree of the element E1v 5 from to - , the loan approval process can be used also as a simulation for loan request process. Since when the element E1v¯ 5 is - , the customer does not have to go up to its execution, and E1v¯ 5 failure or non invocation cannot a ect the overall process commitment. Similarly, the state concept can be attached to the di erent activities in BPEL and can provide very valuable information about the enactment progress of the di erent activities and of the process as a whole. Introducing the state concept can contribute to acquiring the information necessary for discovering the faulty WS and discarding them to improve the performances. Further details can be found in our previous work [18] about the state-guided failure analysis approach, we proposed. Finally, the specification of the process in terms of DR, CR, and OR allows a more flexible enactment. If we define in a higher level on the top of BPEL, a specification of the process in terms of DR, CR, and OR, and we provide the enactment environment with the possibility of regenerating dynamically the process definition, then we can achieve better results.
6 Related Work Making several entities work in tandem to reach a common goal is not a new challenge in itself since it has been widely addressed in several areas. In particular, mechanisms like the flexible process composition and decomposition —we propose in our approach— were also proposed in other areas. The database community introduced the notion of transaction decomposition into steps. A representative work is [22]. In their approach, the authors target was to increase concurrency whereas we target flexibility. In addition, they proposed mechanism based on two-phase locking, not suitable for the WS context. What is interesting about this work is that it directed our attention toward the importance of generating correct process decomposition, and how developers should obtain one; which can constitute a promising future direction for us. In the area of Workflow systems, massive research e orts were focused toward the need for flexibility at runtime to avoid seeing the Workflow execution stopped due to resources unavailability and to allow the users to deviate from the prescribed sequence of
Dependability and Flexibility Centered Approach
179
activities the Workflow definition imposes. The work reported in [23] exemplifies those works. This work presented a mechanism for choosing alternatives to sub-Workflows, thereby allowing the Workflow execution to resume when the predefined sub-Workflow is unavailable; which present some overlaps with the ideas reported in our paper. We can say the same thing about several formalisms from the area of AI, namely, planning techniques and problem-solving methods (PMS). The work in [24] described a framework that modeled a WSC as a PMS that describes how the WS is decomposed into its components. The concept of task decomposition in HTN (Hierarchical Task Network) planning is very similar to the concept of decomposition in our approach. The work [5] reported how to exploit AI planning techniques for automatic WSC by treating WSC as a planning problem. The SHOP2 system creates plans by task decomposition. This work focused mainly on translating OWL-S WS descriptions to a SHOP2 domain. This particular view oriented our attention toward the similarity between the concept of decomposition in our approach and the concept of composite process in OWL-S ontology. Our approach can complement this work with our di erent notations and especially with our transactional behavior and flexibility supports. In the area of WSC, [7] introduced WebTransact. To date, this work is one of the few that introduced a transactional support by defining a WS Transaction Language on top of WSDL enhancing it with functionalities facilitating transactional WSC. The main di erences between our approach and WebTransact are that, first, the WS are statically integrated in WebTransact by a developer who plays the role of WS integrator. Yet, this is not a flexible way. Second, WebTransact is mainly for integrating WS that have their own local transaction support, yet this condition is not always verifiable since not all WS have a transaction support, and not all of them are compliant. Our approach only supports compensatable, retriable, vital, and non-vital behaviors, but it is easily extensible with other transaction behaviors (e.g., pivot). Finally, WebTransact does not address the flexibility issue and it only provided an XML-based notation, hardly understandable and diÆcult to update. We consider also eFlow [3] and SELFSERV [4], where WSC are created dynamically. In eFlow, the definition of a service node encloses a service selection rule. When invoking the service node, the rule is executed to select a specific WS. eFlow supports dynamic process change by migration of process instances from a source schema to a destination schema. Concerning SELFSERV, it exploits the concept of service community, a container of alternative services. At run-time, when a community receives a request, it delegates it to one of its current members. Separating the service description from the actual service provider increases the flexibility. However, SELF-SERV does not support dynamic process changes such as adding new WS type to the WSC. SELF-SERV advocates the use of state-charts instead of formal specifications for easiness to use and modularity whereas eFlow used a proprietary notation.
7 Conclusion In this paper, we introduced a novel approach for a flexible and dependable composite WS specification. Our approach puts forward the view that WSC failures are not exceptional situations —as exposed by many, but it takes a radically di erent view by accepting that failures are inevitable for any WSC. In addition, we noticed that the
180
N. Ben Lakhal, T. Kobayashi, and H. Yokota
Workflow-based composition approach is at the core of the majority of the current solutions and we claimed that this line of thinking has yielded solutions that obey to some restrictions that do not meet modern IT environment requirements. We discussed various limitations caused by a Workflow-like composition approach. In our approach, we enriched the WSC model with several mechanisms that can add flexibility and dependability to the WSC but that are not part from the WS architecture pillars, namely, the state, the transactional behavior, the vitality degree, and the failure recovery mechanisms. We identified a process in terms of Definition Rules (DR) to provide the di erent components description, Composability Rules (CR) to inform about the relationship between the components, and Ordering Rule (OR) to define the ordering relationship between the components. We also introduced three notations: a graphical, a textual, and a CSP-like notation. Our approach can be seen as a higher layer of abstraction of the solutions proposed so far, since it can extend them to support WSC in more powerful way, with increasing level of flexibility and dependability. Our notations allow modeling WSC in a formal and concise way, which can then be used to verify the correctness of the WSC and reason on their semantics without hindrance from technical limitations of an XML-based notation. As for the execution environment, a distributed architecture, like the architecture we introduced in [13]. We can achieve the full potential of our approach since it provides the essential concepts to realize the described failure recovery mechanisms, and the dynamic and distributed execution. Currently, we are still working on an implementation of our proposed model. Our next steps will be finalizing the implementation, experimentally measuring its performances, and comparing it with other approaches. Acknowledgement. Part of this research was supported by CREST of JST (Japan Science and Technology Agency), a Grant-in-Aid for Scientific Research on Priority Areas from MEXT of the Japanese Government (#16016232), and the 21 st Century COE Program Framework for Systematization and Application of Large-scale Knowledge Resources.
References [1] IBM, Systems, B., Microsoft, AG, S., Systems, S.: Bpel4ws business process execution language for web services (2005) [2] Martin, D., al.: Owl-s: Semantic markup for web services. www.daml-s.org (2004) [3] Casati, F., Ilnicki, S., Jin, L., Krishnamoorthy, V., Shan, M.: Adaptive and dynamic service composition in eflow. In Wangler, B., Bergman, L., eds.: 12th inter. Conf. on Advanced information Sys. Eng. Volume 1789 of LNCS., London (2000) 13–31 [4] Benatallah, B.and Dumas, M., Sheng, Q.: Facilitating the rapid development and scalable orchestration of composite web services. Dist. and Parallel Databases 17(1) (2005) 5 [5] Wu, D., Parsia, B., Sirin, W., Hendler, J., Nau, D. In: Automating DAML-S Web Services Composition Using SHOP2. Volume 2870. LNCS, Springer-Verlag (2003) 195 – 210 [6] Sahai, A., Machiraju, V., Sayal, M., van Moorsel, A.P.A., Casati, F.: Automated sla monitoring for web services. In: DSOM ’02: Proc. of the 13th IFIPIEEE Int.Workshop on Distributed Sys., London, UK, Springer-Verlag (2002) 28–41 [7] Pires, P.F.and Mattoso, M., Benevides, M.: Building Reliable Web Services Compositions. In: Web, Web-Services, and Database Systems. Volume 2593. LNCS (2002) 59–72
Dependability and Flexibility Centered Approach
181
[8] Elmagarmid, A.: Database transaction models for advanced applications. Morgan Kaufmann, San Mateo, California (1992) [9] Khalaf, R., Mukhi, N., Weerawarana, S.: Service-oriented composition in bpel4ws. In: WWW (Alternate Paper Tracks). (2003) [10] Curbera, F., Khalaf, R., Mukhi, N., Tai, S., Weerawarana, S.: The next step in web services. Commun. ACM 46(10) (2003) 29–34 [11] Cabrera, F., et al.: Specification: Web services transaction (ws-transaction). http:www106.ibm.comdeveloperworkswebserviceslibraryws-transpec (2002) [12] Fujitsu, IONA, O., Sun, A.T.: Web services composite application framework(ws-caf). http:www.arjuna.comstandardsws-caf (2003) [13] Benlakhal, N., Kobayashi, T., Yokota, H.: Throws: An architecture for highly available distributed execution of web services compositions. In: IEEE 14th Intl. Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications (RIDE’04), Boston, USA, IEEE (2004) 103–110 [14] van der Aalst, W., Hofstede, A., Kiepuszewski, B., Barros, A.: Workflow patterns. Distributed and Parallel Databases 14(1) (2003) 5–51 [15] Aalst, W.: Don’t go with the flow: Web services composition standards exposed. IEEE Intelligent Systems 18(1) (2003) 72–76 [16] C.A.R.Hoare: Communicating Sequential Processes. Prentice Hall (1985) [17] Butler, M.J., Hoare, C.A.R., Ferreira, C.: A trace semantics for long-running transactions. In: 25 Years Communicating Sequential Processes. (2004) 133–150 [18] Benlakhal, N., Kobayashi, T., Yokota, H.: A failure-aware model for estimating and analyzing the eÆciency of web services compositions. In: IEEE 11th Int.Symp.on Pacific Rim Dependable Computing (PRDC2005), Changsha,China, IEEE (2005) pp.114–121 [19] Wohed, P., van der Aalst, W.M., Dumas, M., al.: Pattern based analysis of bpel4ws (2002) [20] Benlakhal, N., Kobayashi, T., Yokota, H.: A well-defined and failure-aware model for estimating the eÆciency of web services compositions. In: Proc. of IEEE Intl. Workshop on Challenges in Web Information Retrieval and Integration(WIRI) In conjunction with ICDE2005, Tokyo, Japan, IEEE (2005) 47–54 [21] Salan, G., Bordeaux, L., Schaerf, M.: Describing and reasoning on web services using process algebra. In: Proc. of Int. Conf. on Web Services, USA, IEEE (2004) 43 [22] Ammann, P., Jajodia, S., Ray, I.: Applying formal methods to semantic-based decomposition of transactions. ACM Trans. Database Syst. 22(2) (1997) 215–254 [23] Vieira, T.A.S.C., Casanova, M.A., Ferrao, L.G.: An ontology-driven architecture for flexible workflow execution. la-webmedia 00 (2004) 70–77 [24] Gomez-Perez, Gonzalez-Cabero, R., Lama, M.: Ode sws: A framework for designing and composing semantic web services. IEEE Intelligent Systems 19(4) (2004) 24–31
182
N. Ben Lakhal, T. Kobayashi, and H. Yokota
Appendix A. BPEL Specification of a Loan Request Process ”
”¡¡¡¡¡¡
” ” ” : ”
”” ”: ”
”” ”: ”
” ” ” : ” ” ” ” : ”
” ”¡¡¡” ”
” ”¡¡¡” ” ”
” ”¡¡¡” ” ”
”
” ” ” ”¡¡¡” ”
” ¡¡¡
” ”
”” ” ”¡¡¡” ” ”
”” ””
” ” ” ”¡¡¡
” ” ”” ” ”
” ” ” ”” ” ”” ”
” ” ” ”¡¡¡” ” ”
” ” ” ” ” ”¡¡¡ ” ” ” ” ”
