=Paper=
{{Paper
|id=Vol-153/paper-7
|storemode=property
|title=Modeling Interactions between Web Applications and Third Party Systems
|pdfUrl=https://ceur-ws.org/Vol-153/paper7.pdf
|volume=Vol-153
|dblpUrl=https://dblp.org/rec/conf/caise/MorenoV05
}}
==Modeling Interactions between Web Applications and Third Party Systems==
https://ceur-ws.org/Vol-153/paper7.pdf
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.