Modeling of Web Services using Reaction Rules

Modeling of Web Services

Modeling of Web Services using Reaction Rules Marko Ribarić1, Shahin Sheidaei2, Milan Milanović3 and Dragan Gašević4 (1) Mihailo Pupin Institute, Serbia (2) School of Interactive Arts and Technology, Simon Fraser University, Canada (3) FON-School of Business Administration, University of Belgrade, Serbia (4) School of Computing and Information Systems, Athabasca University, Canada

1

Modeling of Web Services

2

ABSTRACT Development process of Web services needs to focus on the modeling of business processes rather than on low-level implementation details of Web services, and yet it also needs to incorporate the support for frequent business changes. This paper presents the UML-based Rule Language (URML) and REWERSE Rule Markup Language (R2ML), which use reaction rules (also known as Event-Condition-Action rules) for modeling Web services in terms of message exchange patterns. Web services that are being modeled in this way can easily be integrated in the wider context of modeling orchestration and choreography. In order to achieve proposed solution, we have developed a plug-in for the Fujaba UML tool (so called Strelka) and a number of model transformations for round-trip engineering between Web services and reaction rules. Also, the paper presents mappings of models of Web services with reaction rules into the Drools rule language, thus enabling the run time execution semantics for our rule-based models.

Modeling of Web Services

3

Modeling of Web Services using Reaction Rules 1. INTRODUCTION

Web services provide a communication interface and a workflow management protocol for business systems. Their goal is set to change the Web from a static collection of information, to a dynamic place where different software components (business logics) can be easily integrated (Arroyo et al., 2004). Some of the factors that constrain web services from achieving that goal can be named as follow: when developers try to enrich the existing Web services with some new functionality, they have to implement necessary changes manually, which may lead to potential execution errors; furthermore, business rules, due to their declarative nature, are used for reflecting dynamic changes representing desired alteration in the business process. When business rules are used in a networked business, they are often large and complex, which makes them difficult to manage and change. There is a lack of automatic mechanism for updating Web services based on the business rules changes (Ribaric et al., 2008). The need for a more straightforward way to express, and manage business rules as a separate part of Web services’ composition has been recognized by researchers for the numerous benefits that it provides (Charfi & Mezini, 2004). However, integrating rule-based systems in a serviceoriented environment is a complex task, due to the fact that both worlds have their own paradigms (Rosenberg & Dustdar, 2005). Many different factors involve in this integration. However, the most important one of these factors is the architecture of service oriented systems. In this architecture, layers play a great role. The layering architecture is needed to be represented and deployed in the world of rules which become challenging and could not be simple done. This integration approach should be loosely coupled, meaning that it is reasonable to expose business rules as services. The way of modeling Web services presented in this paper facilitates this integration process, and those services can be more easily integrated in the wider context of modeling orchestration and choreography. A promising way to solve these problems is to use a high-level modeling approach combined with the use of rules. A modeling approach will allow developers to focus on a problem domain rather than on an implementation technology. This is why we propose using an approach based on Model Driving Engineering (MDE). Although, there have been several attempts to leverage MDE principles to model Web services, they are still very low level oriented, as they again focus on technical details covered either by WSDL (Bezivin et al., 2004) (Vara et al., 2005) or OWL-S (Timm & Gannod, 2005) (Gronmo et al., 2005). The use of rules implying that they are defined in a declarative way, they can dynamically reflect business logic changes at run-time without the need to redesign the whole system. Since Web services are used for integration of business processes of various stakeholders, it is important for them to reflect changes in business logic, or policies, as good as possible.

Modeling of Web Services

4

The solution that we propose is to use rules to represent and model business processes from the perspective of message exchange. That is, our modeling approach enables one to model Web services from the perspective of the underlying business logic regulating how Web services are used regardless of the context where they are used. To do so, our proposal is to leverage message-exchange patterns (MEPs) as an underlying perspective integrated into a Web service modeling language. This perspective has already been recognized by Web service standards (Chinnici et al., 2007), and our contribution is to raise this to the level of models. As the leading Rule Modeling language we benefit from UML-based Rule Modeling Language (URML) (Lukichev & Wagner, 2006a) for our approach. URML having strong ties with R2ML (REWERSE Rule Markup Language) empowers us to model rules in various languages. URML supports modeling of domain vocabularies in addition to integrity, derivation, production and reaction rules. .Business rules, being similar to natural language rules, are proposed to be modeled by using reaction rules (also known as Event-Condition-Action, ECA, rules) in this paper. Reaction rules will perform a task (Action) under some circumstances (Conditions) if some events (Event) take place and can best describe a business rule. We also have developed a plugin (called Strelka) for the well known UML tool Fujaba, which has a support for URML notation. Strelka also has the support transformation of URML models into Web Service Description Language (WSDL) and different types of rule languages such as Drools, Jess, and SWRL. In this paper, we discuss those transformations that are implemented by using a model transformation language entitled the ATLAS Transformation Language (ATL) (ATL, ver. 0.7). The paper is structured as follows: in the next section we give a bit of the background, including, Web services, R2ML and URML languages with the emphasis on reaction rules. In section 3 we introduce our approach for modeling business rules and services following by section 4 in which we introduce Strelka (Lukichev & Wagner, 2006b), a tool we developed that is capable of presenting URML diagrams, and performing transformations. Section 5 describes mapping process between URML and WSDL that is a part of Strelka, and also covers a deployment of URML diagrams to the Drools rule engine. Section 6 summarized the related work done so far and in Section 7 we conclude this work by summarizing the major points.

2. BACKGROUND

In this section, we give a brief overview of the technologies and techniques relevant to the problem under study. This includes a short description of Web services, Drools rule engine, and rule language definitions based on MDE principles used in our modeling approach. A complete introduction into the ATLAS Transformation Language (ATL) can be found in the chapter entitled “Sharing ontologies and rules using model transformations”.

Web Services

Modeling of Web Services

5

A Web service is a loosely coupled component that exposes functionality to a client over the Internet (or an intranet) by using web standards such as HTTP, XML, SOAP, WSDL, and UDDI (Timm & Gannod, 2005). SOAP is an XML-based protocol for exchanging information in a decentralized, distributed environment. SOAP builds on XML and common Web protocols (HTTP, FTP, and SMTP) (Coyle, 2002). A SOAP message is the basic unit of communication between SOAP nodes. The “envelope” element represents the root of a SOAP message structure. It contains a mandatory body construct and optional header construct (Gudgin et al., 2007). The header construct is where meta-information can be hosted. In a large number of service-oriented architectures, the header is an important part of the overall architecture, and although it is optional it is rarely omitted. Web Service Description Language (WSDL) is a language for describing both the abstract functionality of a service and the concrete details of a Web service (Chinnici et al., 2007). At an abstract level, WSDL describes a Web service in terms of interfaces and the operations supported by the interfaces. An operation is an interaction with the service consisting of a set of (input, output, infault and outfault) messages exchanged between the service and other parties involved in the interaction (Chinnici et al., 2007). The messages are described independently of a specific wire format by using a type system, typically XML Schema. WSDL also describes the point of contact for a service provider, known as the endpoint – it provides a formal definition of the endpoint interface and also establishes the physical location (address) of the service. Potential requestors need a way to discover Web services descriptors. It is necessary that these descriptors are collected and stored in a central registry. The key part of the Universal Description Discovery and Integration (UDDI) specification (Clement et al., 2004) presents standardizing information inside such a registry as well as specifying the way the information can be searched and updated. Regardless of how complex tasks performed by a Web service are, almost all of them require the exchange of multiple messages (Erl, 2005). It is important to coordinate these messages in a particular sequence, so that the individual actions performed by the message are executed properly. Message exchange patterns (MEPs) are a set of templates that provide a group of already mapped out sequences for the exchange of messages (Erl, 2005). This basically means that MEPs define how services should be used, as they can coordinate input and output messages related to a certain operation. The WSDL 2.0 specification defines three MEPs:  in-only pattern – supports a standard fire-and-forget pattern (i.e., only one message is exchanged);  robust in-only pattern – presents a variation of the in-only pattern that provides an option of sending a fault massage, as a result of possible errors generated while transmitting, or processing data;  in-out pattern – presents a request-response pattern where two messages (input and output) must be exchanged. However, WSDL 2.0 specification offers the possible use of five more patterns (Lewis, 2007): - out-in pattern – also consists of exactly two messages (like in-out pattern), but now a service provider is the one that initiates the exchange of messages; - out-only – consists of exactly one message (like in-only pattern), and is most often used for message notification;

Modeling of Web Services -

-

6

robust out-only - presents a variation of the out-only pattern that provides an option of sending a fault massage; in-optional-out – is similar to pattern in-out with one exception: sending an message that represents a response is optional, and because of this a requester that has started a communication should not expect this message; out-optional-in – is opposite to the previous pattern, where the input message is optional.

Drools

Drools is a business rule management system (BRMS) with a forward chaining inference based rule engine, more correctly known as a production rule system, using an enhanced implementation of the Rete algorithm. BRMS is a production rule system with a focus on knowledge representation to express propositional and first order logic in a concise, non ambiguous and declarative manner. The core of a production rules system is an inference engine that is able to scale to a large number of rules and facts. The inference engine matches facts and data, against production rules, also called productions, to infer conclusions which result in actions. A production rule is a two-part structure using first order logic for knowledge representation (Proctor et al). Figure 1 presents a schema of a production rule. It executes the actions while the conditions are being satisfied. Drools representation contains the same structure, LHS (Left Hand Side) is referring to conditions while RHS (Right Hand Side) is referring to actions. Name of the rule which is presented by “name” is just for better understanding of rules and have no functional value. Attributes, marked with attributes in the rule are used for the rule internal functionality itself.

when then

rule “name” attributes when LHS then RHS end

Figure 1 First order logic representation (left) - Drools representation (right)

The process of matching new or existing facts against production rules is called pattern matching, which is performed by the inference engine (part of Drools). Drools implements and extends the Rete algorithm The Drools Rete implementation is called ReteOO, signifying that Drools has an enhanced and optimized implementation of the Rete algorithm for object oriented systems (Schneier). For better understanding of rules and their structure please refer to the chapter “Object Oriented Rule Languages”.

Modeling of Web Services

7

R2ML

Existing Web rule languages (RuleML (Hirtle et al., 2006) and SWRL (Horrocks et al., 2004)) and rule modeling approaches (SBVR (SBVR, 2006) and PRR (Charfi & Mezini, 2004)) very nicely serve the purpose of rule interchange and rule representation independent of any specific platform, respectively. However, none of these languages offers a suitable modeling foundation that can be used for modeling Web services from a more abstract perspective of business processes and business rules in which they are used. That is, the language should be able to model reaction rules. Yet, such a modeling language should be closely related to the already existing software modeling languages such as UML and preferably defined by following MDE principles. Finally, the language should be closely related to the Web standards for defining ontologies (OWL) and rules (RIF). We have decided to use REWERSE I1 Rule Markup Language (R2ML), as it fully satisfies the above requirements. The language is defined by a MOF-based metamodel which is refined by OCL constraints that precisely define relations between the language’s constructs in addition to those defined by the metamodel; it has an XML schema defined concrete syntax; it has a UMLbased graphical concrete syntax, so called UML-based Rule Modeling Language (URML), which we will introduce it in the section below; and it has a number of transformations with other rule languages (e.g., JBoss’ Drools and OCL) allowing us to translate Web service models to the rule-based languages that can then regulate the use of Web services. R2ML is a rule language that addresses all the requests defined by the W3C working group for the standard rule interchange format (Ginsberg et al., 2006). The R2ML language can represent different types of rule constructs, that is, it can represent different types of rules (Wagner et al., 2006) including: integrity rules, derivation rules, production rule, and reaction rules. Integrity rules in R2ML, also known as (integrity) constraints, consist of a constraint assertion, which is a sentence in a logical language such as first-order predicate logic or OCL. Derivation rules in R2ML are used to derive new knowledge (conclusion) if a condition holds. Production rules in R2ML produce actions if the conditions hold, while post-conditions must also hold after the execution of actions. A reaction rule is a statement of programming logic (Giurca et al., 2006) that specifies the execution of one or more actions in the case of a triggering event occurrence and if rule conditions are satisfied. Optionally, after the execution of the action(s), postconditions may be made true. R2ML also allows one to define vocabularies by using the following constructs: basic content vocabulary, functional content vocabulary, and relational content vocabulary. Here we give short description of vocabulary constructs that we use in this paper. Vocabulary is a concept (class) that can have one or more VocabularyEntry concepts. VocabularyEntry is abstract concept (class) that is used for representing other concepts by its specialization. For example, one of the VocabularyEntry-s is an R2ML Class concept which represents the class element similar to the notion of the UML Class. An R2ML Class can have attributes (class Attribute), reference properties (class ReferenceProperty) and operations (class Operation). Due to the importance for our Web service modeling approach, here we only describe the details of R2ML reaction rules. Reaction rules represent a flexible way for specifying control flows, as well as for integrating events/actions from a real life (Giurca et al., 2006). Reaction rules are represented in the R2ML metamodel as it is shown in Figure 2: triggeringEvent is an R2ML EventExpression (Fig. 4); conditions are represented as a collection of quantifier free logical

Modeling of Web Services

8

formulas; producedAction is an R2ML EventExpression and represents a system state change; and (optional) postcondition must hold when the system state changes.

Figure 2 Definition of reaction rules in the R2ML metamodel The R2ML event metamodel defines basic concepts that are needed for dynamic rule behavior (Figure 3). There are two types of events: atomic event (AtomicEventExpression) and composite events (AndNotEventExpression, SequenceEventExpression, ParallelEventExpression or ChoiceEventExpression). Characteristic of an atomic event is that it has no duration (duration = 0). For the sake of modeling Web services, we are using MessageEventExpression for both triggering events and produced actions. MessageEventExpression is used for modeling messages that are part of the definition of Web services, including, input, output, in-fault, and out-fault messages. Each MessageEventExpression has its own type – EventType. In terms of WSDL, message types are defined by XML Schema complex types, while in R2ML, EventType is a subclass of Class (already defined as a part of the R2ML Vocabulary). This means that each EventType has its own attributes, associations, and all other features of R2ML classes.

Figure 3 Event expressions in the R2ML metamodel

Modeling of Web Services

9

URML

UML-Based Rule Modeling Language (URML) is a graphical concrete syntax of R2ML. URML is developed as an extension of the UML metamodel to be used for rule modeling. In URML, modeling vocabularies is done by using UML class models. Rules are defined on top of such models. The URML reaction rules metamodel, which we use for modeling services, is shown in Figure 4a. The figure shows components of a reaction rule: Condition, Postcondition, RuleAction and EventCondition. The figure also shows that reaction rules are contained inside the UML package which represents Web services operation. This means, that such packages have a stereotype in UML diagrams. An instance of the EventCondition class is represented on the URML diagram as incoming arrow (e.g., see Figure 5), from a UML class that represents either an input message or an input fault message of the Web service operations, to the circle that represents the reaction rule. The UML class that represents the input message (inputMessage in Figure 4b of the Web service operation is MessageEventType (a subclass of EventType from Figure 3) and it is represented by using the stereotype on UML classes. The UML class that represents the input fault message (inFault in Figure 4b) of the Web service operation is FaultMessageEventType in the URML metamodel. In URML diagrams, FaultMessageEventType is represented by the stereotype on UML classes. EventCondition contains an object variable (ObjectVariable in Figure 4c), which is a placeholder for an instance of the MessageEventType class. The object variable has a name that corresponds to the arrow annotation, which represents EventConditon.

a) b) c) Figure 4 a) Extension of the URML metamodel for reaction rules; b) Part of the URML meta-model for EventCondition; c) Extension of the URML metamodel for actions An instance of the RuleAction class is represented as an outgoing arrow on the URML diagram, from the circle that represents the reaction rule to the class that represents either an output message or an output fault message of the Web service operation. The UML class that represents the output message (outputMessage in Figure 4c) of the Web service operation is MessageEventType and it is represented with the stereotype on UML classes. The UML class that represents the output fault message (outFault) of the Web service operation is FaultMessageEventType in the URML metamodel and it is represented with the stereotype on UML classes. RuleAction contains an object variable (ObjectVariable), which represents an instance of the MessageEventType class.

Modeling of Web Services

10

3. MODELING

In this section the idea behind modeling of rules and business processes will be exposed. Modeling will be performed with the help of URML and R2ML. In section 5 with the use of modeling, the transformation to the web services and automatic generation of codes will be described. Rule Modeling

As stated, in this paper we are concerned with reaction rules. Reaction rule formalizes eventcondition-action behavioral model, where the action is executed on event with a condition satisfied. Let us analyze the following example: On customer book item request, if the item is available, then approve order and decrease amount of items in stock. In this rule on customer book item request is a triggering rule event, if the item is available is a rule condition, approve order is a rule action and decrease amount of items in stock is a postcondition, which can be expressed as a logical constraint, requiring less amount of items in stock, than before the rule execution. There are several general advantages of using reaction rules for specifying web services:  Requirements are often captured in the form of rules in a natural language, formulated by business people;  Reaction rules are easier to maintain and integrate with other kinds of rules, used in business applications (integrity rules, which specify constraints the data must fulfill, derivation rules, which explain how a model element can be derived);  The topic of rules validation and verification is well studied;  Reaction rules emphasis on events gives a flexible way to specify control flow and web service interaction patterns. Our approach is on the edge of the MDE, Web Services, and rules. It brings several large communities together and helps to facilitate the use of rules and MDE technologies in the growing area of Web Services. Business Rule Modeling

In this section we describe the concept of our approach talking about modeling of Business rules with the help of web services. In our approach, we look from the perspective of the potential patterns of the use of services. That is, we model services from the perspective of MEPs. It is important to point out that we first start from the definition of a business rule that corresponds to a MEP under study, but without considering the Web services that might be developed to support that rule. In this way, unlike other approaches to modeling of Web services, we are focused on the business rules describing how particular services are used, but without explicitly stating that we are talking about Web services. This approach enables us, not only to focus on the problems under study and the underlying business logic regulating the use of Web services, but also now we are able to translate such Web service modeling to both Web service languages and rule-based languages that can regulate how services are used at run-time.

Modeling of Web Services

11

Here, we describe how the in-out MEP is modeled in URML. The in-out MEP consists of exactly two messages: when a service receives an input message, it has to reply with an output message. This means that a fault message must be delivered to the same target node as the message it replaces, unless otherwise specified by an extension or binding extension. To show how this variation of the in-out MEP can be modeled by using reaction rules, we start our discussion from an example of the in-out MEP with an out-fault message. Let us consider the following business rule: When a user sends a message, if the length of the message is less than five characters long return the message to the user, otherwise return an error message. The business rule is an in-out MEP and can be represented by two reaction rules, represented in semi-formal pseudo rule syntax: ON UserMessageArrival (echoInParam) IF echoInParam.length < 5 THEN DO EchoStringResponse (echoInParam) ON UserMessageArrival (echoInParam) IF NOT echoInParam.length < 5 THEN DO EchoStringError (“message too long”)

In order to have these rules represented using our modeling notation, and also to be able to relate the rules with the elements of vocabularies, we model these rules by using URML. It is important to stress that all rules-based systems define business rules on top of business vocabularies. Thus, the URML graphical notation enables us to define business rules regulating the use of Web services by leveraging a human-comprehendible, and yet formally consistent representation, with the underlying business vocabularies (i.e., UML class models). These abovementioned two reaction rules represented in URML are shown in Figure 5.

Figure 5 PIM level of the in-out message exchange pattern with out-fault, presented in URML In this particular case, we have the following situation: triggering event of either rule (i.e., UserMessageArrival) maps to the input message of the Web service operation. The action of the first reaction rule (i.e., EchoStringResponse), which is triggered when a condition is true, maps

Modeling of Web Services

12

to the output message of the Web service operation. The action of the second reaction rule (i.e., EchoStringError), triggered on a false condition, maps to the out-fault message of the Web service operation. As shown, a web service operation may be modeled by using more than one rule, where rules, that define an operation, are grouped in one package by the name of the operation. Otherwise, for modeling the basic in-out MEP, only one (first) reaction rule would be used. Besides the classes that model exchanged messages, the URML diagrams also model conditions (e.g., echoInParam.length < 5). Such condition constructs are modeled by using OCL filters. OCL filters are based on a part of OCL that models logical expressions, which can be later translated to R2ML logical formulas, as parts of reaction rules. However, these OCL filters cannot be later translated to Web service descriptions (e.g., WSDL), as those languages cannot support such constructs. But, we can translate our URML models into rule-based languages (e.g., Jess or Drools). This means that for each Web service, we can generate a complementary rule, which fully regulates how the service is used. Another benefit of this approach is that our generated Web services, and their regulating rules, are consistent, as they originate (i.e. they are generated from) the same rule-based Web service model. 4. STRELKA – OUR MODELING ENVIRONMENT In this section, we describe Strelka – a tool that was implemented as a plugin for the Fujaba tool1. Fujaba is a UML modeling tool, developed at the University of Paderborn in Germany. Fujaba allows creation of different types of UML diagrams. It allows generation of Java code based on created model, and it offers a plugin interface that we used for Strelka implementation. Figure 6 shows, symbolically, the architecture of Strelka, as well as the functionality that it provides.

Figure 6 Strelka’s functionality The first part of Figure 6 (leftmost dashed box) shows us two important features Fujaba has: it is capable of generating Java code from diagrams, and it offers easily extensible architecture suitable for plugin implementation. This box also symbolically shows that one of the steps that need to be undertaken when creating a plugin for Fujaba is to create a metamodel for the new elements Fujaba will be extended with. After this first box, in the figure, we have an OCL parser. The OCL parser, which we used in this version of Strelka, is developed at the Technical 1

http://www.Fujaba.de

Modeling of Web Services

13

University of Dresden in Germany2. This parser is widely accepted open source tool – besides Fujaba, it can be also integrated into other tools: ArgoUML, Borland Together, Poseidon. The second dashed box on Figure 6 shows that we use JAXB in the process of mapping URML to R2ML. JAXB guaranties that the R2ML XML document we get as the result of serialization of URML diagram created in Strelka, is valid according to the R2ML XML schema. The reason we use JAXB, is that Fujaba does not have explicitly defined metamodel in some of the metamodeling languages (e.g. MOF, or Ecore). So, we could not use model transformations (and ATL), in the mapping process between URML and R2ML like we did in the process of mapping between R2ML and WSDL (this mapping we describe in the next section). And the last dashed box on Figure 6 shows that Strelka has an integrated support for calling model transformations between R2ML and WSDL. As already mentioned, one of the steps in the process of creating plug-ins for Fujaba is defining a metamodel for all the new elements that we extend Fujaba with. This metamodel is created in Fujaba, and then Java code is generated from it. This Java code we use afterwards, in the process of generating plugin itself. As the process of defining metamodel, and Java code generation is complete, we can create class diagrams that can incorporate those newly created elements, as well as UML elements that were already available (e.g. classes and associations). Figure 7 presents fragment of the Rule metamodel created in Fujaba. Classes that are relevant to the modeling of reaction rules are: ReactionRule, MessageAction, EventCondition, MessageEventType, and FaultMessageEventType. Figure 7 shows relations between the ReactionRule class to the other classes in this metamodel. The ReactionRule class is a subclass of Rule class (just like IntegrityRule, ProductionRule, and DerivationRule classes, which are used for modeling integrity, production, and derivation rules respectively).

Figure 7 Strelka’s rule metamodel

5. TRANSFORMING WEB SERVICE MODELS

2

http://dresden-ocl.sourceforge.net/

Modeling of Web Services

14

In this section, we summarize the translation process from URML reaction rules to Web services, and then we describe how this URML model can be transformed to Drools rule language. The process of getting WSDL documents from URML models is as follows: first, we create an URML diagram in Strelka, after this we serialize it in the R2ML XML concrete syntax (this functionality is built in Strelka, and it relies on the use of JAXB). Once URML reaction rules are serialized to R2ML XML, they are translated into WDSL documents (this translation is done at the level of metamodels as described below). It is important to say that this process allows for two way transformation between URML and WSDL, that is, it is possible to perform reverse engineering of existing services, and extract business rules already integrated to service implementation. To support this approach, we have implemented a number of transformations between different languages and their representations (these transformations can be found on the ATL ZOO page (WSDL2R2ML, 2006):  URML and R2ML XML concrete syntax. As previously stated, this is the only transformation that is not implemented by using ATL (ATL, ver. 0.7), but instead it is based on JAXB  R2ML XML-based concrete syntax and R2ML metamodel. This transformation is important to bridge concrete (XML) and abstract (MOF) syntax of R2ML. This is done by using ATL and by leveraging ATL’s XML injector and extractor.  R2ML metamodel and WSDL metamodel. This transformation is the core of our solution and presents mappings between R2ML and WSDL at the level of their abstract syntax.  WSDL XML-based concrete syntax and WSDL metamodel. This transformation is important to bridge concrete (XML) and abstract (MOF) syntax of WSDL. This is done by using ATL and by leveraging ATL’s XML injector and extractor. Here, we describe the third and the forth transformation: i.e. transformation between R2ML metamodel and WSDL metamodel, and transformation between WSDL XML schema and WSDL metamodel. Transformation between WSDL metamodel and R2ML metamodel Figure 8 shows the general principle of mappings between WSDL metamodel and R2ML metamodel (as can be seen on the figure, these mappings can be done in both directions).

Figure 8 Mappings between models that conform to WSDL metamodel to models that conform to R2ML metamodel

Modeling of Web Services

15

Process of transforming WSDL metamodel elements to R2ML metamodel elements is conducted in the MOF technical space (TS) (Kurtev et al., 2002). Table 1 shows a conceptual mapping between these metamodels (this table does not show parts related to the mapping between the XML Schema language, which WSDL uses for defining message types and vocabularies, and the R2ML vocabulary). Table 1 an excerpt of the mapping between the WSDL metamodel and the R2ML metamodel WSDL metamodel R2ML metamodel Description RuleBase ElementType Vocabulary Interface ReactionRuleSet Operation ReactionRule Input MessageEventExpression Infault MessageEventExpression Output MessageEventExpression Outfault MessageEventExpression

Figure 9 shows an example of a matched rule from our (WSDL2R2ML.atl) transformation (for the Input class in the WSDL metamodel), and Figure 10 shows a graphical presentation of this mapping (for this particular class) between WSDL and R2ML metamodel. This matched rule initializes “sender”, “objectVariable” and “type” features of the target R2ML MessageEventExpression element (we are putting a string “to_be_defined” in the “sender” feature, as the user will provide this information if required. This feature refers to the requester of the service). rule TriggeringEvent { from i : WSDL!Input ( i.oclIsTypeOf(WSDL!Input) ) to o : R2ML!MessageEventExpression ( sender