trace verification process to be performed. By providing early design verification and validation, the implementation, testing and deployment of web service.
Tool Support for Model-Based Engineering of Web Service Compositions Howard Foster, Sebastian Uchitel, Jeff Magee, Jeff Kramer Department of Computing, Imperial College London, 180 Queen’s Gate, SW7 2BZ, UK {hf1, su2, jnm, jk}@doc.ic.ac.uk Abstract In this paper we describe tool support for a modelbased approach to verifying compositions of web service implementations. The tool supports verification of properties created from design specifications and implementation models to confirm expected results from the viewpoints of both the designer and implementer. Scenarios are modeled in UML, in the form of Message Sequence Charts (MSCs), and then compiled into the Finite State Process (FSP) algebra to concisely model the required behavior. BPEL4WS implementations are mechanically translated to FSP to allow an equivalence trace verification process to be performed. By providing early design verification and validation, the implementation, testing and deployment of web service compositions can be eased through the understanding of the behavior exhibited by the composition. The tool is implemented as a plug-in for the Eclipse development environment providing cooperating tools for specification, formal modeling and trace animation of the composition process.
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, such as the Business Process Execution Language (BPEL4WS)[2], aim to fulfill the requirement of a coordinated and collaborative service invocation specification to support service orchestration and multi-client scenarios. However, a composition 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 and access control permissions), 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 issue is collectively wrapped up in the term Web Service Choreography [3]. 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 various 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. Therefore, of clear interest is the need to support such engineering tasks as process verification, partner service usability, and other property checking to verify the roles of web service users and their actions [4]. There is also high value in providing a simulated process mechanism to visually compare expected with simulated results of a process invocation which can increase expectations of a successful outcome prior to deployment [5]. In this paper, we elaborate on the approach discussed in our earlier work on web service composition verification [6, 7] and illustrate an implementation of the approach in Eclipse to support mechanical engineering tasks that aid designers and implementers of web service compositions.
2. Background Web Service compositions and choreography provides additional layers above basic service invocation whereby collaborative client scenarios enables the differing uses of these services in a wider cross-enterprise domain. This is seen as an important element of making web services viable for wide spread use, and to provide a closer representation of business transactions in cross-domain enterprises. The effect of using earlier architecture styles has been prone to issues of semantic failure and difficulties in providing the necessary compensation handling sequences [8]. This has been attributed to the strict binding of services with specific technologies. Where previously designers of a workflow had to work very closely with the developers of the technical solution, we now have a mechanism to support technology independent workflow service invocation. This provides an opportunity for the designers to concentrate on exactly what is required from a workflow without hindrance from technical limitations implementation effort. One key part of the verification in this context is to check the trace equivalence with reference to the actions of the design specification, and specifically how sequencing multiple service conversations is achieved. Whilst there have been other attempts to use model-checking techniques for reliable web service verification, such as in [9-11], there
has been little published on the process of using Message Sequence Charts (MSCs) for composition specifications and combining these with composition implementations to verify and validate service behavior against those specified in the requirements.
3. The Approach Our approach, illustrated in Figure 1 and fully described in [6], is undertaken as follows. A designer, given a set of web service 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. The resulting set of scenarios is composed and synthesized to generate a behavioral model, in the form of the Finite State Process (FSP) algebra [12] and then compiled in to a Labelled Transition System (LTS). Requirements validation results
Tool
validation traces
Designers
Composition Composition Specification
mapping
Composition Processes
.
abstraction
Implementers
WS BPEL4 tations en implem
Model Generation synthesis
Composition Semantics
MSC s
BPEL4WS Specification
interactions
Web Service Standards
Validation
Multi-page Editor Verification verification results
Services
MSC Editor View
FSP Editor View
translate view
Verified and Validated
Deployers
The tool to support our approach, was originally written as a prototype plug-in to the existing LTSA tool suite [12]. This provided the groundwork for a Java implementation that collaborated in other extensions to the suite, such as the MSC editor and graphical LTS Draw functions, and which could contribute to future extensions. LTSA uses the FSP to specify behaviour models. From the FSP model, the tool generates a LTS representation. The user can animate the LTS by stepping through the sequences of actions it models, and model-check the LTS for various properties, including deadlock freedom, safety and progress properties. The MSC extension builds on this introducing a graphical editor for MSCs and by synthesising FSP specifications from scenario descriptions [13]. FSP code is generated for architecture, implied checks and constraint models. LTSA model checking capabilities (for safety, deadlock freedom and general property checks) are then used to detect implied scenarios. Our extension to this framework is built in the commonly known model-view-controller pattern, and its architecture illustrated in Figure 2.
models
verification properties
Partner Service Interfaces
4. Tool Architecture
compose
BPEL Editor View translate
view
Web Services Clients
Figure 1 An Approach to Rigorous Web Service Composition Development The service implementation is undertaken by a BPEL4WS engineer, who builds BPEL4WS processes directly from either specification or requirements. The BPEL4WS implementation and their semantics are used to generate a second behavioral model by a process of abstracting the BPEL4WS with respect to data, and to yield a model of interaction based upon specified semantics applied to BPEL4WS through the FSP algebra. Verification and validation consists of comparing and observing traces of these two transition systems. The approach can assist in determining whether the implementation contains all the specified scenarios of the design and whether any additional scenarios exhibited by the implementation are acceptable to the end-user. In addition, checks can be made on the models with respect to desirable general global properties such as absence of deadlock and liveness (using model-checking). Feedback to the users is in the form of MSCs. The approach is to hide the underlying Labelled Transition System (LTS) representations and let the user view only the BPLE4WS specifications or the MSCs as a simple intuitive and visual formalism accessible to most engineers [13].
MSC Synthesis
BPEL Translator
LTSA results
lts
Result Views Compiler View
view
LTS Draw View
state
LTS Animator
action
Figure 2 Tool Component Architecture The core implementation model is the BPEL4WS XML source code, and is used as source in editing in the form of a standard XML editor. The model is also parsed to provide useful editor functions, such as content outline and syntax highlighting. Additionally, a list of observable interactions is built upon restore or save actions, whereby a translation function is called to view activities specified in the composition. The BPEL4WS engineer is able to build one or many web service compositions in the editor, which aids in enterprise service decomposition. For each composition selected, the engineer can either translate a single composition or compose multiple compositions for choreography and translate them in to FSP by way of changing editor views. The translation module is written as an independent module (itself potentially a web service), which takes as input a BPEL4WS implementation and in turn, traverses the source building a representation model in FSP.
5. Tool Components 5.1. Service Composition Specifications The scenario based design approach has been a popular technique to capture user requirements by way of story telling [14]. This method provides a simple yet concise tool for describing how actors (clients), components (services) and messages (conversations) are composed together to complete one or more system goals. It has commonly been used in the past for describing interactions by system users [15] however, the actors can also represent any agent or service that interacts with the system being described by way of activities. Basic MSCs (bMSCs) are useful for describing compositional activities, illustrating partial system behaviour by defining sequences of messages between components, and providing information of interaction state. Figure 3 describes a sample scenario as specified for a loan approval web service composition. A customer makes a new loan request. The request needs to be evaluated by a loan assessor who considers whether the risk of the loan is low (where the loan requested is less than 10000) or high (where the request is for 10000 or more). If the assessment is low then the lowest rate of two loan providers is sought and a reply is sent to the customer following approval. If the assessment is high risk then the customer is asked to apply through an alternative process. Figure 3 Initial Requirements for Loan Approval Service The scenario proposes a domain of services with possible instances of services for a customer, an assessor, an approver and two loan providers. When modeling a description of the concurrent distributed processes, we list the interactions between the system's environment and external systems, labeling the interactions scenario-byscenario. In the tool, a MSC editor provides such a scenario specification interface, whereby the designer of the web service composition can specify the interactions required by either an individual composition, or through collaboration with other service partners (for choreography interactions). A view of one such scenario for the Loan Approval example is illustrated in Figure 4. A set of scenarios can be composed together using High Level MSCs (hMSCs) which provides a complete model of composed alternative scenarios. Thus the product of this step in the approach is a clearly defined set of interactions which are possible given different states in the composition specification. An elaboration of requirements yields additional scenarios for the specification. The amendment to the original specification is focused on providing additional scenarios of permissible concurrency of interactions following the initial service requests, in this
Figure 4 Service Composition Specification as built in the LTSA-WS MSC Editor case that the two loan providers can be requested for loan rates. The concurrency requirements pose a series of questions over that of the behavior constructed initially. Firstly, how does the introduction of this concurrency effect the remaining interactions of the composition? Clearly, by introducing the possibility that two service requests can be performed concurrently suggests that a series of actions may or may not occur within the duration of these initial service requests. Furthermore, can the response from each of the service requests based for loan providers exist over the entire duration of the composition? The designer revisits the specification of the original composition sequence and specifies further sceneries by way of adding bMSC specifications to the design model (such as illustrated in Figure 5). In addition to the MSC editor, the tool provides a mechanical synthesis of the scenarios and their high level composition in to a model in the form of processes defined in the Finite State Process algebra. This model can then be compiled in to an LTS and analysed for properties of interest (which we discuss in later sections of this paper). An LTS for a composed set of scenarios in the composition design specification is illustrated in Figure 6. client
services
Customer
Assessor
LoanProvider1
LoanProvider2
Approvor
request quote_rate_1 quote_rate_2 loan_rate_1 loan_rate_2
Figure 5 Partial View of Secenario for Concurrent Loan Approval Behaviour
Figure 6 LTS of possible invocation paths in Loan Approval Composition Specification
5.2. Service Composition Implementations The implementations in this example of the approach, take the form of BPEL4WS processes. The requirements are built as processes by a BPEL4WS engineer who interprets the necessary composition and choreography forms of the services involved. We consider how the BPEL4WS engineers would undertake implementing and verifying these compositions in our tool. The processes that form the compositions consist of a series of BPEL4WS process statements, specifying the interactions between services and process logic to manipulate message data for these interactions. To re-illustrate the iterative development in the example using our approach, the implementation begins by building the initial process, where all the interactions are sequenced, as illustrated in Figure 7. The sequence consists of an initial “receive” followed by three invocations, one for each of the enquiry services involved. Each receive or invoke activity, for example the initial request by the customer, is undertaken in the order specified in the sequence. The begin and end of the process is marked by the receive, and a final activity of a reply, before the process terminates. Each new request by an customer creates a new instance of the process, signified by the createinstance attribute on the initial receive activity. In addition to the interactions, the process composition is also modeled with variable assignments.
Concurrency analysis suggests that linking of activities is required to fulfil the remaining set of scenarios, for example, detailing the constraint that the loan provider requests may only be made once the receive activity has been made and that the request to the approver may only follow both of the loan provider requests. The engineer therefore adds a source link to both of the loan provider invocations and a target link to the approver service invocation activity. The engineer completes the process with a concurrent wrapper around the linked invoked services using the BPEL4WS element. The updated, potentially a first release composition, is illustrated in Figure 8.
Figure 8 BPEL4WS Process structure for concurrent set of interactions
Figure 7 BPEL4WS Process structure for basic sequence of interactions
The BPEL4WS implementation (in XML source code), is used to manage editing in the form of a standard XML editor. The xml is parsed to provide useful editor functions, such as content outline and syntax highlighting.
Parsing is also performed upon restore or save actions, whereby a translation function is called to translate the BPEL4WS to the FSP algebra. The BPEL4WS engineer is able to build one or many web service compositions which aids in enterprise service composition. For each composition selected, the engineer can either translate a single composition or compose multiple compositions for choreography and translate them in to FSP by way of changing editor views. The translation module is written as an independent module (itself potentially a web service), which takes as input a BPEL4WS implementation and in turn, traverses the source building a representation of its interactions in an FSP model. The mapping from BPEL4WS to FSP has been reported partially in [6], although a full guide is given as a technical report in [16]. Our tool provides both BPEL4WS and FSP views, selectable by switching views in the editor. When the BPEL4WS engineer is satisfied that sufficient detail has been built in the processes, the FSP models can be compiled into a LTS. An LTS for the loan approval composition is illustrated in Figure 10.
5.3. Elaboration for Service Choreography Choreography describes the peer-to-peer collaboration between participants with designated roles in service choreography. Choreography makes use of interaction and activity notation to define the relationships, which represents message exchanges between two web services participants. Web Service Choreography differs from Web Service Composition in compositions are viewed locally, in other words, it is a view of a local process which interacts with other services to complete its own goal. Web Services Choreography explores the relationships, constraints and liveness of a series of interactions between two or more partners in a wider goal and with a standard (such as Web Service Choreography Description Language (WS-CDL) [17]) the aim is to provide a technology independent method of describing these through state collaboration and awareness at a higher level than the composition itself.
Figure 9 BPEL4WS Process and BPEL4WS FSP views in tool WS-CDL suggests providing a design specification for choreography, which in turn is used for defining a contract for composition interactions. In the tool, the designer specifies choreography interaction rules by expanding on the composition specification given earlier to include cross composition interactions where no one composition is the single point of view. For example, in the loan approval composition the approval service may consist of other services, such as an authorization or credit check. Initially the view of composition may only suggest that a reply is necessary, yet in the wider context, the credit check will also have its own process which affects the result of enacting the complete process for loan approval. An additional choreography scenario is illustrated as a bMSC in Figure 11. Here, the designer has specified the interactions between the approver and credit_check services. Notice that this scenario only specifies a positive credit check, and that an additional choreography scenario would be that the credit_check service replies with a failed check. The engineer must observe these choreography requirements by completing the necessary behaviour in a set of compositions. In the tool, multiple composition translation includes interaction mapping by employing a choreography linking algorithm[16] to check partner links between a services and to analyse the partner interfaces to link interface specifications, as depicted in Figure 12.
Figure 10 LTS of concurrent interactions in BPEL4WS Process for a Loan Approval Service
client
services
Customer
Assessor
LoanProvider1
LoanProvider2
Approver
Credit_Check
request quote_rate_1 quote_rate_2 loan_rate_1 loan_rate_2 loan_approval check_credit
implemented in the tool providing a mechanical linking between activities, partners and process compositions. At this stage in undertaking the approach and utilizing the tool built to support it, the designers and engineers have model representations of the specification and implementation of the web service composition and choreography interactions. We now consider how these models are used to enable analysis for completeness and correctness.
credit_ok loan_approved
5.4. Preparation and Abstraction
reply
choreography
Figure 11 Specification for Choreography of loan approval process and a credit check service
Model Generation mapping
abstraction
synthesis
interactions
Partn er S Interf ervice aces tio nta me ls ple de Im Mo
n
Specifications
Composition Interaction Analysis
Composition Mapping
Non-interaction Undefined Activities Process Refs
Figure 12 Partner interaction analysis sub-tasks as part of service choreography in the tool
validation results Desig n Mode ls
Model Generation mapping
abstraction
synthesis
interactions
The algorithm is described as follows. For every composition process selected for modeling we extract all the interaction activities in this process. As mentioned previously, interaction activities are service operation invocations (requests), receiving operation requests and replying to operation requests. In addition to an invocation request, we also add an invocation reply to synchronise the reply from a partner process with that of the requesting client process. The list is then analysed for invocation requests, and for each one found a partner/port lookup is undertaken to gather the actual partner that is specified in a partnerlink declaration. To achieve this, a partner list is used and the partner referenced in invocation request is linked back to a partnerlink reference. The partnerlink specifies the porttype to link operation and partner with an actual interface definition. To complete the partner match, all interface definitions used in composition analysis are searched and matched on porttype and operation of requesting client process. This concludes the partner match. A port connector bridge is then built to support either a simple request invocation (with no reply expected) or in “rendezvous” style, building both invoke/receive and reply/invoke-output models. This supports the synchronous model mapping. The sequence is then repeated for all other invocations in the selected composition process, and then repeated again for any other composition processes to analyse. This algorithm is
Our approach to modeling in the tool, has at its core; synthesis, mapping and abstraction. We describe the model abstraction steps for web service compositions consisting of a series of tasks given input from the synthesis of initial design and implementation models and specifications and semantics of the processes modeled. The composition model abstraction is illustrated in Figure 13. The process of abstraction is decomposed in to analysis of non-interaction activities in implementation (reduction), joining actions between design and implementation through specification semantics (grouping) and linking interactions between compositions through service interface models (further mapping, discussed in the previous section). The tasks of abstracting implementation specific activities, labeling appropriately in service interaction activities, hiding implementation specific activities and mapping between implementation and design composition models provides a typical set of characteristics in abstraction for model verification and Through the tool, the MSC validation [18, 19]. specification synthesized to FSP using the LTSA-MSC plug-in can be included in the composed model. To enable this, a visual mapping table is available to the implementer to link activities in design and implementation.
Specifications And Semantics
Im
tio nta me ls ple ode M
validation traces
Understanding
Analysis and Abstraction
n
Non-interaction Undefined Activities Process Refs
n positio Com ing Mapp Verifi ca Mapp tion ing
Validation models
Verification verification properties
verification results
Figure 13 Model Preparation and Abstraction subtasks implemented in the tool The output of the abstraction steps are enhanced models including mapping information that can be used for joining composition process models, reducing the activities which are considered in the behavior analysis and verifying models of design against implementation models. The inputs to behaviour abstraction are the models from synthesis of a design and models from the translation of
implementation discussed in the previous chapter. In addition to these models, the composition standards specifications and designer semantics are passed on through to assist in analysis of the model-checking techniques discussed later in this chapter. As highlighted previously, the composition standards are formed from the BPEL4WS specification, providing syntactic standards and suggesting semantics of how BPEL4WS processes are defined, implemented and formed and provide information on those activities which are candidates for reduction. The WSDL specification also provides semantics of service binding and linking with BPEL4WS partner interface extensions.
5.5. Verification Verification is achieved through the use of model checking techniques and we evaluate specific topics of our approach for web service compositions by wrapping and applying these techniques under the notions of trace equivalence (implementation exhibits necessary behaviour to fulfill requirements of the design), compatibility checking (activities correlate invocations against receives and replies), and other general policy checking All three of the above areas of verification can be applied to both web service compositions and web service choreography. The focus of which one, is specified by way of selection of one or many processes in the analysis steps, and the intention of how the properties are declared. For example, if one composition is selected for analysis then compatibility checking would be limited to analysing the sequence of activities in just that one process (for asynchronous invoke and receive activities for example). If however, multiple compositions are selected, then this may include checking activities that can be synchronised to form a choreography interaction analysis. The parallel composition that is composed from web service composition interactions can be built either from a single or multiple-process viewpoint, depending on the criteria used at analysis time. In essence, verification is selective depending on the viewpoint required of compositions or choreography. The approach is illustrated in Figure 14.
by the main LTSA model-checking module. An output view summaries actions undertaken by the LTS compiler, and reports on property violations, such as deadlock, liveness or other safety properties. For example, to check that an composition or choreography implementation fulfills the requirements as specified in the MSC designs, the tool can perform a trace equivalence on the set of models and provide violation results back to the user in the form of further MSC scenarios. Implied and counterexample scenarios provide usefully rich information on what the implementation provides over or indirectly to that of the design specifications. The result of such verification, performed on the choreographed processes that were illustrated in Figure 11, are illustrated back to the engineer in Figure 15. The reason for this deadlock is suggested by the lack of the second loanprovider2 reply. In this case the engineer can refer back to the implementations and discover whether the error is due to incorrect sequencing of interactions. client
services
Customer
Assessor
LoanProvider1
LoanProvider2
Approver
request quote_rate_1 quote_rate_2 loan_rate_1 loan_approval
Figure 15 Violation exhibited from a trace equivalence check on the Loan Approval example Using the tool, the engineer or designer can trace all interactions back to the compositions and amend the interactions to fulfill the reply and complete the conversation models. The process of verification, as with evolutionary design and implementation is an iterative feature of the approach and as such repeated verification can assure the engineer that sufficient composition and choreography detail has been specified.
validation traces De Mo sign de ls
Validation
mappings
Verification
Equivalence / Bisimulation
pings
Implementation Models on ati rific ties Ve oper Pr
Verification / Checking
Interface Compatibility Progress (Liveness)
Model Compilation and Traces
M ap
models
Verification results
verification properties
Figure 14 Verification analysis sub-actions undertaken in the tool Results of checks provide implementers and designers with useful details such as missing interaction cycles (e.g. a missing receive or reply action). Checks are undertaken
5.6. Validation The validation approach consists of taking as input the same inputs that were used in verification analysis, but with the exception that a set of validation properties are known by the person who is undertaking the validation, rather than a machine process-able set used in verification. Therefore the inputs are the design models, implementation models and mappings. The process of validation is split between a focus of animation, simulation or an interactive trace. The output of the validation
process is set of results related to the validation properties used (for example, a general property would be that the behaviour defined in the models provides sufficient behaviour to support the initial requirements given). The sub-actions of our approach are illustrated in Figure 16. validation traces De Mo sign de ls
Validation Map
Verification
on ati lid s Va race T
Validation Analysis
Simulation
Validation Assessment
Implementation Models
mappings
Animation
pings
models
Validation Results
Interactive Trace
verification properties
Figure 16 Validation analysis sub-actions undertaken in the tool Validation is a technique for ensuring that the right product is built, or in this case, that the service compositions being specified provide suitable behaviour of that to fulfill the needs as detailed in the requirements given. In a similar way to that of verification we present (or abstract from the implementation models) the interactions back to the user in a form easily accessible to determine if the behaviour given has been interpreted correctly. We begin by illustrating this through animation of the loan approval composition example discussed earlier. As we have shown previously, the police enquiry composition may come in two forms, either in that of a design or implementation. The behaviour model is a key output of design or implementation synthesis, and is the source model used in validation animation. Given a composition behaviour model, the user may step through the sequence of observable actions in this model. An example validation sequence performed using the Animator feature of the LTSA tool is illustrated in Figure 17.
Here, the user steps through each state of the composition design (from state 1, labelled “request” in this example, to the end state “endAction”). Whilst the sample given is just one sequence, more complex compositions may introduce alternative paths to the end state (such as the model presented earlier in Figure 6. For example, in the loan approval composition the alternative paths are that either the first loan provider a second loan provider may be invoked first after a request is received. The user can animate these alternatives and confirm the expected results following each path.
6. Evaluation 6.1. Review of Related Work Several tools have been reported as part of the formalising and modelling work discussed in previous sections. In [9], a tool for analysing and verifying interactions among web services is supported. The mechanism is based upon conversation modelling (interactions of messages passing between processes) using both BPEL4WS and a formal conversation representation (in the form of GFSA) to describe verification properties to be analysed. The GFSA is then translated to the PROMELA language, which can then be verified in the SPIN tool. In [20] the BPE-Calculus is incorporated into the Concurrency WorkBench (CWB) tool. The CWB presents a new view to analyse the compositions specified in the BPE-Calculus. We believe that the end-user (i.e. the BPEL4WS engineer) would ideally require that the view of the verification tool or process algebra compilation is hidden from the development process, which encourages us to develop the verification toolset to support automated, background compilation of BPEL4WS processes and present findings back in the way in which design specifications were constructed (e.g. in MSC form). There are also some examples in the modelling of standards specifications whilst these specifications are being agreed (for example the W3C Choroeography Working Group has adopted an adapted form of π-calculus to reason about WS-CDL descriptions). There is an increasing number of work on verification of web service compositions and we expect that this will follow through to web services choreography. Our work provides an integrated approach to resolve questions raised in each of these areas, whilst also allowing other specifications to be introduced as they arise.
6.2. On our Approach and Tool Figure 17 Validation assistance by way of the Animator feature of the tool
Our tool aims at providing the following criteria for its ease of learning and carrying out verification and validation. Firstly, the design specifications are based on the scenario approach, and the use of bMSC and hMSC
sequence charts is widely undertaken and understood in industry. Where other work has concentrated on specifying formal algebraic notations for specifications, we provide a graphical interface so that the user does not have to learn these sometimes complex notations. The implementations are constructed either directly in the tool or through a third-party tool such that the BPEL4WS engineer are not restricted in a particular editor implementation or feature list to use our approach. Early payback is another key objective of the approach. Our aim is to support answering questions highlighted by the distributed nature of web service compositions and on consideration of the pattern by which these compositions may interact. Clearly, the benefits of using such an approach will require early feedback to the developers so that greater assurance can be given, in both design and implementation activities, as earlier as possible. We achieve this by separating the tool between design and implementation, and consolidate their output to provide another view for analysis. The iterative development does not necessarily suggest that service compositions will be designed and implemented in isolation; moreover, we believe that compositions will be part of much wider developments cross-enterprise and between several development teams. The essence of our approach is to highlight inconsistencies between interactions specified in composition implementations against that of those given in design specifications. We do not aim to clarify notational
and specification semantic correctness, although that can be achieved to a degree by user validation through animation.
6.3. Integrated use in Eclipse From a technical implementation perspective, we wished to provide the tool as much as a reusable service as that of which it is used to verify. In this way, we have scoped the architecture for the tool to be extendable and integrated without a presumption of which interfaces would be used to build the inputs to the tool core. In other words, the BPEL4WS engineers are free to build the compositions in any supporting editor, yet on the one condition that the output from these editors conforms to the same specification supported by our tool. The tool was originally written as a prototype plug-in to the existing LTSA tool suite [12] and we have recently migrated this to the Eclipse environment. The plug-in views described here are based upon a migration of the Java modules from the original prototype. Core LTSA Java modules could be successfully imported into the Eclipse plug-in development environment however; rebuilding view modules has required some changes, particularly when moving the LTS Draw view (Figure 18) from the Swing/AWT API to SWT API (the GUI API used by Eclipse). Aside from these differences however, current view migration has mapped conveniently onto the standard views provided by the Eclipse framework.
Figure 18 LTSA-WS in Eclipse: LTS Draw View of BPEL4WS composition
7. Conclusions and Future Work Using the Eclipse framework opens the potential to link the tool with a network of other Eclipse plug-in contributions and aims to simplify the number of different, bespoke tools used in software engineering as a whole. Indeed, amongst these contributions are commercial BPEL4WS graphical editors (we currently only provide a basic XML editor), although the reader is invited to browse plug-in web sites as the list of contributors is continuously expanding. The LTSA-WS plug-in and specifically the version supporting BPEL4WS, is being considered for use on a number of medium sized case studies, including within projects undertaken by University College London and the UK Police IT Organization (PITO). BPEL4WS provides a work for forming an XML specification language for defining and implementing business process workflows for web services. We plan to expand the approach to allow designers and engineers to describe composition properties by way of the Web Services Choreography Description Language (WSCDL). The use of these standards provides an example of how distributed system computing using web services will be specified for web service choreography invocations, yet it is important to compose the service workflow correctly for all service actors and more importantly, verify this flow before actual implementation and deployment is undertaken. In this paper we presented a report on tool support towards this goal in the form of MSCs, and an implementation of equal requirements in BPEL. We are still in the process of migrating the complete suite (including MSC editor) as a project funded partly by the STATUS ESPIRIT project (IST-2001-32298), the EPSRC READS project (GR/S03270/01) and by an IBM Innovation Award (2005). The plug-in is available for download at http://www.doc.ic.ac.uk/ltsa.
8. References [1] 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. [2] F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, and S. Weerawarana, "Business Process Execution Language For Web Services, Version 1.1," 2003. [3] W3C-WSCI, "Web Service Choreography Interface (WSCI) 1.0," W3C - Web Services Choreography Working Group 2002. [4] R. Akkiraju, D. Flaxer, H. Chang, T. Chao, L.-J. Zhang, F. Wu, and J.-J. Jeng, "A Framework for Facilitating Dynamic e-Business via Web Services," presented at OOPSLA 2001 Workshop on Object-Oriented Web Services, Tampa, FL, 2001.
[5] C. Karamanolis, D.Giannakopoulou, J.Magee, and S.Wheater, "Modelling and Analysis of Workflow Processes," Imperial College of Science, Technology and Medicine, London 1999. [6] H. Foster, S. Uchitel, J. Magee, and J. Kramer, "Modelbased Verification of Web Service Compositions," presented at Eighteenth IEEE International Conference on Automated Software Engineering (ASE), Montreal, Canada, 2003a. [7] 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, 2004a. [8] O. Bukhres and C.J.Crawley, "Failure Handling in Transactional Workflows Utilizing CORBA 2.0," presented at 10th ERCIM Database Research Group Workshop on Heterogeneous Information Management, Prague, 1996. [9] X. Fu, T. Bultan, and J. Su, "WSAT: A tool for Formal Analysis of Web Services," presented at 16th International Conference on Computer Aided Verification (CAV), Boston, MA, 2004c. [10] S. Nakajima, "Model-Checking Verification for Reliable Web Service," presented at OOPSLA 2002 Workshop on Object-Oriented Web Services, Seattle, Washington, 2002. [11] S. Narayanan and S. A. Mcllraith, "Simulation, Verification and Automated Composition of Web Services," presented at Eleventh International World Wide Web Conference (WWW-11), Honolulu, Hawaii, 2002. [12] J. Magee and J. Kramer, Concurrency - State Models and Java Programs: John Wiley, 1999. [13] S. Uchitel and J. Kramer, "A Workbench for Synthesising Behaviour Models from Scenarios," presented at the 23rd IEEE International Conference on Software Engineering (ICSE'01), Toronto, Canada, 2001. [14] I. Jacobson, J. Rumbaugh, and G. Booch, The Unified Software Development Process: Addison-Wesley, Harlow, UK, 1999. [15] P. Graubmann, "Describing interactions between MSC components: the MSC connectors," The International Journal of Computer and Telecommunications Networking, vol. 42, pp. 323-342, 2003. [16] H. Foster, "A Guide to Mapping BPEL4WS to FSP," Department of Computing, Imperial College London, Technical Report 2003b. [17] N. Kavantzas, D. Burdett, G. Ritzinger, T. Fletcher, and Y. Lafon, "Web Service Choreography Description Language (WS-CDL) - W3C Working Draft 17 December 2004," W3C - Web Services Choreography Working Group 2004. [18] G. Engels, J. M. Kuster, R. Heckel, and M. Lohmann, "Model-Based Verification and Validation of Properties," Electronic Notes in Theoretical Computer Science, vol. 82, 2003. [19] D. P. Gluch, S. Cormella-Dorda, J. Hudak, G. Lewis, and C. Weinstock, "Model-Based Verification: Abstraction Guidelines," Software Engineering Institute, Pitssburgh, PA (CMU/SEI-2001-TN-028), 2001. [20] M. Koshkina, "Verification of Business Processes for Web Services," in Department of Computer Science. Toronto, Ontario: York University, 2003.
