Modelling and Transforming the Behavioural aspects of Web Services

This paper introduces the modelling, mapping and transformation of behavioural aspects of interacting Web services, within the context of Model Driven Architecture (MDA). There are certain systems, such as Web services, where the dynamic aspects are of high importance and need to be considered during the modelling and transformation process, in order to create accurate representations in their target domains. To demonstrate the approach, a realistic example is presented, involving a number of Web services, participating in a business process expressed as choreography of exchanged messages. Introduction Currently, the research on model transformations within Model Driven Architecture (MDA) is restricted among models, including only their structural characteristics, such as their content and their interrelations. In this paper we apply model mappings and transformations among behavioural models and express the way the various components collaborate, in order to implement different system functionalities and behaviours. Transforming the behaviour of a system as long as its structure results to completely defined new models. In particularly, if one considers a number of Web services standards, such as the Business Process Execution Language (BPEL) [2] and the Web services Choreography Interface (WSCI) [17] that represent business processes and choreographies of message exchanges among Web service participants respectively, one then understands that representing and mapping their behaviours is of primary importance. In order to illustrate the applicability and feasibility of the approach presented, a case study based on a realistic scenario is considered. Thus, specific models, metamodels, mappings and transformation rules have been introduced, for modelling, mapping and transforming a UML activity diagram accordingly to a scenario implemented with Web Services Choreography Interfaces. Preliminaries Web services [3][4] are a set of technologies allowing applications to communicate with each other across the Internet. Among the technologies used are the Extensible Markup Language (XML) [16], the Web Service Description Language (WSDL) [18] and the Web Services Choreography Interface (WSCI) [17]. XML can be used either as a meta-language or for structuring and interchanging data. WSDL provides a model in an XML format, for describing Web services as a set of exposed operations and WSCI as an XML based interface, for describing the message exchanges among various Web service participants and their choreography. WSCI works in conjunction with WSDL and describes the dynamic interfaces of the Web services. The Model Driven Architecture [1][7] is an emerging technology for software development. MDA promotes the automatic creation of models and code by a series of transformations. Initially, models are designed with a high level of abstraction that are independent of any implementation technology and called Platform Independent Models (PIMs). Then a PIM may be transformed to a Platform Specific Model (PSM) that is tailored to a specific implementation technology and finally to the actual code. In MDA all models are based on a specific metamodel that defines the language that the model is created in. Finally, all MDA metamodels are based on a common metamodel called Meta Object Facility (MOF) [12]. Model transformations [6][11] are defined by transformation rules in a transformation language like OCL [13], ATLAS [5] etc and they are executed by specialised tools. According to a QVT RFP [14] the transformations are defined at metamodel level (M2) and executed at model level (M1) as illustrated on the Figure 1. Source Model e.g. UML Activity Diagram (M1) Source Metamodel e.g. UML Lang (M2) Transformation Rules Transformation Engine TargetModel e.g. WSCI model (M1) Target Metamodel e.g. WSCI Lang (M2) Automatic code generation Code actual wsdl file MOF (M3) Figure 1: Transformation in MDA Case Study Example In order to illustrate, our Model Transformation approach, we shall present an example, which uses WSCI to model a business process. The example is a simplified version of an “airline ticket reservation and booking” business process, presented in WSCI specification. For the complete specification and example please refer to [17]. Here, the focus is on modelling the behaviour for only one of the participants involved; the Traveller. A UML Activity diagram that specifies the behaviour of the Traveller is presented. The model transformation converts such activity diagrams into an equivalent WSCI MOF based model [12], which is very close to the implementation code. There are three Web services involved in the example; a Traveller, a Travel Agent and an Airline System. The business process “Planning and Booking a Trip” represents the interaction between the above three Web services as described in the follows scenario: Initially, the Traveller plans a trip by deciding the destination, the departure and return date and time, and the preferred plan route. Then, she submits her request to the Travel Agent. The Travel Agent will evaluate the best itinerary for a destination and will build a proposed itinerary for the traveller. The proposed itinerary may not be satisfactory to the traveller, so she can submit a modified version and wait for a reply in the form of a new proposal by the Travel Agent. The Traveller can also choose to cancel the trip at any stage. In this case, the whole process terminates. However, if the plan is accepted, she has to reserve the tickets and provide her credit card details. If the reservation is confirmed, the Traveller can either book the tickets or cancel the reservation. There is a timeout for the booking period, i.e. tickets can be reserved for a limited time, at the end of which, the Airline System issues a notification and terminates the process. At the end, the Traveller receives two set of items; an e-ticket from the e Airline System and a statement containing the charge details and the description of the trip itinerary from the Travel Agent. The process of “Planning and Booking a Trip” is completed upon the reception of both items. UML Activity diagram The process of “Planning and Booking a Trip” explained in the previous section can be modelled with a UML Activity diagram, see Figure 2, which represents both the coordination and interaction between the participants, either as a workflow or as choreography of message exchanges. The Activity diagram consists of three partitions, corresponding to three involving Web services. However, to reduce the size of the diagram, the Activities related to the Traveller and the flow of messages between the Traveller and the other two participants are only included. The Activity diagram of Figure 2 for “Planning and Booking a Trip” can be explained as follows: The Traveller starts the process and triggers the message exchanges. Initially, she makes an order request to the Travel Agent by using a request-response WSDL operation called OrderTrip. In that case, the TripOrderRequest message is used to encapsulate the trip order details, where the TripOrderAcknowledgement message is the Travel Agent’s response with the proposed itinerary. If the Traveller is not happy with the itinerary, she may submit modifications by using the ChangeItinerary operation and the ChangeItineraryRequest message with the proposed itinerary. If it is accepted, a confirmation is returned. The whole process can be repeated as many times as the traveller is not satisfied with the plan. Notice, that such action is likely, only if it is triggered externally by the Traveller and not upon the arrival of a message or upon the satisfaction of a specific condition. While there is an itinerary proposal, the Traveller has the choice to either reject the trip completely or accept it. If the trip is cancelled, the Travel Agent is notified by using the CancelItinerary operation with a CancelItineraryRequest. Then the Travel Agent will reply with a confirmation message. As a consequence, a fault will be generated that will terminate the process. If the plan is accepted, which is the default case, the Traveller has to reserve the tickets and provide her credit card information with a ReserveTickets operation and a ReservationRequest message. Next, the TravelAgent confirms the reservation of the seats to the Traveller.