A BPEL Engine and Editor for the.net framework

Transcription

1 A BPEL Engine and Editor for the.net framework Matthew Buckle 1, Charlie Abela 1, Matthew Montebello 1 1 Department of Computer Science and AI, University of Malta mbuckle@crimsonwing.com, charlie.abela@um.edu.mt, matthew.montebello@um.edu.mt Abstract. In today's world of extreme competition, information exchange and efficient communication is the need of the day. This need for information exchange brings in another need, that which makes information selectively visible, and its visibility to be changed on the fly. Web Services are a new breed of web application and play a central role in the WWW, providing the above-mentioned requirements. The composition of these services enables application integration within and across organizational boundaries. The Business Process Execution Language (BPEL) is intended to enable portable business process definitions for WSDL based services. In this paper we describe the work done on a BPEL execution engine and editor developed for the.net framework. We also describe how a graphical representation based on UML activity diagrams was used to visualise service compositions and how this can be adopted as the underlying model for Semantic Web service descriptions such as OWL-S. Rationale The growing trend in software architecture is to build platform-independent software components, called web services that are available in the distributed environment of the Internet. Nowadays, web services can communicate with each other, advertise themselves, be discovered and invoked using industry - wide specifications. Applications are to be assembled from a set of appropriate web services and no longer be written manually. Seamless composition of web services has enormous potential in streamlining business-to-business or enterprise application integration. When viewed as a stand-alone entity, web services provide the required computation for some specific service by hiding any technical details from the client and allow its use over different systems. Substantial progress has already been achieved to enable rich, flexible and dynamic interoperation of highly distributed and heterogeneous web services. A number of process composition languages have already been developed to cater for the need of integrating different web services. Languages such as XLANG[2], WSFL[3], WSCI[4], OWL-S[5] and BPEL[1] are compared and contrasted in [12] The Business Process Execution Language for Web Services (BPEL for short) is the result of the merge of WSFL from IBM and XLANG from Microsoft. BPEL4WS provides a balance between both WSFL (support for graph oriented processes) and

2 XLANG (structural constructs for processes) into a package that supports the implementation of any kind of business process, together with composition of existing web services. BPEL is an XML based scripting language intended to enable portable business process definitions for WSDL[6] based business processes. An engine for this scripting language already exists and runs over a Java enabled web server. In this paper we provide an alternative BPEL engine that runs over the.net framework, in which processes comprising the composition of existing web services can be created, deployed and used by customers as a new web service. In order to facilitate the use of this language, a visual editor is also being developed so as to allow the user to: Create a BPEL process without exposing details of the markup used by the language. Use some standard diagramming technique to specify composition of existing web services for the process being created. Have the specified process diagram automatically generating the corresponding markup for the language. Edit the generated markup if more expressiveness to the process needs to be added. Overview Most of the effort was dedicated to the development of the engine, however, keeping a balance between the load of work required to implement the editor. The Engine provides the underlying platform that allows the execution of BPEL processes. This consists of an API that implements the constructs provided by the BPEL specification. Together with other components, the engine allows the users to create, verify and deploy new web services. The figure below gives an overview of the runtime environment for BPEL processes. Internet Inputs Web Service 1 Set of WSDL files of external Web Services Localhost Web. Service Web Service n WSDL(Service 1) WSDL(Service 2) WSDL(BPEL process) BPEL Engine Deployed BPEL process (composition of Web Services) BPEL process file BPEL process description Fig. 1. Runtime environment overview

3 The Visual editor, as the name denotes, allows the inexperienced user to easily create and edit BPEL processes through the use of UML[7] activity diagrams. The editor generates the corresponding BPEL markup from the given diagram. Users can also view the generated syntax at any point of the construction of the diagram, given that the provided diagram has a valid context. The idea of mapping UML activity diagrams to BPEL originated from the work done by James Scicluna [10]. His thesis consisted of a tool that would allow inexperienced users to easily create an OWL-S description of a web service. Specifically, the tool consisted of a visual composer that allows the user to build a process ontology through the use of a standard diagramming technique, namely UML activity diagrams. The main reason of creating a BPEL editor that uses UML activity diagrams to build a process visually is that of having an underlying framework that implicitly provides a mapping between BPEL and OWL-S constructs. The aim is to show that these markup languages can be, perhaps in the near future, combined to have a language that provides both a potential expressiveness with regards to service composition together with a means of semantically describing the process and allowing dynamic discovery of other processes. Engine The engine provides the run-time environment for BPEL processes. This consists of a library that implements the constructs that are required to describe a process, as specified by the BPEL 1.1 specification. The library is based on a factorymechanism, exposing only an interface of each class representing a construct and hiding any other underlying technical details. This is similar to the way BPWS4J allows the creation of BPEL processes. A process is then created through a BPEL source file and its WSDL description, together with any additional WSDL documents of any partner services that the process might use throughout its execution. These files are fed to the Deployer component that validates the syntax of the provided files, generates a respective process out of the API and makes the process available to its clients in the form of a SOAP web service. The processes are stored as object data files on disk and are loaded once upon startup of the engine and are kept in memory throughout the engine s lifetime. After deployment, a process is ready to serve its clients. However, the process by itself is not actually a web service. Technically speaking, the only web service is the engine. It is the only entity that handles all the incoming messages from the clients. The engine, together with the ProcessManager component, examines the messages received from the clients and routes them to a new or an existing instance of a process, depending on the message context. Thus, the engine upon receiving a message from a client physically starts a process. Creation of the process can be done either manually (i.e. self coding the markup for the process) or through the use of the Visual Editor provided in this project.

4 The user sends requests over HTTP, since the system acts as a single web service by itself. These are evaluated by checking the requested process ID, locating the actual process from the deployed process cache and finally executing it, sending any replies back to the user. Process Descriptor Files User Interaction Process Creation Process Validation Constructed Process File User HTTP request for process execution HTTP request for process execution Process ID Deployed Processes Cache WWW Process Request HTTP response for process results HTTP response for process results Process Execution Deployed Process Fig. 2. Engine s General Architecture Editor The visual editor serves as a tool that helps in the creation of BPEL processes, allow inexperienced users to define processes using a standard diagramming technique, namely UML activity diagrams, thus without the need of knowing the underlying markup comprised by the language. The user can visually drop different UML components onto a drawing canvas and combine them in different ways to generate a corresponding BPEL process. Through these diagrams, the editor automatically generates the markup for the specified process, provided that the diagram is valid in its context. The user can then view, at any point of the construction of the diagram, the code generated for the process. It was thus necessary mapping the implemented BPEL constructs to a respective UML activity diagram. An activity in BPEL provides a particular action that is carried out by the process at some point in time. It is clear that such a construct can be associated to an Action icon in UML activity diagrams. Such BPEL constructs that were mapped to the Action icon include the Receive, Invoke, Reply, Assign, Throw, Empty and Terminate activities. The Sequence activity in BPEL is implicitly obtained when two or more activities are connected to each other with a control flow icon. The figure below shows how a Sequence activity can be represented as a UML activity diagram.

5 Activity Activity 1 Activity 2 Fig. 3. BPEL activity as a UML action Fig. 4. A BPEL Sequence Concurrency in BPEL is provided by the Flow construct. The corresponding UML activity diagram that represents a set of activities executing concurrently, is the fork transition. By definition, a Flow activity stops executing when all of its enclosing activities have each finished their execution. This can be viewed as an implicit join condition applied on each activity enclosed in the Flow activity. A corresponding representation in UML activity diagrams, of such a scenario, can be provided by the use of the fork + join icons. Activity 1 Activity 2 Activity 3 Fig. 5. A UML action representation of a BPEL Flow Activity The Switch activity in BPEL provides a mechanism similar to that of a nested If- Then-Else activity in many common programming languages. Such a structure can be represented in UML activity diagrams using the decision and merge icons. The use of a merge icon is necessary because the UML 2.0 specification states that no action can have more than one control flow entering/exiting it. The merge icon signifies the end of the if-then-else construct. However, these only represent a single if-then-else construct. In order to model the Switch activity in UML, it was necessary nesting multiple decision and merge icons respectively, which would eventually be representing a nested If-Then-Else construct, hence the Switch activity.

6 Activity 1 Activity 2 Activity 3 Activity 4 Fig. 6. A UML action representation of a BPEL Switch Activity The While construct in BPEL, is used to iteratively execute an activity and its possible sub-activities. As described previously, the UML 2.0 specification states that no multiple control flow can be converged to a single action. This might seem as a problem when considering a way to represent a looping construct, like the While activity, in UML activity diagrams. However, this can be overcome by placing a merge icon exactly before a decision icon. A diagram is shown below. Activity Fig. 7. A UML action representation of a BPEL While activity The screenshot below shows a simple representation of a tested process, namely the Marketplace process. The idea behind this process is that of showing a small buyer-seller scenario in the form of a web service that keeps a stateful conversation between the two parties. The process concurrently enables two receive activities, one for the buyer and one for the seller respectively. In such a way, the process can be instantiated by any party. The conversation between the two parties becomes stateful only if the item in context is equal. The process then performs some logic to check

7 whether the buyer s offer is less than or equal to the seller s asking price. A reply is sent to both parties, indicating the outcome of the deal. Fig 8: BPEL Visual Editor Evaluation Time constraints were very tight and in order to obtain the best possible results it was opted to have the most important constructs of the language implemented first, since the project was not only focused in developing an engine that supports the language, but also an editor that would allow users to easily generate the markup for the language. Thus a balance between both major parts had to be established, restricting the runtime API to provide only the most necessary constructs in describing a process. The API was tested using different examples that are provided with IBM s BPWS4J[8] engine, including the Marketplace example presented in the Visual Editor section, which proved to work well for all of the implemented constructs.

8 The visual editor is limited when it comes to direct markup editing. Features such as automatic markup completion have been omitted from this part of the project, since these require quite a substantial amount of time to be completed. Such features were considered as enhancements to the tool that would not affect the validity of the work done and as such had to be left out due to the tight time constraints faced during the whole project. Another limitation is that only the constructs implemented in the runtime API were mapped to UML activity diagrams. The rest of the BPEL constructs are not currently supported by the editor, but can easily be added in the future. The reason behind this omission is primarily the amount of time required for their implementation. The editor was tested through a series of UML activity diagrams comprised of various complex compositions. The result was that the markup generated successfully in all test cases. Furthermore, the generated markup was then verified both through the editor and the Deployer component of the engine. In both cases, verification resulted to be positive and the Deployer also correctly generated the respective process file. Since a relationship between certain BPEL and OWL-S constructs has been discovered throughout the work done in this project, the editor can be further extended to generate both BPEL and OWL-S markup. The idea would be that of having a general process editor that would cater for the generation of the markup of both of these languages, having UML activity diagrams acting as the underlying framework that allows a mapping between particular, common constructs of these two languages. OWL-S version 1.1 provides a set of control constructs that can be used to define composite processes, such as Sequence, Split, Split + Join, Unordered, Choice, If-Then-Else, Repeat-While and Repeat-Until. Each of these mentioned constructs are defined as sub-classes of the ControlConstruct class, each having its own properties and restrictions. As a practical example, let us take the Sequence construct from both languages. The UML activity diagram is similar to the one described in Figure 4, whereby the Sequence consists of a set of ActionState icons that are connected to each other in a sequential order. A Sequence in OWL-S is defined as a list of ControlContructs to be executed in the order in which they are defined. Similarly, the BPEL Sequence activity consists of one or more other activities that are to be executed sequentially, whereby an activity defines part of the behavior that is carried out by the service (e.g. invoke another service, send a reply to the client). Similarly, other control constructs from both languages can also be related to each other via other UML activity diagrams. Specifically, the Flow construct in BPEL can be mapped to the Split + Join activity in OWL-S using the Fork and Join icons, the If-Then-Else construct in OWL-S can be mapped to the Switch construct in BPEL using the Decision and Merge icons, and finally, the While construct in BPEL can be mapped to the Repeat- While construct in OWL-S using a Merge icon before a Decision icon. Although the mapping of certain control constructs to UML activity diagrams provided a relationship between both of these languages, the idea does not provide a direct mapping between each construct. Specifically, the Sequence construct in OWL-S must consist of one or more other ControlConstructs, while the Sequence construct in BPEL must consist of one or more other activities. Other differences arise from the fact that certain constructs are present in one language and missing in

9 the other. Specifically, BPEL provides constructs, called activities, such as Receive, Invoke, Reply, etc, which are used to define the behavior of the process, while OWL-S does not currently define such constructs. However, the idea of using UML activity diagrams as an underlying framework in order to provide the functionality required to generate the markup for both languages can still be applied to the editor. The editor would have to be extended in order to determine the validity of the process diagram in the context of the chosen language to be generated. Related Work A tool that is available and that allows the creation and execution of BPEL processes is the BPWS4J package. This package consists of an execution engine and an editor that is implemented as an Eclipse plug-in and was developed by the Component Systems Group at IBM TJ Watson Research Center. The engine is completely implemented in Java and that runs in a servlet container over a Javaenabled web server. The editor can be used with Eclipse V2.0 or higher. Basically, the editor allows the inexperienced user to easily create and modify BPEL files. Specifically, it allows the user to: View the source both as visual tree views and as XML format. Handle the design of the process both top-down and bottom-up. Validate the created process against specification requirements. In contrast to the BPEL engine provided by IBM, the implemented runtime in this project lacks some functionality, in that not all of the language constructs have been implemented. BPWS4J currently supports the use of all BPEL constructs. On the other hand, the editor implemented in this project, probably provides a better approach in guiding the user to visually construct a process, than the editor that comes with the BPWS4J package. The main reason behind this statement is that the editor provided by the BPWS4J package simply represents a process through the use of a Java Tree View control, while the editor provided by this project uses a standard software diagramming technique, namely UML activity diagrams. Furthermore, the use of this diagramming technique also revealed an implicit relationship between BPEL and OWL-S, as explained earlier. In [9] the authors discuss the issue of integrating semantic web technology into web services, specifically building on the BPEL composition language to present dynamic binding of web services together with interoperation and semantic translation. It is argued that in order to achieve the long-term goal of seamless interoperability, web services must embrace many of the representation and reasoning ideas proposed by the semantic web services community. The idea proposed in this paper is that of integrating semantic service description querying into the BPWS4J. Since the current release of BPWS4J is not extensible, the idea proposed is that of constructing a Semantic Discovery Service (SDS) that would sit between a BPEL process and its collaborating partners. The intent is that of having the engine directly routing requests to the SDS rather than to its previously selected partners. The SDS

10 then locates appropriate service partners and serves as a dynamic proxy between the engine and the discovered partners. The LTSA-WS/BPEL4WS [13] plug-in is an Eclipse plug-in that extends on the Labeled Transition System Analyzer (LTSA) tool. LTSA is a tool that provides a means to construct and analyze complex models of finite state process specifications. This plug-in allows the user to express a BPEL process in the form of a Finite State Process (FSP) diagram [11]. In contrast to our tool, BPEL constructs have been mapped to a respective FSP, rather than to a corresponding UML activity diagram. Furthermore, since LTSA provides a mechanism that models workflows prior to implementation and deployment testing, value is added to the development of a BPEL process since early verification of the process can be performed through such a model. In contrast to our application, this tool provides a mechanism that would output more robust processes due to the verification performed prior to their testing, though they resort to BPWS4J engine for execution. CaSheW-s [14] is an ongoing project concerning the composition of semantic Web services via workflow-oriented orchestrations. The aim of the project is similar to the one we described in this paper in that it aims to provide a generic process editor that is based on an underlying model and which would support different service composition languages such as OWL-S and WSMO (Web Service Modeling Ontology) [15]. The work also aims at providing an orchestration engine based on Haskell and which is able to execute any workflow whose semantics can be described by process calculus. Future Work We plan to extend the project primarily by implementing the rest of the constructs of the language and extending the functionality of certain implemented constructs. The first enhancement to be carried out for the editor is the support for all of the constructs comprised by BPEL. The current implementation of the editor only supports the constructs implemented in the runtime API. This would require more work on the mapping between the rest of the constructs and corresponding UML activity diagram. Another feature, which is planned to be added to the GUI of the editor, is a mechanism that gives brief helping tips for the use of each component, together with a drag-drop environment for the components. Together with these features, we also intend to include a mechanism for auto-completion of markup, when being manually coded by the user. We also plan to extend the tool with a verification phase prior to the execution phase. Our verification will be based on FSAs and is inspired by [16]. The engine requires the inclusion of a scheduling mechanism so that the tool can handle in a more efficient way not just service orchestration but also service choreography. Conclusion The prototype described in this paper is intended to serve as a package that provides an alternative BPEL engine that runs over the.net framework. We have

11 shown that new processes built from the composition of existing web services can be created and deployed easily. In particular the editor allows inexperienced users to easily create their own processes by hiding away the underlying complex markup of the language. We have also shown that our idea of using an underlying model to be able to work with OWL-S can also be extended to BPEL and is being adopted in other research thus proving scalable. References 1. Francisco Curbera, Yaron Goland, Johannes Klein, Frank Leymann, Dieter Roller, Satish Thatte,SanjivaWeerawarana. Business Process Execution Language for Web Services, Version 1.0, Satish Thatte. XLANG: Web Services for Business Process Design, Frank Leymann, IBM Software Group, Web Services Flow Language (WSFL) Version 1.0, Intalio, Sun Microsystems, BEA Systems, SAP. Web Service Choreography Interface (WSCI) 1.0 Specification, OWL-S 1.1 Release Roberto Chinnic, Martin Gudgin,Jean-Jacques Moreau, Sanjiva Weerawarana, Web Services Description Language (WSDL) Version 1.2, /WD-wsdl /#intro. 7. UML Resource Page IBM Daniel J.Mandell, Sheila A. McIlraith, Adapting BPEL4WS for the Semantic Web: The bottom-up approach to web service interoperation, people/sam/iswc2003sam-djm-final.pdf 10. James Scicluna, Matthew Montebello, Charlie Abela, Visual Modeling of OWL-S Services, submitted to the IADIS WWW conference, Howard Foster, Sebastian Uchitel, Jeff Magee. Model-based verification of web service compositions, Charlie Abela, Monika Solanki, The Landscape of Markup Languages for Web Service Composition LTSA-WS/BPEL4WS plug-in, Composition and Semantic enhancement of Web-Services (CaSheW-s). shef.ac.uk/~barry/cashew-s/ 15. WSMO, Web Service Modeling Ontology, Daniela Berardi, Fabio De Rosa, Luca De Santis, Massimo Mecelli, Finite State Automata as Conceptual Model for E-Services