Modeling Interactions between Web Applications and Third Party Systems Nathalie Moreno and Antonio Vallecillo Dpto. de Lenguajes y Ciencias de la Computación Universidad de Málaga, Spain {vergara,av}@lcc.uma.es Abstract are also needed, as mentioned in [11]. Although a priori there are no major problems with this Web-based applications are no longer isolated sys- approach, we may face different kinds of incompatibility tems. Now they need to interoperate with external ser- issues when trying to integrate external pieces into the sys- vice providers and legacy systems, which are available in a tem (e.g., external services or legacy applications). For in- wide range of different platforms, and may follow disparate stance, the interface of the services required by our appli- communication mechanisms. Modeling the interactions be- cation (as specified in one of the PIMs) may not match the tween these systems is not simple, and need to be properly interface of the actual service, as provided by the external addressed within any model-driven development scenario. service provider. There is no problem if these incompati- Many of the existing Web Engineering proposals do not take bilities are explicit because they can be easily detected and this fact into account, or address it in a very simplistic way. corrected—as it happens with signature incompatibilities, In this work we use an MDA approach for encapsulating for example. These situations can be treated with the use of the different interaction abstractions and mechanisms into a adaptors, wrappers, or any kind of adaptation techniques. separate platform-independent level, and show the transfor- The major problem appears in the cases of implicit as- mations required to produce platform-specific models de- sumptions on the interaction models and mechanisms fol- pending on the particular details and interaction mecha- lowed by clients and servers. Normally, these assumptions nisms of each technology platform and middleware. are implicitly made by software developers with previous knowledge about how the target platform(s) work. When- ever all the application is generated from the initial PIMs us- 1 Introduction ing a single platform technology, and therefore all parts fol- low the same interaction models and patterns, this problem As the demand and the number of available distributed does not happen. However, when we need to work with ex- Web applications grows, so does the need to easily design, ternal entities, the interactions models of each party should deploy, maintain, integrate and interconnect such Web ap- be made explicit to be able to detect and resolve potential plications in heterogeneous environments. MDA [18, 5] inconsistencies and conflicts at design level. seems to be one of the most promising approaches for ad- This work presents an approach for modeling the com- dressing these issues: it provides the right kinds of abstrac- munication mechanisms between a Web application and its tions and mechanisms for improving the way applications related external systems, that makes explicit both the pro- are integrated and interconnected nowadays. gramming abstractions through which the client and service A proper integration approach requires an structured and provider view the communication, and certain implementa- efficient way to assist software architects and developers tion choices about the selected target platform that generally achieve such integration not only at implementation level, are implicit. This is specially relevant in those contexts in but also during all phases of the development process. In which several platform technologies may be simultaneously this regard, any integration with legacy data and external used. services at the PIM level requires modeling them, too (their In general, there is no standard way of describing imple- structural features, behavioral descriptions, etc.)—allowing mentation decisions such as concurrence, security or trans- the manipulation of the external entities of such systems as action aspects, in order to get computationally complete native elements of our models. Special care should be taken PIMS, i.e., PIMs that contain all the information required in this case with the bridges that connect the system with to produce real program code. its external partners applications, for which transformations Several approaches that address this issue by identify- ing these concerns at different levels of abstraction have ap- 2.1 Calling Service Provider for a Web Applica- peared recently. Almeida et al. [1, 2] introduce the abstract tion platform concept that defines characteristics that must have proper mappings onto the set of concrete target platforms Currently, three main technologies support communica- that are considered for an MDA design process. Following tion between modules of disparate systems, hiding plat- a different approach that uses a UML profile, Witthawaskul form and language specific details: CORBA, Enterprise and Johnson [22] define the unit of work concept which can Java Beans, J2EE and Web Services and .NET. be applied on a UML operation to support platform inde- pendent transaction modeling. Likewise, our work follows an approach based on marks (using a UML metamodel) that CORBA Service Provider. To request a CORBA service guide both the PIM to PSM transformation, and the PSM to provider, the client may follow two approaches [8, 16, 20]: the Implementation Model transformation too. They rep- (i) a static invocation method or (ii) a dynamic invocation resent interaction model capabilities and services provided method. For the former, the client has to acquire at compile- by potential target platforms abstracted and specified in a time an object reference to the CORBA object. Then, this platform-independent way. reference is used to initialize a proxy object that represents the remote object in the client’s address space. For gener- Another controversial issue is related to where imple- ating the proxy implementation, an IDL specification of the mentation decisions are expected to appear: (i) directly in CORBA object is required and compiled into the client pro- the PIM; (ii) in the target platform model, or; (iii) in the gram. IDL specifications can define both synchronous (re- transformation model. The MDA community still struggles quest/reply) operations and asynchronous (one-way) mes- to deal with this issue, as a quick look at the discussion hap- sages. pening in the MDA mailing lists clearly reveals. For dynamic invocations there is no information about The structure of this document is as follows. After this the types and interface specifications of the required introduction, Section 2 provides a brief description of the CORBA service. The client can look this information up by interaction styles supported by technologies like CORBA, querying an Interface Repository (a service that provides Enterprise Java Beans, J2EE, Web Services or .NET. After IDL definitions at run-time). In consequence, a client re- that, Section 3 derives a UML metamodel based on the ex- quest consists of operations for setting the name and pa- isting similarities found among the previous interaction mo- rameters of the request and retrieving the returned values dels. Using this metamodel, Sections 4, 5 and 6 show how or an exception at run-time. Once the client has acquired to apply it in a service-oriented scenario. Finally, Section 7 a valid remote object reference to the CORBA server ob- draws some conclusions and outlines some further research ject, it can call the server object’s methods as if the server activities. object resided in the client’s address space. The mapping of the object name to its implementation is handled by the Implementation Repository. 2 Interaction Models for Web Applications Enterprise Java Beans/J2EE Provider. For a client to call a business method, it needs to go via an EJB object (a generated Java class based on the Component Interface). Currently, Web applications need to interoperate with This means that a client never accesses an enterprise bean third party systems (external portlets, Web services or directly [4, 21]. In this regard, the client has in first place legacy applications) in a variety of ways—interaction to call a factory object (which is the EJB Home Object) to models—which reflect the heterogeneity of applications either locate an existing EJB object or create a new EJB built upon disparate implementation technologies such as object. Once it is generated during compile or deployment J2EE, CORBA or .NET. Generally, each middleware tech- time, EJB objects act as bridges between the client and the nology has its own interaction model, although traditional bean instances [19]. client-server interaction patterns are likely to be common. There are several types of EJBs: session beans, entity A Web application may require to communicate with beans and message-driven beans. The two former kinds of a great variety of systems in different address spaces and beans provide their interfaces to allow remote clients to in- running on heterogeneous platforms—which use different voke them. However, message-driven beans do no make communication abstractions and interaction models. Here public their interfaces. On the contrary, a message-driven we will briefly describe the interaction styles of the most bean listens for messages that are sent using Java Message commonly used technologies, which are able to connect ap- Service and processes them anonymously (asynchronous in- plications implemented using heterogeneous technologies. vocations) [10]. An XML file describes how an Enterprise Java Bean Service should be assembled and deployed, its name, and other ex- Registry ternal dependencies of the bean. Find Publish Java/RMI. This mechanism is tied to the Java program- ming language and virtual machines [9]. RMI allows to invoke operations on Java objects. The client should con- Bind Service Service tact first an RMI registry, and request the name of the ser- requester provider vice. RMI URLs identify services, including the hostname on which the service is located, and the logical name of the service. Then, the registry will point the client to the direc- Figure 1. Basic Interaction Model tion of the service it wants to call. The mapping of Object Name to its Implementation is handled by the RMI Registry. RMI generates proxies and stubs from Java interface def- Step 2. A service requestor discovers those services by initions. Furthermore, RMI uses Java’s capabilities for dy- querying the registry and binds to the selected service. namic linking to load the classes of parameters or returned (Note that we will call the service requester a client) objects over the network, allowing clients or servers to re- ceive objects of classes unknown at compile time. Step 3. Client interacts with service provider. Web Services & .NET Provider. In order for a client to According to Figure 1, an interaction between two end- be able to consume a Web service, the client should know points can be defined in terms of: where the Web service resides and how to invoke its meth- ods (that is, how to serialize the call to the Web service and • The set of messages accepted by the service provider how to deserialize received messages from the Web ser- (Provided Interface) vice). This information is provided by the WSDL speci- fication of the Web service [23]—an XML document that • The set of messages required by the client (Required specifies the data types of the messages, the protocols that Interface) are accepted, the Web service’s endpoint, and the bindings. Since notions involved in creating the SOAP message to • A protocol that defines the partial order between the send to the Web service, making the actual HTTP request, exchanged messages. deserializing the HTTP response, etc. could be complex, • The programming abstractions through which the they are abstracted using a proxy class. A proxy class is client and server view the protocol (the client-side and a class that encapsulates the complexity of calling a Web server-side programming interfaces). This is impor- service and exposes this complexity through a simplified tant, because these programming abstractions encap- interface [12]. From the client application’s perspective, sulate the agreement between both parties on: the data the Web service is simply a local component—the client format, the mechanism for transforming and recon- doesn’t have to worry about the specifics of how to serialize structing object state into this format, the transport pro- a SOAP message, or how to make an HTTP request. tocol, etc. 3 Modeling interactions Most approaches focus just on the first three points. However, the fourth is not explicitly stated or modeled any- 3.1 Interactions where; instead, it is usually implicitly assumed by both the client and the server, and therefore hard-wired into their mo- dels, transformation rules, and code. This is neither flex- The basic interaction model works according to the ible, nor provides the platform-independence required in a three-step process shown in Figure 1, being different true MDA approach. Besides, these assumptions are usually interaction models supported by combinations of this separately made, which may cause contradictory assump- configuration—mainly combinations of the second and tions. Thus, being able to express this kind of information— third steps. particulary the last point—in a Platform-Independent way is a step forward to achieve abstracts models established in Step 1. A service provider publishes a description of their more details that allow code-generation MDA tools to ob- services in a publicly accessible registry. tain really implementations. 3.2 Identifying Model Elements and their Rela- specifies public operations that are remotely available. On tionships the other hand, RequiredInterfaces complement Provided- Interface and describe the features that make up a system that depends on in order to implement its functionality. UML Base Element Stereotype Similar to Interfaces, Ports describe how a System in- Port ¿ServerPortÀ teracts with its environment, but is different in that Inter- Port ¿ClientPortÀ Port ¿StubClientÀ faces contain just syntactic information about methods pro- Port ¿ProxyClientÀ vided by a System and Ports encapsulate the required busi- Port ¿DynamicClientÀ ness logic that allows a Requirer to interact with a Provider, Interface ¿InterfaceSignatureÀ tying that business logic with a concrete “implementation Interface ¿ProvidedInterfaceÀ Interface ¿RequiredInterfaceÀ choice”. Note that in many cases some implementation Assembly Adaptor ¿InteractionÀ choices will only be supported by certain target platforms. Each Port has associated a Protocol that defines the par- Table 1. Summary of the stereotypes used tial order in which the objects expect their methods to be called, and the order in which they should invoke other ob- In our proposal we have tried to use as much as possible ject’s methods. Port’s Protocols show a global perspective existing UML elements, in particular UML 2.0 elements be- over its constituent external applications protocol descrip- cause they provide some useful architectural concepts and tions. For simplicity we have supposed that each Port is mechanisms for our purposes. Table 1 shows a summary of associated with only one Interface, and hence Port’s proto- the profile we have defined for representing these concepts. cols will be coincide with Interface’s protocols. In particular, we consider each system as a UML 2.0 Com- ServerPort’s Protocol can be given inside text files as ponent, which represents “a modular part of a system that BPEL4WS or WS-CDL specifications, for example. On the encapsulates its contents, designs as well as implementa- other hand, ClientPorts interfaces can be augmented with tions features, without losing the ability to describe deploy- behavioral descriptions based on protocol state machines ment information and being replaceable within its environ- that define usage constraints among features of the asso- ment” [17]. ciated interface. Component interactions are carried out through a layer Many aspects of the ClientPort are determined by the of abstraction that allows clients to instantiate and access to external system the client connects to. In consequence, the the methods of the external services provider. In this sense, ClientPort can be classified into three main categories based we can define one or more Ports through which a component on the third party system that they can interact with: invokes and receives method calls. Since each endpoint can act as either a provider or a client in each of the Web interactions in which it plays a (i) Stub Clients are never required to be downloaded or role, we have modeled causality by a Port stereotyped as distributed to clients and they are specific for a cer- ClientPort or ServerPort. tain protocol, transport option and server requirer (ac- The interaction between a ServerPort and a ClientPort corded at compile time). The client must obtain a refer- falls into one of the following categories: ence to the Stub before using it, which represents an in- stance of the server provider. In order to obtain it, both • Synchronous invocation. The ClientPort invokes a re- the remote interface and its implementation have to mote procedure and blocks until a response or an ex- be available so the client relies on an implementation- ception is received from the ServerPort. specific class. • Asynchronous invocation. The ClientPort invokes a (ii) Proxy Clients, as Stub Clients, refer to static invoca- remote procedure and continues processing without tion of server provider methods. They are not portable waiting for a return, although the returned value will across implementations either—in this case, the code be received in any moment. for the Proxy Client is created during runtime, but the • One-way invocation. The ClientPort invokes a remote reference to the interface specification of the external procedure but does not block or wait to receive a return provider is obtained at compile-time. since it will not receive a return value. (iii) Dynamic Clients can access a service discovering its In a first approach we will consider that each Port is asso- interface description dynamically. In the same way, ciated with only one Interface. More precisely, a ClientPort they can invoke server provider methods at runtime. is associated with a RequiredInterface and a ServerPort is This implies an extra work at runtime to fetch and pro- associated with a ProvidedInterface. A ProvidedInterface cess the server interface. At this point, a benefit of using Ports is that the con- 4 Example: The Travel Agency straints and requirements on the communications between applications can be modeled without forcing software de- In order to illustrate the use of interaction patterns in the velopers to take into account the platform specific notions definition of Platform Independent and Platform Specific in their designs. In this way, the designs can be reused to Models, let us consider a Travel Agency service that sells be run on different platforms (hence following the platform- vacation packages to its customers. The packages include independence philosophy dictated by MDA). flights, hotel rooms, car rentals, and combinations of these. The kind of Client Port to be used is important, and External service providers include transportation companies strongly influences the kinds of client-side artifacts that (airlines, hotels and car rentals) and financial organizations need to be generated at development-time. Both Stub and (credit companies and banks). proxy clients require the complete interface specification of To book a vacation package, the customer will pro- the external services. That is, the client does not need to dis- vide details about his preferred dates, destinations, and ac- cover the required service but instead it has, at development- commodation options to the Travel Agency System (TAS). time, to know the external system’s details (location, con- Based on this information, the TAS will request its service figuration file, WSDL or IDL URL, namespace, etc.). In providers for offers that fulfill the user’s requirements, and contrast, Dynamic Clients must dynamically discover and then will present the list of offers to the customer. At this invoke an external system without any prior knowledge of point, the customer may either select one of the offered its details (signature of the remote procedure or the name packages, reject them all and quit, or refine his requirements of the service). For a Dynamic Client, there is no coupling and start the process again. If the customer selects one of between the service interface and the client. This makes the the packages, the TAS will book the individual services to client code easy to modify if the external systems specifica- the corresponding transportation companies, and charge the tions change. customer. The straightforward application of MDA to develop a On the other hand, one of the most significant differ- system is based on the following steps: ences between Stub Clients and Proxy Clients is how exter- nal functionality is invoked. For the former, the client-side Step 1 Create class diagram (PIM) describing object programming interface is embedded inside the client busi- model. ness logic. On the contrary, for Proxy Client and Dynamic Client, the client-side code is packaged apart from the client Step 2 Mark PIM elements with stereotypes. application. Step 3 Customize the marked PIM with annotations. Please note that the selection of these Ports only affects the client side. From the server perspective, it only receives Step 4 Specify the target platform. and returns messages which are identical for all client types. Step 5 Generate a PSM. In general, the MDA software development process be- 3.3 Adaptors comes an iterative model transformation process where each step transforms one (or more) PIM of the system at one level into one (or more) PSM at the next level until a final implementation model is reached (see Figure2). Here, In case there is a strong requirement of using an exter- an implementation model is just another PSM, which pro- nal service provider (e.g., for Stub Clients), the software vides all the information needed to construct a system and designer can specify what should be done if the behav- to put it into operation). ior/specification of both parties is incompatible. Since we Note that, we will call technology platform to the last have available the interface of the required external systems platform (i.e., the one that provides the executable PSM, or (provided interfaces), we can carry out static checking for implementation). The intermediate platforms that transform comparing them and determining whether they fulfil our re- PIMs into PSMs that will be used as PIMs in the next step quirements (required interfaces). are considered as abstract platforms. If not, the designer can decide at designing-time to im- Given that an element of the PIM may be marked several plement an intermediate business logic (adaptors) that con- times with marks that come from different metamodels, it forms to a given interface or consume a required exter- will be transformed according to each of the mappings. The nal system. Adaptors mediates between the ClientPort and semantic of the resulting marked element is given by the ServerPort interactions, resolving service provider and ser- gathered features through the MDA model transformation vice requester differences at interface and protocol levels. process. ify/mark: the system elements that require code generation; the system elements that will be remotely accessed using its PIM provided interface specifications and implementations; the * system elements that need to interact with others; and the M arks system properties that are used for identifying them. All this is done in this first phase in a platform-independent man- ner, i.e., independently from the communication asbtrac- tions and mechanisms used, and the platforms in which our system and the external services are implemented. These details will be added in the second phase. M arked In the first place we need to create the PIM of the system, PIM which in our case is shown in Figure 3. It is focused just on the operation of the system, while hiding the rest of the Annotations details (software architecture, distribution, system bound- aries, communication protocols, implementation platforms, etc.). This solution is specified in terms of UML pack- ages and their interconnections in a platform independent way, where no implementation decisions have been explic- Annotated itly specified (what greatly simplifies the application PIM PIM making it reusable across different target platform environ- ments). M appings air_lines Air_lines +find_flight( inf_req : Fly_req ) : Fly_list +reserve_flight( fly_sel : Fly_Inf ) : Reserv +pay_flight( pay_inf : Pay_Inf ) : Ack_pay car_hire +cancel_flight( reserv_inf : Reserv ) : Ack_cancel PSM Car_Hire +find_car( car_req : Car_req ) : Car_list +reserve_car( car_sel : Car_Inf ) : Reserv +pay_car( pay_inf : Pay_Inf ) : Ack_pay travel_agency +cancel_car( reserv_inf : Reserv ) : Ack_cancel Travel_AG +find_travel( travel_req : Travel_req ) : Travel_list Figure 2. The PIM to PSM iterative process +reserve_travel( travel_sel : Travel_Inf ) : Reserv +pay_travel( pay_inf : Pay_Inf ) : Ack_pay hotel +cancel_travel( reserv_inf : Reserv ) : Ack_cancel Hotel +find_room( room_req : Room_req ) : Room_list +reserve_room( room_sel : Room_inf ) : Reserv +pay_room( pay_inf : Pay_Inf ) : Ack_pay +cancel_room( reserv_inf : Reserv ) : Ack_cancel In our approach we need to go though two main phases. bank Firstly, we need to identify the system scope and bound- Bank aries, i.e, which services will be provided by our system, +make_payment( pay_inf : Pay_Inf ) : Ack_pay and which ones will be externally required. The result of this phase is a high-level architectural view of the services and components of our global system. In the second phase, Figure 3. The TAS PIM we need to determine the concrete platforms and communi- cation mechanisms between our application and the external systems identified previously. As previously mentioned, any integration to legacy data and services may require that the interfaces to those ele- 5 Identifying the scope and boundaries of our ments are also modeled. The kind of information that is system available from them will allow us to check whether they match our requirements or not, as described by the system In our previous work [15], we presented a model-based model [14]. More precisely, this information should be able framework that allows the high-level integration of Web ap- to allow us to: plications with third party systems aligned with the MDA (a) model the component or legacy system (e.g., by de- principles. It enables the manipulation of the external enti- scribing its structure, behavior, and choreography); ties and systems as native elements of our models. At design level, software developers are able to spec- (b) check whether it matches the system requirements (this is also known as the gap analysis problem [7]); Note that the marked PIM is, by definition tech- nology independent. In consequence, the prefix “Ex- (c) evaluate the changes and adaptation effort required to ternal” used by the stereotypes ¿ExternalSystemÀ and make it match the system requirements (i.e., evaluate ¿ExternalAssociationÀ in Figure 4 does not imply any im- the distance between the models of the “required” and plementation decisions. Instead, it is only used to limit the the “actual” services, see e.g., [13]); and system scope that has to be development. Once we have the marked PIM, we need to transform it (d) ideally, provide the specification of an adaptor that re- into a PSM that can be translated into a target implemen- solves these possible mismatches and differences (see tation code. As “platform” we will use here the UML 2.0 e.g., [6]). constructs and infrastructure for describing software archi- tectures, because what we want to build in this phase is the Although the integration of third party systems with a software architectural description (i.e., model) of the sys- Web application should be address at three levels of ab- tem. This transformation will be guided by the following stractions (e.g., at presentation, business process and data mapping rules: level) [15], for the sake of simplicity in this paper we will only consider the process level. • Packages transformation. Each UML package is Once the high-level PIM is identified, we need to iden- mapped to a UML ¿ComponentÀ initialized with the tify the system scope and boundaries, and then build a same of its corresponding UML package. model of the system with this information. That tar- get model (PSM) will be built by transforming the orig- • Classes transformation. The UML class stereo- inal PIM using marks. To identify the elements in typed as ¿InternalSystemÀ or ¿ExternalSystemÀ is the TAS PIM that should be transformed in a particular mapped to a UML ¿ClassÀ holding the same char- way, we will use the stereotypes ¿ExternalSystemÀ and acteristics as its original (name, attributes and opera- ¿ExternalAssociationÀ. An ¿ExternalSystemÀ defines tions). any other external system interacting with the system under • Associations transformation. For each UML associa- consideration. In the same way, an ¿ExternalAssociationÀ tion stereotyped as ¿ExternalAssociationÀ two com- defines an interaction between the system under deployment ponent ports will be generated, each one as Associa- and an ¿ExternalSystemÀ. tion ends of that relationship. Ports will be associated Implicitly, each type of model element in the PIM is to the UML ¿ComponentÀ derived in previous step. only suitable for certain marks, which indicate what type Its behavior is defined in terms of an interface associ- of model element will be generated in the PSM. ated with that port, which specifies the nature of the in- Marks are not a part of the platform independent model teractions that may occur over that port. Thus, the port although they appear on the marked PIM (see Figure 4). interface’s name is given the value of the UML class name from which it derives and its operations corre- air_lines spond to its UML class operations. • Association’s ends transformation. For the end- <> Air_lines +find_flight( inf_req : Fly_req ) : Fly_list +reserve_flight( fly_sel : Fly_Inf ) : Reserv point of an ¿ExternalAssociationÀ stereotyped as +pay_flight( pay_inf : Pay_Inf ) : Ack_pay +cancel_flight( reserv_inf : Reserv ) : Ack_cancel car_hire ¿InternalSystemÀ a usage dependency from the <> port to the interface is generated, showing how the <> Car_Hire <> +find_car( car_req : Car_req ) : Car_list ¿InternalSystemÀ provide a set of services. travel_agency +reserve_car( car_sel : Car_Inf ) : Reserv +pay_car( pay_inf : Pay_Inf ) : Ack_pay <> +cancel_car( reserv_inf : Reserv ) : Ack_cancel For the endpoint of an ¿ExternalAssociationÀ stereo- Travel_AG typed as ¿ExternalSystemÀ an implementation de- +find_travel( travel_req : Travel_req ) : Travel_list +reserve_travel( travel_sel : Travel_Inf ) : Reserv hotel pendency from the port to the interface is generated, +pay_travel( pay_inf : Pay_Inf ) : Ack_pay +cancel_travel( reserv_inf : Reserv ) : Ack_cancel <> showing how the ¿ExternalSystemÀ require a set of Hotel <> +find_room( room_req : Room_req ) : Room_list services. +reserve_room( room_sel : Room_inf ) : Reserv <> +pay_room( pay_inf : Pay_Inf ) : Ack_pay bank +cancel_room( reserv_inf : Reserv ) : Ack_cancel • Finally, an assembly connector is defined from a re- <> Bank quired Interface to a provided Interface. +make_payment( pay_inf : Pay_Inf ) : Ack_pay Applying these mapping rules on the PIM in Figure 4, we obtain the PSM shown in Figure 5. Figure 4. The marked TAS PIM As previously mentioned, the MDA software develop- ment process is an iterative model transformation process Bank Hotel Travel_Ag Bank Hotel Travel_Ag +make_payment( ... ) : Ack_pay +find_room( ... ) : Room_list +find_travel( ... ) : Travel_list +reserve_room( ... ) : Reserv +reserve_travel( ... ) : Reserv +pay_room( ... ) : Ack_pay +pay_travel( ... ) : Ack_pay +cancel_room( ... ) : Ack_cancel +cancel_travel( ... ) : Ack_cancel Air_Line Car_Hire Air_Line Car_Hire +find_flight( ... ) : Fly_list +reserve_flight( ... ) : Reserv +find_car( ... ) : Car_list +pay_flight( ... ) : Ack_pay +reserve_car( ... ) : Reserv +cancel_flight( ... ) : Ack_cancel +pay_car( ... ) : Ack_pay +cancel_car( ... ) : Ack_cancel Figure 5. The PSM after applying the MDA transformation whereby a PIM is transformed into a PSM, which in turn Now it is the time to include information about the tech- becomes the PIM for the next transformation—until a final nologies used to interact with the external services. PSM (the system implementation) is reached. What counts In the particular case of the Travel Agency System, we as a platform depends on the level of abstraction, and the are going to make use of external service providers which kind of system being developed. include transportation companies (airlines, hotels and car rentals) and financial organizations (credit companies and banks). For illustration purposes we have selected different 6 A Platform Specific Interaction-Model technologies for each external service. More precisely: Once we have the (UML 2.0) architectural description • A CORBA implementation of the Hotel Service. As of the system, that identifies its scope and interactions with previously mentioned, to participate in an interaction external services, the next phase focuses on the specifica- with a CORBA server application, the client (that is, tion of such external interactions using the particular plat- our Travel Agency Service) must be able to get an ob- forms and communication mechanisms of the required ser- ject reference for a CORBA object and invoke opera- vices. By adopting an MDA transformation process based tions on the object. To accomplish this, the client need on marks and annotations, we have to define the marks and information about references to the environmental ob- transformations required. jects that provide services for the CORBA application Basically the information that the transformation process we plan to use and the IDL specification for imple- has to generate from the marked PIM is: the communica- menting a stub-style invocation. Figure 7 shows how tion mechanisms between the Components; how the com- this information is specified using notes associated to munications will be carried out; and the information that its corresponding stereotypes. describes the architecture of the Web application. There- fore, the model shown in Figure 5 have to be marked again • Another CORBA implementation of the CarHire Ser- to specify that information. vice. In this case, we plan to implement a dynamic interaction pattern so the IDL file will be looked up Once we have applied previous transformation rules on into an Interface Repository where it must be stored. the PIM, the resulting PSM is also platform-independent. In that sense, no IDL file has to be provided by the We will mark them with decisions which are considered external server provider. and taken in the context of a specific implementation design based on the concepts discussed in Section 3: The exact steps taken to access the Interface Reposi- tory depend on whether the client is seeking informa- • Ports that specify services provided by external entities tion about a specific object, or browsing the Interface are stereotyped as ¿ServerPortsÀ Repository to find an interface. In both cases, before a dynamic client can browse the Interface Repository, • Ports that specify required services are stereotyped as it needs to obtain the object reference of the Interface ¿ClientPortsÀ. Repository to start the search. Once the client has the object reference, it can navigate the Interface Reposi- • Finally, assembly adaptors connecting interfaces have tory, starting at the root. been stereotyped as ¿InteractionsÀ. • The two others external services are supposed to be The resulting model is shown in Figure 6. available as external Web services. Their respec- Bank Hotel <> Travel_Ag <> <> <> <> <> Bank Hotel Travel_Ag +make_payment( ... ) : Ack_pay +find_room( ... ) : Room_list +find_travel( ... ) : Travel_list +reserve_room( ... ) : Reserv +reserve_travel( ... ) : Reserv +pay_room( ... ) : Ack_pay +pay_travel( ... ) : Ack_pay +cancel_room( ... ) : Ack_cancel +cancel_travel( ... ) : Ack_cancel Air_Line <> <> <> Car_Hire <> Air_Line <> <> Car_Hire +find_flight( ... ) : Fly_list +reserve_flight( ... ) : Reserv +find_car( ... ) : Car_list +pay_flight( ... ) : Ack_pay +reserve_car( ... ) : Reserv +cancel_flight( ... ) : Ack_cancel +pay_car( ... ) : Ack_pay +cancel_car( ... ) : Ack_cancel Figure 6. Marked PIM type= WSDL_Interface file= http://.../BANK.wsdl type= CORBA_Interface file= http://.../HOTEL.idl <> <> namespace=http://bank.com namespace=http://bla.bla.com portName = bank <> <> <> protocol_FILE =... protocol_FILE =... type= Asynchronous host_port= //trixie:3500 host_port= //bank:3500 namespace=http://bla.bla.com namespace=http://bla.bla.com protocol_FILE =... protocol_FILE =... <> invocation_type= Asynchronous Bank Hotel Travel_Ag <> <> <> <> <> <> Bank Hotel Travel_Ag +make_payment( ... ) : Ack_pay <> +find_room( ... ) : Room_list +find_travel( ... ) : Travel_list +reserve_room( ... ) : Reserv type= Asynchronous +reserve_travel( ... ) : Reserv +pay_room( ... ) : Ack_pay +pay_travel( ... ) : Ack_pay <> +cancel_room( ... ) : Ack_cancel +cancel_travel( ... ) : Ack_cancel type= Asynchronous Air_Line <> <> <> Car_Hire <> <> <> Air_Line Car_Hire +find_flight( ... ) : Fly_list +reserve_flight( ... ) : Reserv <> <> +find_car( ... ) : Car_list +pay_flight( ... ) : Ack_pay +reserve_car( ... ) : Reserv namespace=http://bla.bla.com domain = .. +pay_car( ... ) : Ack_pay +cancel_flight( ... ) : Ack_cancel protocol_FILE = ... namespace=http://bla.bla.com protocol_FILE =... +cancel_car( ... ) : Ack_cancel type= CORBA_Interface type= WSDL_Interface file= http://.../AIR_LINE.wsdl <> <> domain = ... namespace = http://bla.bla.com namespace=http://bla.bla.com protocol_FILE =... protocol_FILE =... host_port= //airline:3500 implementation_FILE= .... Figure 7. The Annotated TAS PIM tive WSDL interface descriptions are required as il- tation class. A service endpoint interface declares the lustrated Figure 7. Additionally, the code for the in- methods that a remote client may invoke on the ser- teraction with the Airline Web service relies on an vice. In this regard, each UML class is mapped to implementation-specific class since it use an stub- a ¿JavaClassÀ initialized with the same character- style. This means that its implementation should be istics of its corresponding UML class. Based on it, the also available. ¿JavaInterfaceÀ is also derived. At this point, we also need to decide on the implementa- 2. Build, generate, and package the files required by tion technologies and platforms of our own system. Imagine the service. In this sense, each UML class is also that we decide to implement the Travel Agency using Java mapped to a ¿WSDL SpecificationsÀ: ¿WSDL and Web Services technologies. typesÀ, ¿WSDL operationsÀ, ¿WSDL bindingsÀ In this case we could use the transformation rules of any and ¿WSDL servicesÀ. of the existing approaches for converting our marked and annotated PIM (in Fig. 7) to the corresponding PSM (shown 3. Deploy the service. Four deployment files are in Fig. 8). For instance, we could follow the approach by required: web.xml, jaxrpc-ri.xml, config-wsdl and Bezivin et al. [3], and then proceed according to the follow- config-interface. In this sense, the ¿JavaClassÀ is ing steps: mapped to a ¿JWSDPweb.xmlÀ, ¿JWSDPjaxrpc- ri.xmlÀ, ¿JWSDPconfig-wsdlÀ and ¿JWSDPconfig- 1. Code the service endpoint interface and its implemen- interfaceÀ files. <> <> <> References Tra vel_Ag_wsdl Travel_Ag_uddi Travel_Ag_web travel_agency <> Int_Travel_Ag <> Travel_Ag [1] J. P. Almeida, R. Dijkman, M. van Sinderen, and L. F. Pires. +find_travel( travel_req : Travel_req ) : Travel_list +reserve_travel( travel_sel : Travel_Inf ) : Reserv +pay_travel( pay_inf : Pay_Inf ) : Ack_pay +find_travel( travel_req : Travel_req ) : Travel_list +reserve_travel( travel_sel : Travel_Inf ) : Reserv +pay_travel( pay_inf : Pay_Inf ) : Ack_pay On the notion of abstract platform in mda development. In +cancel_travel( reserv_inf : Reserv ) : Ack_cancel +cancel_travel( reserv_inf : Reserv ) : Ack_cancel The 8th International IEEE Enterprise Distributed Object <> Travel_Ag_interfaceStub <> Travel_Ag_interfaceHelper <> Travel_Ag_interfaceHolder Computing Conference, pages 253–263, Monterey, Califor- nia, USA, Sept. 2004. IEEE Computer Society. <> <> <> [2] J. P. Almeida, R. Dijkman, M. van Sinderen, and L. F. Pires. Travel_Ag_jaxrpc-ri Travel_Ag_config-wsdl Travel_Ag_config-interface Platform-independent modeling in mda: Supporting abstract platforms. In Proceedings of Model Driven Architecture: Figure 8. PSM Foundations and Applications (MDAFA 2004), pages 217– 231, June 2004. [3] J. Bezivin, S. Hammoudi, D. Lopes, and F. Jouault. Ap- plying MDA approach to B2B applications: A road map. Workshop on Model Driven Development (WMDD 2004) at 4. Generate client-side abstractions for consuming exter- ECOOP 2004, Oslo, Norway, Springer-Verlag, LNCS, 3344, nal services. For the CORBA services, we will add: 2004. the client stubs for each interface (interfaceStub.java), [4] D. Blevins. Overview of the enterprise javabeans component the CORBA helper class (interfaceHelper.java) and the model. In Component-Based Software Engineering: Putting CORBA holder class (interfaceHolder.java) that de- the Pieces Together, pages 589–606. Addison-Wesley, 2001. scribe everything it is needed to use the client stub [5] A. W. Brown. Model driven architecture: Principles and from the Java programming language. For the rest of practice. Software System Model, 3:314–327, 2004. the services, no more classes are generated. On the [6] R. Bruni, H. Melgratti, and U. Montanari. Theoretical foun- contrary, the code is embedded in the ¿JavaClassÀ dations for compensations in flow composition languages. implementation. SIGPLAN Not., 40(1):209–220, 2005. [7] J. Cheesman and J. Daniels. UML components: a simple process for specifying component-based software. Addison- The PSM obtained, shown in Figure 8, includes all the Wesley Longman Publishing, Boston, MA, USA, 2000. details required to build the final implementation. [8] M. Henning and S. Vinoski. Advanced CORBA Program- ming with C++. Addison-Wesley, 1999. [9] JavaRMI. Remote Method Invocation. Sun Microsystems, 7 Conclusions and Future Works 2004. http://java.sun.com /j2se /1.4.2 /docs /guide /rmi /spec /rmiTOC.html. [10] Juan. bla bla, volume 3. p, p edition, p 2005. In this paper we have discussed some of the (many) prob- [11] A. Kleppe, J. Warmer, and W. Bast. MDA Explained. lems that may happen when integrating Web-based appli- The Model Driven Architecture: Practice and Promise. cations with external systems. In particular, we have con- Addison-Wesley, Apr. 2003. centrated on the interaction issues due to potential incom- [12] Microsoft Corporation. .NET Web Page, 2004. patibilities between clients and servers of different imple- http://www.microsoft.com/net/. mentation platforms and middlewares. Our main contribu- [13] R. Mili, J. Desharnais, M. Frappier, and A. Mili. Semantic distance between specifications. Theoretical Comput. Sci., tion is to make such interaction models and mechanisms 247:257–276, Sept. 2000. explicit, so incompatibilities can be detected, and bridges [14] N. Moreno and A. Vallecillo. What to we do with re-use in or adapters can be easily built. Besides, we have done it MDA? Second European Workshop on Model Driven Archi- according to the MDA principles, encapsulating those inter- tecture (EWMDA-2), Sept. 2004. Canterbury, Kent. action concepts and mechanisms in a platform-independent [15] N. Moreno and A. Vallecillo. A model-based approach for manner, and then providing transformation rules to the dif- integrating third party systems with web applications. Fifth ferent implementations available of these concepts in most International Conference on Web Engineering (ICWE2005), commonly used platforms and middelwares. July 2005. Sydney, Australia. Now that the interaction issues are solved at this level, [16] Object Management Group. CORBA 3.0 - IDL Syntax and Semantics Chapter, 2002. we plan to move forward, trying to address two other major http://www.omg.org/docs/formal/02-06-39.pdf. issues. First, the (semi-)automatic derivation of adaptors in [17] Object Management Group. UML 2.0 Superstructure Spec- case incompatibilities are detected at this level. And sec- ification, 2003. http://www.omg.org/cgi-bin/doc?ptc/03-08- ond, move up one level of abstraction, and study how to 02.pdf. model systems so potential mismatches that may happen at [18] OMG. Model Driven Architecture. A Technical Perspec- the behavioral semantic or contract (e.g., QoS) level can be tive. Object Management Group, Jan. 2001. OMG docu- detected. ment ab/2001-01-01. [19] OpenEnterpriseX. Just Enough Enterprise Java Beans Con- cepts, 2004. http://www.OpenEnterpriseX.org. [20] J. Siegel. CORBA 3. Fundamentals and Programming. John Wiley & Sons. OMG Press, 2000. [21] Sun Microsystems. The J2EE 1.4 Tutorial, June 2004. http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html. [22] W. Witthawaskul and R. Johnson. Transaction support using unit of work modeling in the context of MDA. Available from http://weerasak.com/Unitf, Mar. 2005. [23] Web Services Description Language (WSDL) 1.1, 2001. http://www.w3.org/TR/wsdl.