Model-Based Analysis of Obligations in Web Service Choreography
Howard Foster, Sebastian Uchitel, Jeff Magee, Jeff Kramer
Imperial College London,
180 Queen’s Gate, London SW7 2BZ, UK
{hf1,su2,jnm,jk}@doc.ic.ac.uk
Abstract
In this paper we discuss a model-based approach to the analysis of service interactions for coordinated web service compositions using obligation policies specified in the form of Message Sequence Charts (MSCs) and implemented in the Web Service Choreography Description Language (WS-CDL). The approach uses finite state machine representations of web service compositions (implemented in BPEL4WS) and service choreography rules, and assigns semantics to the distributed process interactions. The move towards implementing web service choreography requires design time verification of these service interactions to ensure that service implementations fulfill requirements for multiple interested partners before such compositions and choreographies are deployed. The described approach is supported by a suite of cooperating tools for specification, formal modeling, animation and providing verification results from choreographed web service interactions.
1. Introduction
A Web Services Architecture (WS-A) [1] is an emerging distributed software architecture that harnesses the flexibility and reach of the internet with that of extended distributed systems engineering practices. Web Service composition languages aim to fulfill the requirement of a coordinated and collaborative service invocation specification to support long running transactions and multi-service scenarios, yet composing these services alone does not fulfill the requirement of an assured collaboration in cross-enterprise service domains. Participating services must adhere to policies set out to support these collaborative roles in a WS-A with permissions and obligations constraining the interactions between services. Whilst policies are generally considered to be resource access based (e.g. security), obligations are equally important in ensuring collaboration is conducted in an appropriate manner and that the behavior exhibited by participating clients is suitable in a given scenario. This obligation issue is collectively wrapped up in the term Web Service Choreography [2]. In addition the design and implementation of service components in this architecture style must support the original policies as defined by the service owner. These interacting services can be constructed using emerging standards and managed by multiple parties in their domain of interest and as such the
task of linking these activities across workflows within this domain is crucial.
This work considers the obligations of services in a web services environment with the aim of verifying service implementations and their choreography rules against that of design specifications. We expand on our results from earlier work discussing verifying local web service compositions [3] against design specifications and providing compatibility analysis between compositions [4] both of which focused on the analysis and verification of behavior models of web service compositions implemented in the Business Process Execution Language for Web Services (BPEL4WS) [5]. In addition, we have provided tool support for this approach, which has been documented in [6]. In this paper we describe the formal approach to modeling and analyzing the behavior of web service choreography, defined in the Web Service Choreography Description Language (WS-CDL) [7] with that of interactions in web service compositions of BPEL4WS. The remainder of the paper is organised as follows: Section 2 describes a background to web services issues and Section 3 portrays our approach to a rigorous engineering of service compositions and a brief example. Section 4 and 5 describes building models of service compositions and choreography descriptions. In section 6 we describe verifying the choreography and compositions, with sections 7 and 8 reviewing and concluding this work.
2. Background
Obligation policies specify what activities a subject must or must not do to a set of target objects. The subject or target of a policy is usually expressed as a domain of objects and applies to all objects in the domain so a single policy can be specified for a group of objects [8]. In the domain of web services, the objects are service components that interact with one or more partners in the domain to fulfill a coordinated goal. To date, web service behaviour analysis has largely focused on the interactions between services from the viewpoint of checking that interaction cycles are completed between partners and that service logic is checked for completeness using safety and liveness properties (e.g. absence of deadlock). Web Service behaviour analysis consists of analysing two aspects of the web service architecture style. A web service formally exhibits its identity and permissible interactions through an interface definition in the form of the Web Service Description
Language (WSDL). Within the implementation for a web service however, the behaviour of its interactions is defined (i.e. the sequence and occurrence). The coordination of a service’s behaviour is formed from the basic operations of requesting, receiving a new request, replying to a partner or receiving the reply from a request and this forms the basis for service conversations as part of its behaviour towards an overall goal. Standards elaborate the specification of how, what and when these interactions can occur. The layers above the basic service are described through service compositions, choreography, transactions and policies. These standards can be aligned with that of parts of software process analysis, as illustrated in Figure 1.
SOAP WSDL XML Schemas XML BPEL, WSCI WS-Transaction WS-CDL, WS-CI Data Format Message Interface Orchestration Transactions Choreography
Layer Standards (W3C/OASIS)
Ser vi ces Compo sitions Software Process Behaviour (State) Identity
Input and Output WS-Policy, XACML
Policy Verification(Properties)
Val
ida
tio
n
Figure 1 Web Services Standards and Software Process Analysis
A policy in part, can be used to evaluate that a sequence of interactions (a choreography) between two services is allowable towards the given policy goal. Furthermore, by combining these parts of a policy, a set of permissible interactions between different related partners can also be evaluated. WS-CDL is one agreed standard for service choreography which describes choreography as “…re-usable common rules, which govern the ordering of exchanged messages and the provisioning patterns of collaborative behavior, agreed between two or more interacting parties.” These rules take the form of a choreography policy which defines the necessary work units (a set of activities to be completed as part of the choreography), document transfers (as part of the state) and reactions to state values passed between partners in the choreography. The aim of our analysis concentrates on the ability of services, and their underlying interaction behavior, to take part in a choreography environment given a specification. With an accurate analysis approach, the implementers of the choreography and compositions can be assured that interactions will be compatible with these rules and therefore match the requirements of interaction between partners. To illustrate how these interacting compositions are verified, we have constructed an example distributed process for a Payroll composition, consisting of a series of web services (for time and expenses, benefits, contributions and tax enquiries) interacting to complete a payroll activity. A basic MSC for this choreography is illustrated in Figure 2.
Payroll TimeExpense Benefits
partner services client Contributions timesheet req_te Req_Benefits req_cont contribution Req_Tax Tax_Rate benefits report_tax_income Tax_confirmed Tax
Figure 2 A Scenario of Interactions in a Payroll Service
3. Approach to Analysis
The ability to perform verification and validation between implementations and design, and within the process compositions themselves, is a key requirement of the web services architecture specification [9]. We portray this analysis through an approach to compare design specification models against that of implementation models (and vice-versa), and report back on obligations specified by either service designer or implementer that result in implied scenarios or property violations. The approach is illustrated in Figure 3. Tool Designers Validation validation results . models Deployers Implementers Specification verification results Composition Clients Verification Verified and Validated Services BPEL4WS implement ations Composition Processes Composition Semantics Requirements Web Service Standards MSCs BPEL4WS Specification Composition Specification Web Services Model Generation sy nthesi s ma pp in g ab st ra ctio n in te ra ctio ns verification properties validation traces Partner Service Interfaces
Figure 3 An approach to analysis of Service Compositions and Interactions
In this work a designer, given a set of service choreography requirements, specifies a series of MSCs to describe how the services will be used and to model how each service interacts (i.e. service conversations) in a given service scenario. Additionally, the obligations can be specified in the WS-CDL specification as a set of interactions with conditional exchanges of message (and their parts) between roles in choreography scenarios. The resulting set of scenarios is composed and synthesized to
generate a behavioral model, in the form of the FSP algebra and then compiled in to a Labelled Transition System (LTS). The implementation of service compositions providing one or more roles within this service choreography is undertaken by a service engineer who defines the sequences of interactions within each service role as part of the choreography enactment. Interaction processes can be implemented in the emerging standard of the BPEL4WS. In the approach these compositions are also translated to the FSP algebra and compiled in to LTS models. Through a process of abstraction and mapping, the composition interactions are combined to provide an architecture model of the cooperating services. The choreography model can then be compared with two or more compositions such that the interactions fulfill partner roles, and their obligations, as defined in the choreography specification (illustrated in Figure 4). Web Service BPEL4WS Process <invoke> Web Service Process <receive> Channel 1 <invoke> <receive> <reply> Channel 1 Channel 2 Partner A Partner B BPEL4WS Service Process <receive> <reply> Partner x... <invoke>Ch annel 1 Choreography Specification – (WS-CDL) Interaction <receive> Channel 2 Partner_A Partner_B request reply Scenarios State Transfer Obligations Policy Partner_B Partner_x request reply Implementation Design
Service Choreography Domain
Figure 4 Obligations Policy Design (MSC), Policy Implementation (WS-CDL) and Composition Interactions (BPEL4WS) in Choreography Domain
4. Web Service Composition Models
In our previously reported work [3,4], we have discussed modeling a service process as defined by a service composition, implemented in the standard of BPEL4WS. A process consists of a series of BPEL4WS activity statements, specifying the interactions between services and local logic to manipulate message data for these interactions. An
example process for payroll and benefits services is illustrated in structure form for a concurrent sequence of interactions between a Payroll process and its partners.
Figure 5 BPEL4WS Process Structures for Concurrent Interactions of Payroll and Benefits Services
The remaining services are built in a similar approach. The services are then translated into the FSP notation, where the semantics of BPEL4WS specification are given equivalent representation as processes in FSP (Figure 6). In FSP, processes are defined using the -> operator, sequences are represented using the sequence operator of ; and concurrent processes are defined using the parallel composition operator ||. The abstraction from the BPEL4WS is based upon modeling the sequence of interactions in the process, and enumerating the conditional elements which affect the possible paths of execution depending on values within messages. A full guide of BPEL4WS to FSP is given in [10]. A graphical LTS for the FSP is illustrated in Figure 7.
// Sequences after timesheets & benefits ---||FLOW1 = (PAY_TIME_SEQ || PAY_BENEFITS_SEQ).
PAY_TAX = (inv_payroll_tax_report_tax->END).
PAY_TAX_REP = (rep_tax_payroll_report_tax->END).
PAY_TAX_SEQ = PAYROLL_TAX;PAYROLL_TAX_REPLY;END.
PAY_SEQ1 = FLOW1 ; PAYROLL_TAX_SEQ; END.
// Parallel composition process ---||PAYROLL_BPELModel = (PAYROLL_SEQUENCE1).
Figure 6 FSP Processes for Concurrent Interactions of Payroll Service Composition
A secondary step is required to build a synchronization model between interactions of the compositions. In this way, we are examining the pattern of invoking a partner process, the receiving activity of the partner process and the reply message back to the requestor process. To achieve this we add a port connector process between the compositions by analyzing how they interact, from the viewpoint of each individual composition (Figure 8).
Figure 8 LTS of Synchronised Port Interactions
The result of modeling these compositions, and applying port connector models between compositions, is that we have a complete model representing the implementation of services carrying out one or many roles within the specification given earlier. This model represents the source for analyzing the behaviour of the implementations against the choreography design and implementation which we discuss in section 6.
5. Web Service Choreography
The choreography rules of the service interactions can be implemented in the WS-CDL specification language, and then potentially executed on a choreography engine. As part of this specification, the engineer can build the necessary interactions as control flows (resembling traditional structured control), work units (scoped repeatable activity sets) or basic activities (an interaction or a call to perform another choreography set for example). The interactions specified must be part of an agreed “cross service” scenarios. Whilst implementation of service compositions (implemented as an example in BPEL4WS in the previous section) could be developed with local logic and carried out by individual development teams, the specification must be agreed between groups concisely, and the behaviour specified between services must not only be compatible but also adhere to the choreography rules set. We examine here how the specifications, in WS-CDL form, are translated and modeled as a set of processes.
5.1 The WS-CDL Specification
WS-CDL provides a specification and language for defining rules of choreographed web service interactions. WS-CDL provides a layer above BPEL4WS coordinating partner interactions. A choreography package is created for each specification instance that is attributed to one or
more logical scenarios. Within this package, the partners, roles and relationships (in terms of relationship types - such as “buyer or seller “ roles) are specified for all exchanges between services participating in the interaction scenarios. A choreography sub-section of the specification then details a group of physical interactions between partners and data exchanges as messages are sent or received. The structure of a WS-CDL package is illustrated in Figure 9.
Package
Information
Type Tokens Choreography Roles Channels Relationships
Relationship
o
Variables Interaction
Participate Exchange Record
Figure 9 WS-CDL Specification Structure
The interaction construct is the key activity to expressing that an exchange of messages between two partners should occur. This interaction can be expressed as a request (to a partner of the choreography), a response (from a partner in the choreography) and a request-response (expecting a reply from a request between two partners). Although an information variable is defined as part of the exchange, WS-CDL also provides channels to describe a shareable variable storage in which partner requests or responses may be passed along. The control-flow aspects of the specification are represented by the three constructs of sequence, parallel and choice. These subsequently represent a sequential process and parallel composition of processes or a selective guarded process on one or more conditional elements respectively.
Although these constructs are also represented in BPEL4WS, in WS-CDL the basis for choice is dependent on the guard in question and whether that guard is data-driven (evaluation is based upon data values) or event-driven (that some event has occurred during the choreography). In addition, a work-unit represents a scoped block of activities which can be repeated and expressed as non-blocking or blocking (depending on whether the work-unit should wait for certain variables to become available). A guard encompasses the work-unit and when evaluated to true, the work-unit process is undertaken. Fault and exception handling is also provided in the form of designated work-units. These can be activated if a particular exception is discovered (such as an interaction failure in which the sending of a message did
not succeed or an application failure in the result of receiving a message which raises some application level exception). Under normal choreography running, a finaliser work-unit can be defined to perform some “end of choreography” activities (e.g. a final interaction which can only be undertaken when a choreography group has been completed).
5.2 WS-CDL to FSP
As with the translation from BPEL4WS to FSP, we provide a translation between WS-CDL and FSP processes by way of abstracting the choreography sets and interactions contained within these sets. The process considers each construct in the choreography tree and maps the construct with associated actions to represent the information contained within the constructs children. The process is iterative for each child in each tree of the choreography specification. For example, the choreography rules defined in Figure 10, is translated in to a set of processes to define each of the interactions as a set of invoke, receive, reply and synchronized invoke_reply (invrep) processes. This is sequenced in FSP to represent the ordering of an invocation and replying to an exchange. In Figure 10, we have also listed the FSP for this translation. Note that each interaction in a choreography group is built on the basis of a synchronized service connection. The parallel construct in WS-CDL is translated to a parallel composition in FSP using its || operator, whereby the PARALLEL1 process composes the sequences of interaction 1 (I1) and 2 (I2). Finally, another composition forms the group for the choreography (CHOREOGRAPHY1). Compiling this FSP into an LTS provides us with a model of the concurrent interaction rules for this choreography. With conditional choreography interaction rules, based upon the choice construct in WS-CDL, the FSP guarded variable operators provide a mechanism to represent alternative choices possible in the choreography model. This is similar to the representation for the switch.case construct in BPEL4WS.
5.3 WS-CDL Abstraction
Our modeling abstraction from WS-CDL concentrates on the interactions specified in the choreography groups of each specification. With other parts of the specification, namely for declarations of roles and relationships, we build a list and link of these from WSDL documents for the partner correlation between activities. This provides a consistent approach with that of BPEL4WS in labeling interaction activities. Information Types, Tokens and Channels are not considered in the modeling for interactions, yet may be as part of enhanced modeling at a later point in our work. In our analysis, we concentrate on the interaction sequences described in the WS-CDL and not on state transfer between partners through message passing.
// INTERACTION 1
I1INV_hVE = (inv_Payroll_Benefits_req-> END).
I1REC_hVE = (rec_Benefits_Payroll_req-> END).
I1REP_hVE = (rep_Benefits_Payroll_req-> END).
I1IVR_hVE = (invrep_Payroll_Benefits_req-> END).
I1_SEQ_INV = I1INV_hVE; I1REC_hVE; END.
I1_SEQ_REPLY = I1REP_hVE; I1IVR_hVE; END.
I1_SEQ = I1_SEQ_INV; I1_SEQ_REPLY; END.
||I1_COMP = (I1_SEQ). // INTERACTION 2
I2INV_hVE = (inv_Payroll_TimeExp_req-> END).
I2REC_hVE = (rec_TimeExp_Payroll_req-> END).
I2REP_hVE = (rep_TimeExp_Payroll_req-> END).
I2IVR_hVE = (invrep_Payroll_TimeExp_req-> END).
I2_SEQ_INV = I2INV_hAE; I2REC_hAE; END.
I2_SEQ_REPLY = I2REP_hAE; I2IVR_hAE; END.
I2_SEQ = I2_SEQ_INV; I2_SEQ_REPLY; END.
||I2_COMP = (I2_SEQ).
||PARALLEL1 = (I1_COMP || I2_COMP). ||CHOREOGRAPHY1 = (PARALLEL1).
Figure 10 WS-CDL Choreography (top) and translation to FSP (bottom) for Payroll Service
6. Analysis of the Service Models
We now consider how given a set of models representing design specification (MSCs), service compositions (BPEL4WS) and service choreography (WS-CDL), analysis of the models can be undertaken with a view of verifying that these models are consistent between design and implementations given particular properties of interest. The common approach to analysis is described and specific properties analyzed given different sets of models, for service choreography, compatibility and implementation analysis, and properties for analysis. For verification we analyse compositions of the models generated in earlier sections of this work. Additionally,
we also provide a mechanism for validation to assist in confirming the behaviour exhibited by a modelled composition, and allow the analyst or engineer to validate that the processes created are indeed the required behaviour for a solution to the requirements. In this section we discuss the techniques for both of these methods and provide examples of undertaking them. We portray this analysis through an approach to compare the design specification models against that of implementation models (and vice-versa), and report back on unfulfilled obligations specified by either service designer or implementer that result in implied scenarios or progress violations.
Verification is achieved through the use of formal software process model checking techniques. Firstly, we can check the behaviour of a composition or choreography is deadlock free (i.e. that there no states with no outgoing transitions). In a finite state model (such as the models we produced from design specification and implementations in earlier examples), a deadlock state is a state with no outgoing transitions in these models. The deadlock states we are interested in are those that arise from a parallel composition of concurrent activities in a single process, a number of interacting processes and one or many compositions against that of their design specifications. A breadth-first search of the model is then performed and trace results can be obtained of the activities taken from the start state to the state at deadlock. An example of a deadlock state in web service choreography is that two services are waiting to receive a message from each other. The processes of these services are clearly in a deadlock situation where one is awaiting the other, and will never transition past this state. Secondly, we can use safety
property checking techniques to determine if given model
properties are satisfied in one or many compositions. Safety properties used on complex systems are usually better stated as what is required, rather than stating what is not required [11]. We consider these properties in terms of verifying service choreography implementations against design specifications, checking obligations against choreography rules as part of service provision (in the form of service compositions) and checking composition compatibility between services in relation to the obligations specified in the choreography rules.
6.1 Verifying Choreography Implementations
Verifying the service choreography rules (specified in the WS-CDL implementation) consists of two aspects. Firstly, we can check the WS-CDL model for correctness against the MSC design specification model. To achieve this we compose the WS-CDL model and MSC models together, and append label mappings between the actions in one against the other. These mappings are specified by the engineer on the equal understanding of each activity. For example, in the payroll service example, we observed that the choreography rules specified two interactions from the
Payroll service to the TimeExpenses and Benefits services. The models, property and property check in FSP are illustrated in Figure 11.
// MSC as property to check WS-CDL model MSC_Arch = MSCArchitectureModel. WSCDL_Arch = CHOREOGRAPHY1.
deterministic ||DetModel = MSC_Arch. property ||P_MSCDetMSC = DetMSC.
||CheckWSCDL = (P_MSCDetMSC || WSCDL_Arch). // output of progress check
Trace to property violation in P_MSCDetMSC: invoke_payroll_timeexp_request
invoke_payroll_benefits_request reply_timeexp_payroll_request // MSC of trace to property violation:
Figure 11 Properties and Trace to Violation in WS-CDL Rules against Choreography Design Specification
The violation exists as the choreography permits a concurrent interaction of TimeExpenses and Benefits calls. The MSC design of this choreography however, currently only permits a single sequence in that order, and as such a Benefits call prior to TimeExpenses is not permitted. The result of this check is that the choreography engineer can discuss this requirement with the designer of the service choreography as to whether the design or choreography rules should change. Secondly, the choreography model itself can be checked for any potential deadlocks. The model of the WS-CDL implementation is analysed for any deadlocks using the method described previously, in that, a breadth-first search is performed and any states with no outgoing transitions are highlighted in a resulting trace. As with verifying choreography rules against design specifications, these can be represented back to the engineer in MSC form.
6.2 Service Obligation Verification
Service obligation verification provides a service engineer and any partnered services to check the suitability of service conversations in composition implementations against that of the obligations policy. This obligations check discovers if the conversations between compositions fulfils the rules set in the choreography specification. To compose a model for checking a series of interacting service compositions requires that the “interaction verification” (discussed in section 6.1) has been successful. An example undertakes these two steps to illustrate how the models are built and analysed. The steps to check for obligations verification is for checking composition interactions against those specified in the WS-CDL implementation. Given a series of interacting models formed from BPEL4WS implementations (such as that
used previously for service conversation obligations analysis), the approach can be used to check that the possible interactions exhibited by these compositions fulfills the rules specified in the choreography sets. An example of the payroll services case study is as follows. Given three models of interacting services, in this case the Payroll, Benefits and TimeExpenses enquiries, a composed model of interactions is compiled. This composed model is then used as a property against the choreography rules. A property check can reveal whether the service composition interactions comply with the rules set out in the choreography by equivalent interaction traces. Furthermore, any additional interactions which are exhibited between the partners in the compositions are highlighted back to the engineer. Below we have given the FSP for building a deterministic model of the WS-CDL model and then specified this as the property for analysis.
// specify WS-CDL as property to check against service composition interaction model ||WSIntModel = (Payroll||Benefits||TimeExps). WSCDL_Arch = CHOREOGRAPHY1.
deterministic ||DetModel = WSCDL_Arch. property ||P_DetCDL = DetModel.
||CheckWSCDL = (P_DetCDL || WSIntModel).
The source of the composed composition models (WSIntModel) is composed with this property to use in the trace of any violations. In this case, a trace will observe no violations. The reason for this is that although the Payroll service interacts concurrently with other partnered services, the choreography rule of “Benefits or TimeExpenses” is still upheld. The other interactions in the Payroll are “silent” to the choreography rules. Interestingly, we can also reverse this approach to check what other traces are permissible given the composition model as a property to check against the WS-CDL. The second example listed in Figure 12 provides this example. In this case, the reason for the violation is that the BPEL4WS permits an invocation of Benefits to Contribution service, yet the WS-CDL rules do not. The verification approach for specifying obligation policies, building web service compositions and implementing policies in WS-CDL have been built into an Eclipse plug-in (Figure 13). The plug-in is based upon a core Labelled Transition System Analyser (LTSA) [11] built by Jeff Magee of Imperial College London.
7. Related Work
In addition to our work, the WS-CDL specification has been modeled using the pi-calculus algebra [12] and tools are available to generate WS-CDL from models in the form of (XML) tree diagrams. One reason for using pi-calculus has been discussed towards that of the availability to express mobile processes. The concept is to express choreography channels that “move” between partners as state changes. Also, there are approaches to generate
BPEL4WS templates from WS-CDL specifications [13, 14]. Other earlier work also considered other choreography specifications [15], yet WS-CDL has gained more popularity since it was published. For our initial work, FSP process algebra provided a clear and easily machine-readable notation for representing interactions as processes. This, together with the availability and extendibility of our scenario-modeling tools, proved highly valuable in delivering a mechanical solution for our approach.
// specify composition interaction model as property to check against WS-CDL policy
||WSIntModel=(Payroll || Benefits || TimeExps). WSCDL_Arch = CHOREOGRAPHY1.
deterministic ||DetModel = WSIntModel. property ||P_DetCDL = DetModel.
||CheckWSCDL = (P_DetCDL || WSCDL_Arch). // output of progress check
Trace to property violation in P_DetCDL: invoke_payroll_timeexp_request reply_timeexp_payroll_request invoke_payroll_benefits_request invoke_benefits_contributions_request
// MSC of trace to property violation:
Figure 12 Checking Properties and Trace to a violation using BPEL4WS compositions and WS-CDL rules.
8. Conclusions and Future Work
The main contribution of this paper is to provide an approach to analyzing choreography rules and service implementations against design specifications, which we have implemented within a tool, and demonstrates a mechanical verification of properties of interest to both designers and implementers. The use of a formal, well defined, process algebra (in this case FSP) provided a semantic mapping between the composition implementation (in the BPEL4WS specification for web service compositions), and we were fortunate to be able to leverage some work in [16] for the synthesis of design specifications, in the form of message sequence charts, to the same process algebra. For future work, we wish to continue describing compositional behaviour by elaborating on the wider choreography aspects of partnered services. This includes considering WS-CDL policy generation from MSC designs, and modeling compensation and transactional integrity within and between distributed processes. The authors would like to acknowledge that this research was supported, in part, by the EU SENSORIA project and by an IBM Eclipse Innovation Award 2004 &2005.
LTS Draw View Machine and Animator View Composition Outline Compiler and Log Output MSC Editor BPEL4WS Editor WS-CDL Editor
Figure 13 LTSA-Eclipse: The Choreography Analysis Approach Implemented in an Eclipse plug-in
9. References
[1] W3C WS-A Group, "Web Services Architecture (WS-A)," vol. 2004: W3C Working Group Note 11 February 2004, 2002.
[2] S. Daniel Austin, A. Barbir, E. Peters, and S. Ross-Talbot, "Web Services Choreography Requirements - W3C Working Draft," 2004.
[3] H. Foster, S. Uchitel, J. Magee, and J. Kramer, "Model-based Verification of Web Service Compositions," presented at Eighteenth IEEE International Conference on Automated Software Engineering (ASE), Montreal, Canada, 2003.
[4] H. Foster, S. Uchitel, J. Magee, and J. Kramer, "Compatibility for Web Service Choreography," presented at 3rd IEEE International Conference on Web Services (ICWS), San Diego, CA, 2004.
[5] F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, and S. Weerawarana, "Business Process Execution Language For Web Services, Version 1.0," 2002.
[6] H. Foster, "LTSA-BPEL4WS Tool." Department of Computing, Imperial College London: Available to
download at http://www.doc.ic.ac.uk/ltsa/bpel4ws, 2003b.
[7] N. Kavantzas, D. Burdett, G. Ritzinger, T. Fletcher, and Y. Lafon, "Web Services Choreography Description Language Version 1.0 - W3C Working Draft 17 December 2004," 2004.
[8] E. Lupu and M. Sloman, "Conflict Analysis for Management Policies," presented at Proceedings of the Fifth IFIP/IEEE International Symposium on Integrated Network Management, San Diego, CA, 1997.
[9] D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, and D. Orchard, "Web Services Architecture (WS-A) - W3C Working Group Note 11 February 2004," vol. 2004: W3C Web Services Architecture Group, 2004.
[10] H. Foster, "Mapping BPEL4WS to FSP, Technical Report," Imperial College, London 2003.
[11] J. Magee and J. Kramer, Concurrency - State Models and
Java Programs: John Wiley, 1999.
[12] S. Ross-Talbot, "Web Services Choreography and Process Algebra," SWSL Committee: Working Materials, 2004. [13] M. Hafner and R. Breu, "From Inter-Organizational
Workfows to Process Execution: Generating BPEL from WS-CDL," presented at ACM / IEEE 8th International Conference on Model Driven Engineering Languages and Systems, Montego Bay, Jamaica, 2005.
[14] M. Bravetti, C. Guidi, R. Lucchi, and G. Zavattaro, "Supporting e-commerce Systems Formalization with Choreography Languages," presented at The 20th Annual ACM Symposium on Applied Computing (SAC05), Santa Fe, New Mexico, 2005.
[15] A. Brogi, C. Canal, E. Pimentel, and A. Vallecillo, "Formalizing Web Services Choreographies," presented at 1st International Workshop on Web Services and Formal Methods (WS-FM 2004), Pisa, Italy, 2004.
[16] S. Uchitel, "Incremental Elaboration of Scenario-Based Specifications and Behaviour Models Using Implied Scenarios," in Distributed Software Engineering. London: Imperial College London, 2003.
