Methods for web services based application development. Part 1

(1)

Methods for web services

based application

development

Part 1

(2)

(3)

Colophon

Date : 01-08-03

Version : 0.9

Change :

Project reference: WASP/D3.4 Part 1

TI reference :

Company reference :

URL : https://doc.telin.nl/dscgi/ds.py/View/Collection-5154

Access permissions : Public

Status : Final draft

Editor : João Paulo A. Almeida

Company : University of Twente, Ericsson, Telematica Instituut

Author(s) : João Paulo A. Almeida

Luís Ferreira Pires Marten van Sinderen

Synopsis:

The objective of this document is to propose an approach to web services development based on the separation of platform-specific aspects from platform-independent aspects of designs. Platform-specific aspects include web services-specific aspects and aspects of web services hosting

(4)

(5)

Abstract

We propose an approach to (web services) development based on the separation of platform-specific aspects from platform-independent aspects of designs. Platform-specific aspects include web

services-specific aspects and aspects of web services hosting platforms. Web services hosting platforms are

necessary for web services realization and include programming languages (Java, .NET languages, C++), middleware platforms (Java RMI and JMS, .NET, CORBA) and component architectures (EJB, .NET, CCM). Our approach is proposed within the context of the Model-Driven Architecture defined by the Object Management Group (OMG). We identify modelling techniques to be used at platform-independent level and mappings to Web Services abstractions and abstractions of web services implementation

(6)

(7)

1 Introduction

1.1 Motivation

Methods for application development that take into account Web Services technologies should take into account the constructs available for the design of web services (provided by XML / XML Schema, WSDL and SOAP), and the scenarios in which Web Services technologies are used. With respect to this latter issue, we assume that:

- Web services are mostly developed by different and independent implementation authorities;

- Web services often expose part of a large (existing) back-end system; and that

- Web services are implemented in different web services hosting platforms, with diverging platform characteristics. Web services hosting platforms are necessary for web services realization and include programming languages (Java, .NET languages, C++), middleware platforms (Java RMI and JMS, .NET, CORBA) and component architectures (EJB, .NET, CCM). This scenario is depicted in Figure 1.1 .NET J2EE EAI CCM SOAP Utilities (UDDI) Intra-domain abstractions Inter-domain abstractions WSDL

web services hosting platforms

Figure 1.1: Web Services are realized in different web services hosting platforms

In order to enable the cooperation of distributed applications with the assumptions presented, Web Services must accommodate the heterogeneity of web services hosting platforms. Not only interoperability may be hindered by the heterogeneity of platforms, but also application portability and the provision of transparency for the application developer. Ideally, application developers should manipulate a set of

(10)

consistent higher-level constructs to access both the services that are located within the same technology domain and services that are implemented in other technology domains.

In this sense, Web Services technologies on their own can only offer a solution if they are adopted for all future intra-domain development. This would mean that the abstractions manipulated in Web Services languages and protocols should be used as a starting point for development of applications at the first place. Given the proposed use of Web Services as a technology for the integration of applications and services implemented on top of different middleware platforms, it is unlikely that Web Services will replace existing middleware platforms. This is corroborated with the fact that some of these platforms are

flourishing now and have strong Web Services support such as the J2EE and .NET platforms. If Web Services are confined to inter-domain interoperation, abstractions manipulated by intra-domain middleware platforms will indeed diverge from abstractions manipulated across technology domains, and there will always be a “seam” between the abstractions manipulated in a technology domain and abstractions used in inter-domain interoperation. As a consequence, a large effort in the development of web services is concentrated on the (manual) coding of wrappers to existing applications.

Abstractions of particular domains are not the only obstacles for seamless interoperation. For applications to achieve meaningful interaction, they must agree on the application protocols they use. These protocols have been called application choreographies [SchmidtVinoski] in the context of web services, and refer to the behavioural or dynamic aspects of an application or application parts that cooperate. Behaviour complements static aspects of a system, such as interface signatures, data structures and deployment descriptors.

1.2 Objectives

The objective of this document is to present a model-driven approach for Web Services-based application development, in the context of the Model-Driven Architecture (MDA) defined by the Object Management Group (OMG) [OMG-ORMSC/010701].

Our approach provides guidelines for a developer to describe an application in terms of

platform-independent and platform-specific models. Platform-specific models rely on Web Services-specific aspects (e.g., what is implied by the use of XML Schema and WSDL) and aspects of web services hosting

platforms (the constructs implied by middleware platforms and programming languages).

The separation of platform-independent and platform-specific concerns improves portability by allowing developers to re-use platform-independent models to target different web services hosting platforms. The ability to target different web services hosting platforms supplements web services standardization, in which portability conventions are left to be defined only for particular web services hosting platforms (e.g.,

(11)

as defined in EJB 2.1 [EJB2.1] and Servlet 2.4 specifications [Servlet2.4]), and there is little or no portability of web services implementations across hosting platforms provided by different vendors (e.g., between J2EE and .NET platforms).

Besides that, the separation of independent concerns protects effort invested in platform-independent modelling from changes in Web Services standards. For example, it would be possible to reuse platform-independent models for targeting web services that comply with new versions of WSDL or other descriptions languages, or that comply with extended Web Services architectures such as defined in the Open Grid Services Infrastructure (OGSI) [OGSI].

Platform-independent models may also be used to facilitate application integration at platform-independent level. These models can be used as a basis for the generation of wrappers to bridge the gap between Web Services abstractions and abstractions of the various web services hosting platforms, reducing the effort invested in the manual coding.

1.3 Structure

This document is further structured as follows. In Section 2, we introduce OMG’s MDA, and present some of the core technologies and standards within the MDA. We proceed, in Section 3, by defining

requirements to customize the MDA for the development of web services, and presenting an overview of our approach. In Section 4, we present a technique for platform-independent modelling and, in Section 5, we present the relation between platform-independent and platform-specific models. In Section 6, we identify requirements for supporting the approach we propose in MDA tools. Finally, in Section 7, we present some conclusions and outlook on future work.

(12)

2 Model-Driven

Architecture

2.1 Overview

The MDA [OMG-ORMSC/010701] is an approach to system (application) specification, portability and

interoperability based on the use of formal and semi-formal models. From the perspective of systems

development, a significant quality of the MDA approach is the independence of system specifications (i.e., sets of models) from potential target implementation platforms. A system specification exists independently of any implementation platform and has formal or semi-formal transformation rules to many possible target platforms. The effort invested in developing platform independent models is protected from changes in platforms. Furthermore, model transformation rules may be implemented in model-driven tools to (partially) automate the transformation of platform-independent models into platform-specific models, increasing the level of automation of the development trajectory. Figure 2.1 illustrates a scenario in which platform-independent models are not affected by platform changes.

Model Stability Platform Change Platform-independent models Platform-specific models

Figure 2.1: Platform-independent models are not affected by platform change

From the perspective of systems interoperability, the use of platform-independent models facilitates the creation of different platform-specific models corresponding to the same set of platform-independent models, which results ultimately in implementations that are easily (if not automatically) integrated.

Platform-independent models also play an important role in the re-use of legacy applications. In this case, integration is done at a platform-independent level, using platform-independent models that represent the legacy application. These platform-independent models are derived by reverse engineering.

(13)

The core of the MDA is made up by a number of OMG standards, including: the Unified Modelling Language (UML) [UML1.5], the Meta Object Facility (MOF) [MOF1.4], and the XML Metadata Interchange (XMI) [XMI1.2].

2.2 Platform-independent and platform-specific models

The MDA is based on the notion of model. In the MDA, a model is a representation of (a part of) the function, structure and/or behaviour of a system in a language that has a well-defined syntax, semantics, and possibly rules of analysis, inference, or proof for its constructs [OMG-ORMSC/010701]. Examples of models are UML class diagrams, IDL interfaces and Java source code.

The term platform is used to refer to technological and engineering details that are irrelevant to the fundamental functionality of a system (part) [OMG-ORMSC/010701]. A platform-independent model is a model that does not depend on, or rely on characteristics of a particular platform. In order to refer to platform-independent or platform-specific models, one must define what a platform is, i.e., one must define which technological and engineering details are irrelevant in a particular context.

The current OMG Request For Proposal (RFP) template [RFP-Template] defines platform as: ”A set of subsystems/technologies that provide a coherent set of functionality through interfaces and specified usage patterns that any subsystem that depends on the platform can use without concern for the details of how the functionality provided by the platform is implemented.”

If the set of technologies that define a platform comprehends middleware platforms, such as, e.g., CORBA and Web Services, a CORBA IDL specification is a platform-specific model. In contrast, if the set of technologies that define a platform comprehends programming languages and CORBA ORB implementations, such as, e.g., the C++ language and the C++ ORB implementation, a CORBA IDL specification is a platform-independent model.

2.3 Metamodelling

In the MDA, metamodels are used to support the definition of syntax and semantics of models. When a model B is used to describe a model A, B is said to be the metamodel of A. In an alternative formulation, one can say that the abstract syntax of the model A is defined in the metamodel B. In yet another formulation, one can say that the model A is an instance of the metamodel B.

Figure 2.2 shows an example of a model and its metamodel. The elements of the model are instances of the elements of the metamodel: the classes Employer and Employee are instances of the meta-class

(14)

Class. The association between Employer and Employee is an instance of the meta-class Association. Class Association Employer * * Employee * 1 «instance» «instance» «instance» metamodel model

Figure 2.2: A model and its metamodel

The abstract syntax of a metamodel B can also be described in yet another metamodel C, sometimes called meta-metamodel. Although the number of meta-levels is arbitrary, metamodelling frameworks should define a limited number of useful meta-levels.

Metamodels are usually accompanied by natural language descriptions of concepts that correspond to elements of the metamodel, defining informally the semantics of the modelling elements. This approach has been adopted by OMG in the Meta-Object Facility (MOF) [MOF1.4] and in the UML standards [UML1.5].

2.4 Model transformation

A particular pattern explored extensively in model-driven engineering is the use of model transformation. Model transformation is basically seen as a mapping of elements of one model onto elements of another model. An instance of usage of this pattern is the creation of software systems by code generation. Each generated artefact, either some code in a programming language or some textual deployment artefact can be manipulated as a model. These models are based on a defined structure, which itself forms a

metamodel, which can be expressed in terms of the UML and/or MOF standards.

Model transformation is useful if formally or systematically defined. As depicted in Figure 2.3, a

transformation may be defined at the level of metamodels. When transformation is applied, a source model is transformed into a target model according to the defined transformation (rules).

(15)

Source Meta-Model Transformation Source Model Target Meta-Model Target Model Meta- Meta-Model1 apply transformation define transformation instance of instance of instance of Meta- Meta-Model2 instance of

Figure 2.3: Model transformation defined at the meta-level

According to OMG definitions, a metamodel is based and constructed from elements of an underlying meta-metamodel (the MOF) and a model is constructed from elements of the metamodel. The use of a common meta-metamodel for the target and source metamodels, as illustrated in Figure 2.4 may facilitate the definition of transformations.

Source Meta-Model Transformation Source Model Target Meta-Model Target Model Meta- Meta-Model apply transformation define transformation instance of instance of instance of instance of

(16)

The model transformation pattern can be applied successively. In this case the notions of source and target models are relative. An intermediary model is considered a target model from the perspective of the transformation from the source model, and the same intermediary model is considered a source model from the perspective of the transformation to the final target model. This is illustrated in Figure 2.5.

Source Meta-Model Source Model Intermediary Meta-Model Intermediary Model Transformation 1 apply transformation define transformation instance of instance of Target Meta-Model Target Model instance of apply transformation define transformation Transformation 2

Figure 2.5: Successive model transformations

In order to allow a developer to guide the transformation of a source model when necessary,

transformations may be parameterised. An annotation model may be used to contain the parameters for a transformation. The application of the transformation may include a step that transforms the source model into an annotated source model and then proceeds with the transformation. This is illustrated in Figure 2.6.

Source Model Target Model apply transformation Annotation Model Annotated Source

Model _{apply transformation} apply annotations

(17)

3 Model-driven development of web services

3.1 Requirements

For an MDA project to be successful, MDA core technologies and standards have to be complemented with a development trajectory that identifies concrete modelling techniques, models (deliverables) to be

produced and model transformations. This translates into the following requirements for our approach:

- Platform-independent modelling techniques must be identified, which include concepts and

notations for specifying models. General requirements for modelling techniques have been identified in deliverable D3.2 of the WASP Project [WASP-D3.2].

- Web-Services-specific modelling techniques should be identified. These include core Web

Services languages such as WSDL and XML Schema, and potentially additional description languages such as WSCI and/or BPEL4WS.

- Web Services hosting platform-specific modelling techniques should be identified. These include

Java (interfaces), CORBA IDL, .NET source code, and other relevant artefacts from target Web Services hosting platforms considered.

- Platform-independent models should service as input to transformations that produce Web Services-specific artefacts and Web Services hosting platforms-specific artefacts.

- Platform-independent models should be produced through transformation from Web Services-specific artefacts and Web Services hosting platforms-Services-specific artefacts.

3.2 Overview

An overview of the models defined in our approach is depicted in Figure 3.1. The arrows represent transformations from and to source and target models.

(18)

WS Hosting Platform- specific models Platform-independent models in terms of WSDL, XML Schema, WSCI or BPEL4WS in terms of J2EE/JAX-RPC, .NET/XML Web Services, etc.

Web Services-specific models

+

Figure 3.1: Models considered in the approach (with different levels of platform-independence)

In Figure 3.2 we show a revised Figure 1.1, which illustrates that several different target web services hosting platforms are considered as target platforms. Transformations define the correspondence between the platform-independent view and the platform-specific views.

.NET EJB / Java EAI CCM / C++ Web Services WSDL SOAP EDOC-CCA

(19)

4 Platform-independent

modelling

The OMG has standardized the EDOC (Enterprise Distributed Object Computing) UML Profile [EDOC] to provide MDA developers with a language for specifying platform-independent models of distributed enterprise applications. In our approach, we use part of this profile, namely, the Component Collaboration Architecture (CCA). The CCA is a component architecture that provides re-use and composability of components, and re-use of designs and patterns, while being independent of choice of technology (e.g. component models), independent of choice of middleware (e.g. message services) and independent of choice of paradigms (e.g. synchronous or asynchronous interactions).

Models in the CCA can be seen as models in the computational and information viewpoints of the Open Distributed Processing (ODP) Reference Model [ITU-X.901]. The computational viewpoint is concerned with the decomposition of the system into objects that interact at interfaces, and on the constraints on the actions of the objects and the interactions. The information viewpoint is concerned with the information that needs to be stored and processed in the system.

This profile introduces CCA modelling concepts and provides a notation in terms of the specialization of UML constructs. As a consequence, UML tools that support UML profiles may be used to draw EDOC UML diagrams. In addition to the UML profile notation, the EDOC specification introduces an alternative notation. For the purpose of this document, we adopt this alternative notation to achieve some economy of expression.

EDOC’s CCA provides concepts for the modelling of structural and behavioural aspects of a distributed application as well as data aspects. In this section, we present the EDOC-CCA metamodels since they are useful for understanding the CCA, and they are a pre-requisite for detailing transformations from CCA models to platform-specific models. We do not present behaviour models, since they are not currently considered in our approach.

4.1 Computational viewpoint (structure)

(20)

Figure 4.1: Structural Specification Metamodel [EDOC]

The following are key model elements of the structural specification:

- ProcessComponent – this corresponds to the logical concept of component. A ProcessComponent can be either abstract, in which case it is only specified from the external perspective, or concrete, in which case it may be defined from the internal perspective or directly implemented using some component technology like EJB or CCM. The external perspective plays the role of a contract to which the component has to comply;

- Port - defines a point through which a component can interact with other components. The port type defines the kind of interactions that a component can support when it is attached to another component through this port;

(21)

- FlowPort, which supports a single message exchange. A FlowPort is either a receiver or sender of information and it is the most elementary port type. All other ports have to be eventually defined in terms of FlowPorts;

- ProtocolPort, which refers to a protocol, meaning that the interactions between components through this part have to comply with the contract imposed by the protocol; A Protocol is a complete conversation between components, in terms of the messages these components exchange and the dependencies between these messages. A protocol may be structured in terms of sub-protocols (protocols contained in this protocol), and have been introduced to allow the structuring of complex interactions patterns and reuse of behaviour parts;

- OperationPort, which supports a request/response pattern of interaction. Although the request/response pattern occurs on this port type, it is actually a special case of a protocol.

The EDOC-CCA metamodel for structural specification of compositions is depicted in Figure 4.2.

(22)

The elements in the composition metamodel are useful for specifying how components are composed internally and to specify how components are used in a larger composition. These concepts allow the designer to consider the system at different levels of composition, recursively until components are fine-grained enough to stop the decomposition. When a ProcessComponent is composed by other

ProcessComponents, a ComponentUsage is used to refer to these components. Their Ports are then represented by PortConnectors, and are connected by Connections.

4.2 Information viewpoint

The EDOC-CCA metamodel for the specification of data elements manipulated by ProcessComponents is called the Document Metamodel. This metamodel is depicted in Figure 4.3.

Figure 4.3: Document Metamodel [EDOC]

An alternative to the CCA Document Metamodel is the MOF-metamodel [MOF1.4] to specify the structure of the information exchanged between ProcessComponents. We adopt this alternative since using MOF for the data aspects will allow us to re-use the MOF XML serialization defined in the XMI standard, and other technology mappings available for MOF. Furthermore, we believe the concepts defined in the MOF metamodel are appropriate for modelling data aspects. In order to integrate the MOF metamodel for data aspects to the CCA structural specification, the structural specification should refer to a Class (as defined in the MOF-metamodel) instead of referring to a DataElement (as defined in the Document Metamodel) to specify data types that flow in a FlowPort.

(23)

4.3 Model management

Model management defines how CCA models are structured and organized. A Package defines a logical hierarchy of model elements. Elements that may be defined in a Package are PackageContent and may be ProcessComponents, Protocols, DataElements, CommunityProcesses and other packages. The model management meta-model is depicted in Figure 4.4.

Figure 4.4: Model Management metamodel [EDOC]

4.4 Example

Figure 4.5 depicts platform independent models defined as structural specifications in the CCA. This example is in line with the architecture proposed in WASP Deliverable D3.3b [WASPD3.3b].

ProcessComponents in this example are the WASP Application, WASP Platform and Context Provider. The WASP Platform is shown in detail, revealing the SubscriptionManager, ContextInterpreter,

(24)

Figure 4.5: Computational Viewpoint – WASP Platform

Figure 4.6 shows the SubscriptionInterface (a ProtocolPort) in detail. The SubscriptionInterface owns addSubscription (a OperationPort) and removesubscription (a FlowPort). The addSubscription

OperationPort owns susbcriptiondescription and subscriptionid (FlowPorts). The FlowPort type associated with subscriptiondescription is shown in detail. The syntax is merely illustrative.

(25)

Subscription SelectExpression Expression Action Term Variable EntityContext * +scoping 0..1 * +occurrence triggering 0..1 * * * +param *

Entity Literal Function

* +param * -declares 1 * +scoping declaration 1 * * * +AND, OR * +NOT * *

(26)

5 Platform-specific

realization

There is on-going standardization activity in mapping platform-independent models specified in EDOC-CCA to Web Services artefacts: an OMG Request For Proposal (RFP) has been issued [WSEC-RFP] to request for a mapping from the EDOC-CCA to XML-Schema, WSDL 1.1 and SOAP. An initial submission [WSEC] is available, and a revised submission is expected in August 2003. The mapping presented here is partially based on this submission. The mapping of data aspects diverges, since we do not reuse EDOC’s Document Metamodel (as discussed in section 4.2).

5.1 Computational viewpoint (structure)

CCA descriptions that are instances of the metamodels presented in the previous sections are the source models for the forward transformation that generates target platform-specific models. The first step in the transformation is the annotation of source models. The annotations are intended to add technology details to platform-independent models prior to transformation. From annotated models, platform-specific models are generated.

The WSEC RFP submission specifies extensions to the CCA metamodel that add to the CCA the ability of producing annotated CCA models. Some of these extensions are presented in the Distributed Component meta-model depicted in Figure 5.1.

(27)

The following are key model elements of the extended structural specification:

- Engine - An Engine extends a Composition, defining the execution context of the components it owns. An Engine has an adapter aspect that defines the Engine’s distribution characteristics. The WSEC submission specifies adapter aspects for WSDL (1.1), SOAP and HTTP. The annotation model can be extended to include parameters necessary for targeting web services hosting platforms. This is done by defining aspects for the target platform. For example, adapter aspects can be defined for Java, .NET and CORBA.

- Endpoint - An Endpoint specifies a set of RoleResources (associated with the ProcessComponent) that may be used by other components (from other Engines).

- Proxy - A Proxy represents a RoleResource that is provided outside the Engine. It is the local representative of an externally implemented Role, and may be used in any place an actual implementation of the Role could be used.

Figure 5.2 presents a simple CCA model with some superimposed annotations. The syntax is merely illustrative. No particular syntax is defined in the current WSEC submission.

Engine (Java) Engine (.NET) Engine (Java) Endpoint (WSDL/SOAP) Proxy Proxy

(28)

5.1.1 CCA – WSDL mapping

Table 1 presents the main mapping rules from CCA model elements to WSDL constructs. The complete mapping rules are presented in [WSEC].

Table 1: Mapping rules from CCA model element to WSDL constructs

CCA ELEMENT WSDL CONSTRUCT MAPPING RULE

Engine <definitions> An Engine corresponds to a WSDL specification.

Role <service> There is a <service> for each ProcessComponent directly contained by the Engine, which implements a Role, and which is not a Proxy.

OutermostPortECA <portType> Either a FlowPort, OperationPort or ProtocolPort.

ProtocolPorts that contain other ProtocolPorts are flattened into one <portType>.

MiddlePortECA <operation> Either a FlowPort or an OperationPort.

FlowPort <input> A FlowPort which is, or is contained by, “MiddlePortECA” and has direction “initiates”. The WSDL message attribute value is based on the FlowPort type, see <message> below.

FlowPort <output> A FlowPort which is, or is contained by, “MiddlePortECA” and has direction = “responds” and postCondition = “success”. FlowPort <fault> A FlowPort which is, or is contained by, “MiddlePortECA” and

has direction = “responds” and postCondition != “success”.

Class <message> and

<type>

For each Class referenced by typed FlowPorts within the Engine, there is a <message> and a <type>. There may be a <message> with no <part> definitions if any of the FlowPorts are untyped. The mapping of the Class definitions to schema is treated in Section 5.2.

<port> There is one <port> per <portType>. No additional constraints related to CCA Elements.

<binding> There is one <binding> per <port>. The type of binding may be defined in an aspect.

(29)

5.1.2 WSDL – CCA mapping

Table 2 presents the main mapping rules from WSDL constructs to CCA model elements. The complete mapping rules are presented in [WSEC].

Table 2: Mapping rules from WSDL constructs to CCA model elements

WSDL CONSTRUCT CCA ELEMENT MAPPING RULE <definitions> Endpoint

<service> Role and RoleResource

The Role is the ProcessComponent, and the RoleResource is the corresponding ComponentUsage. The RoleResource is contained within the Endpoint Composition.

<types> The WSDL <types> element contains a set of <schema> definitions. Mapping of the <schema> definitions is treated in Section 5.2.

ProtocolPort and Protocol

The ProtocolPort contains OperationPorts and FlowPorts derived with the rules below.

<operation> OperationPort or FlowPort

An OperationPort when the <operation> is two-way, or a FlowPort when the <operation> is one-way.

<input> FlowPort A FlowPort with direction “initiates”.

<output> FlowPort A FlowPort with direction “responds” and postCondition “success”.

<fault> FlowPort A FlowPort with direction “responds” and postCondition “anyFailure”.

<message> Class For each WSDL <input>, <output> or <fault> element, there exists a FlowPort. The type of the FlowPort is derived from the type element of the <part> of the <message> associated with the <input>, <output> or <fault>. For the mapping of a <message> with several <part> elements, a Class is created in the data model that contains the Classes for each <part> and corresponding <type>.

(30)

5.2 Information viewpoint

The XML Metadata Interchange (XMI) specification [XMI1.2, XMI2-RevSub] is a standard interchange mechanism that defines how XML tags are used to represent serialized MOF-compliant models in XML. As depicted in Figure 3.1, MOF-based metamodels are translated to XML Document Type Definitions (DTD’s) or XML Schemas and models are translated into XML documents that are consistent with their

corresponding DTD’s or Schemas. Source Meta-Model Source Model XML DTD or Schema XML Document XMI XMI instance of instance of

Figure 5.3: Obtaining XML artefacts from MOF models

Current XMI version 1.2 [XMI1.2] specifies how to produce XML DTD’s from MOF 1.4 metamodels. The revised submission to XMI version 2.0 [XMI2-RevSub] defines how to produce XML Schemas from MOF 2.0 metamodels. The XMI 2.0 submission also defines rules for the generation of MOF 2.0 metamodels from XML Schemas, XML DTD, and XML documents.

We suggest the following approach with respect to the representation of meta-data in an MDA trajectory:

- If an XML format (i.e., an XML DTD or XML Schema) has not been defined yet, it should be preferable to define a MOF metamodel for the data being represented and generate (automatically) an XML Schema from the metamodel using the rules defined in XMI 2.0;

- If an XML format is already defined (legacy), it becomes possible to generate MOF metamodels from this legacy XML format, e.g., with XMI 2.0. In this way, MOF metamodels can be defined for XML formats such as, e.g., WSDL 1.1 and RDF meta-data.

In both cases, the MOF metamodel should be the reference definition. We identify the following benefits of this MOF/XMI-based approach:

(31)

- MOF repositories may be used to manage XML instance data, such as, e.g., WSDL and RDF documents

- MOF-IDL and MOF-Java mappings may be used to generate IDL and Java interfaces to access instance data. This data can be managed in CORBA or Java repositories

- Future mappings from MOF to new meta-data standards or representation formats may be used to generate artefacts compliant with the new standards. A mapping from MOF to WSDL/SOAP will probably be standardized soon, exposing MOF repositories to Web Services clients. In fact, this is already possible given that an IDL to WSDL/SOAP mapping has been standardized [OMG-PTC/03-01-14]

- If changes to the MOF metamodel are necessary, updated artefacts in several different target formats can be generated automatically from the modified metamodel

A drawback of generating XML artefacts automatically from MOF metamodels is that the generated XML artefacts may be larger and more complex than XML formats defined manually by XML developers. However, this drawback applies mostly to XMI 1.1 and 1.2. The mapping defined in the current submission to XMI version 2.0 [XMI2-RevSub] addresses these issues to a large extent.

5.3 Web Services hosting environments

One alternative for the generation of artefacts of web services hosting environments is to derive WSDL descriptions from CCA models and then apply mappings between WSDL descriptions and artefacts supported by different web services hosting platforms. Examples of these mappings are the mappings from and to Java interfaces in the JAX-RPC specification [JAX-RPC], the mappings from and to .NET’s

Common Type System [MS01c] and the mappings from and to CORBA IDL [MARS/02-06-04, OMG-PTC/03-01-14]. This alternative has the benefit that mappings are already defined and are implemented in available tools. However, these mappings can be quite restrictive. For example, <choice> constructs in Schema are not supported in the JAX-RPC mapping. Constructs that are not supported by these mappings (yet) would have to be avoided in the generation of WSDL artefacts. This would require a revision of the mapping from CCA to WSDL presented in Section 5.1.

Ideally, a mapping from CCA models to artefacts of web service hosting platforms should be done directly from CCA models. In this case, the same base CCA model would be used for deriving a WSDL description and artefacts of the web services hosting platform that implement the service described in WSDL. The CCA model could then be used to facilitate the automatic generation of server-side stubs. While the mappings derived with this solution deviate from the “standard” mappings, the constraints of current

(32)

“standard” mappings are avoided. A limitation of this solution is that it depends on how open the hosting platform is with respect to the replacement of standard stubs.

(33)

6 MDA tool requirements

6.1.1 Model transformation

Tool support for generation of Web Services artefacts from UML EDOC models (and vice-versa) as defined in our approach may be provided by using generic model transformation functionality in MDA tools. Currently, tool support for model transformation is proprietary. For example, the MDA tool ArcStyler [ArcStyler] defines transformations on so-called MDA cartridges, which are plug-ins to extend ArcStyler with customized model transformations. For a comprehensive description of ArcStyler’s transformation capabilities please refer to [ArcStyler-Ext-Guide].

Standards for specification of transformations are still on the make. The OMG has issued a Request For Proposal (RFP) entitled “MOF 2.0 Query / View / Transformations”, and several initial proposals with different approaches to model transformation have been submitted [QVT-Submissions]. Agreement on model transformation specification through this standard should guarantee the portability of

transformations across MDA tools from different tool vendors, and define requirements for these tools in terms of compliance points.

6.1.2 MOF and XMI

In order to follow our recommendation for the modelling of data aspects with tool support, the following tool requirements apply:

- support for modelling of MOF metamodels;

- support for MOF model repositories;

- support for generation of XMI from MOF (meta)models;

- support for XMI 2.0’s generation of MOF 2.0 (meta)models from XML Schemas, XML DTD, and XML documents.

Several tools have their own metamodels that differ from the MOF M3 metamodel and do not support (yet) MOF metamodelling. A number of these tools implement XMI with the sole purpose of exchanging

serialized UML models. These tools generate XML documents that are compliant with the UML XMI DTD (or Schema). This level of XMI functionality is not suitable for deriving arbitrary XML artefacts from MOF metamodels and their instances.

(34)

An alternative for MDA tools that are based on UML profiling (instead of MOF metamodelling) is to use profiling capabilities to define a profile for MOF M3, and to specify transformations that conform to the XMI specification. This approach is adequate for tools such as Objecteering [Objecteering].

Tools that do not support MOF repositories (and the associated XMI functionality) or UML profiles may still allow one to define transformations from their proprietary metamodels to XML artefacts in line with XMI specification. These transformations may be provided with the tools or defined by users through extension mechanisms.

(35)

7 Conclusions and outlook

We have presented an approach to web services development based on the separation of platform-specific aspects from platform-independent aspects of designs. Platform-platform-specific aspects include web services-specific aspects and aspects of web services hosting platforms.

The next version of this document (Part 2) will contain an evaluation of this approach based on a case study. This case study will be aligned with the architecture for the WASP platform presented in WASP Deliverable D3.3b [WASPD3.3b]. The final version of the approach (Part 3) will incorporate the improvements and extensions that were inspired by the evaluation. With the case study, we will gain experience with tool support, which will allows to provide guidelines for a specific tool or toolset, possibly refining section 6. Furthermore, we will consider a number of web service hosting platforms deriving mappings for these specific platforms, following one of the alternative approaches presented in section 5.3.

We expect some activity on standardization that may influence our approach in the near future. In particular, there will be new revised submission(s) for the WSEC RFP [WSEC-RFP] in August 2003, as well as new revised submission(s) for the MOF 2.0 Query/View/Transformations RFP [QVT-RFP]. In addition, in September 2003, a report on the Finalization Task Force of the EDOC UML Profile should be available.

The EDOC UML profile has some capabilities for describing the behaviour of components and their interaction. Several languages have been proposed in order to enable the description of the behaviour of web services, e.g., BPEL4WS (Business Process Execution Language for Web Services) [BPEL4WS] and WSCI (Web Service Choreography Interface) [WSCI]. Developers use behavioural descriptions in these languages as a tool for documenting, communicating and understanding the dynamic characteristics of a web service or a set of related web services. This is, however, not the only role these descriptions may play. Behavioural descriptions of web services may be used as input for code generation, execution by engines, or run-time verification of web services’ execution. For example the tool BPWS4J [BPWS4J] includes an engine for executing BPEL4WS definitions in Java. As future work, we should incorporate behavioural descriptions in our approach, and explore the technologies and approaches that can be used to relate specifications in BPEL4WS to actual realizations of these services. This will allow behavioural aspects to be considered at platform-independent level and at both platform-specific levels we address.

(36)

(37)

References

[ArcStyler] Interactive Objects. (iO) ArcStyler Overview. Available at http://www.io-software.com/products/arcstyler_overview.jsp

[ArcStyler-Ext-Guide] Interactive Objects. ArcStyler MDA Extensibility Guide. Available at http://www.io-software.com/as_support/docu/extensibility_guide.pdf

[BPEL4WS] Thatte, S (ed.). Business Process Execution Language for Web Services, Version 1.1, May 2003. Available at http://www.ibm.com/developerworks/library/ws-bpel/

[BPWS4J] IBM. alphaWorks : BPWS4J. Available at http://www.alphaworks.ibm.com/tech/bpws4j

[EDOC] Object Management Group. UML Profile for Enterprise Distributed Object Computing

Specification, OMG document ad/02-02-05, February 2002.

[EJB2.1] Sun Microsystems, Inc., Enterprise JavaBeans Specification 2.1, July 2002. Available at

http://java.sun.com/products/ejb/docs.html

[ITU-X.901] ITU-T Recommendation X.901 | ISO/IEC 10746-1. Open Distributed Processing Reference Model. Part 1 - Overview. International Telecommunications Union (ITU), Geneva, 1997.

[JAX-RPC] Sun Microsystems, Java API for XML-Based RPC (JAX-RPC) Specification 1.0, JSR-101 available at http://java.sun.com/xml/downloads/jaxrpc.html#jaxrpcspec1

[MOF1.4] Object Management Group. Meta Object Facility (MOF) Specification 1.4, OMG document ad/02-04-03, April 2002.

[MS01a] Microsoft Corporation. Microsoft .NET Remoting: A Technical Overview, July 2001. Available at

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/hawkremoting.asp

[MS01b] Microsoft Corporation. Inside the .NET Framework, 2001. Available at

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconinsidenetframework.asp

[MS01c] Microsoft Corporation. Data Types Supported by XML Web Services Created Using ASP.NET. Available at

(38)

[Objecteering] SOFTEAM. Welcome to Objecteering Software. Available at http://www.objecteering.com/

[OGSI] Global Grid Forum. Open Grid Services Infrastructure (OGSI) Version 1.0 (draft), April 2003. Available at http://www.gridforum.org/ogsi-wg/drafts/draft-ggf-ogsi-gridservice-29_2003-04-05.pdf

[OMG-IDL-Mappings] Object Management Group. Catalog of OMG IDL / Language Mappings Specifications. Available at http://www.omg.org/technology/documents/idl2x_spec_catalog.htm

[OMG-MARS/02-06-04] Object Management Group. Joint Initial WSDL-SOAP to CORBA Interworking RFP

submission, mars/02-06-04. Available at http://cgi.omg.org/cgi-bin/doc?mars/02-06-04

[OMG-ORMSC/010701] Object Management Group, Model Driven Architecture (MDA), ormsc/01-07-01, July 2001.

[OMG-PTC/03-01-14] Object Management Group. CORBA-WSDL/SOAP final adopted specification, January 2003, available at http://cgi.omg.org/docs/ptc/03-01-14.pdf

[QVT-RFP] Object Management Group. MOF 2.0 Query / Views / Transformations RFP. ad/02-04-10, April 2002.

[QVT-Submissions] Object Management Group. OMG TC Work in Progress, MOF 2.0 Query / Views /

Transformations RFP, available at

http://www.omg.org/techprocess/meetings/schedule/MOF_2.0_Query_View_Transf._RFP.html

[RFP-Template] Object Management Group. Generic RFP template. ab/02-04-06, April 2002.

[SchmidtVinoski] Schmidt, D. and Vinoski, S. “Object Interconnections: CORBA and XML – Part 3: SOAP and Web Services”, C/C++ Users Journal C++ Experts Forum, Sept 2001. Available at

http://www.cuj.com/experts/1910/vinoski.htm

[Servlet2.4] Sun Microsystems, Inc., The Java Servlet Specification 2.4, April 2003. Available at

http://java.sun.com/products/servlet/download.html#specs

[UML1.5] Object Management Group. Unified Modelling Language (UML), version 1.5, OMG document formal/2003-03-01, March 2003. Available at http://www.omg.org/cgi-bin/doc?formal/03-03-01

[WASP-D3.2] L. Ferreira Pires et al. Modelling of Services and Component Interaction. WASP Project Deliverable D3.2, July 2003.

(39)

[WASPD3.3b] P. Dockhorn Costa. Towards a Services Platform for Context-Aware Applications, Master of Science Thesis, University of Twente, The Netherlands, August 2003. Also available as WASP Project Deliverable D3.3b.

[WSCI] World Wide Web Consortium. Web Service Choreography Interface 1.0, August 2002. Available at

http://www.w3.org/TR/wsci/

[WSEC] Object Management Group. Web Services for Enterprise Collaboration (WSEC), October 2003, available at http://www.omg.org/cgi-bin/doc?mars/02-10-11

[WSEC-RFP] Object Management Group. Web Services for Enterprise Collaboration (WSEC) RFP, mars/2002-06-06, June 2002, available at http://www.omg.org/cgi-bin/doc?mars/02-06-06

[XMI1.2] Object Management Group. OMG XML Metadata Interchange (XMI) Specification, Version 1.2, January 2002, available at http://www.omg.org/cgi-bin/doc?formal/02-01-01

[XMI2-RevSub] Object Management Group. Meta Object Facility (MOF) 2.0 XMI Mapping, Revised

Submission to ADTF RFP ad/01-11-13, January 2003, available at http://www.omg.org/cgi-bin/doc?ad/02-12-07

Methods for web services based application development. Part 1