Impacts of changes in enterprise software construction for telecommunications

Transcription

1 Project Report Impacts of changes in enterprise software construction for telecommunications Model Driven Architecture Assessments of relevant technologies Editor: Olaf Kath, IKV++ Technologies AG DRAFT Awaiting approval by the EURESCOM Board of Governors Abstract The object technology programming paradigm has replaced the more than twenty years old procedural refinement paradigm by the philosophy of object composition. Recently, this evolution itself is triggering today another even more drastic change in system construction, towards model transformation. As a concrete sketch of this, the Object Management Group (OMG) is hurriedly moving from its Object Management Architecture vision (OMA) to the Model-Driven Architecture (MDA). The main characteristics of this movement are outlined in this document. This deliverable introduces the MDA as such, its driving technologies and application scenarios of such technologies. EDIN 0001-xxxx Project P1149 For full Publication January 2002

2 EURESCOM PARTICIPANTS in Project P1149 are: Deutsche Telekom AG France Télécom R&D Telenor AS IKV++ Technologies AG [Project title] Impacts of changes in enterprise software construction for telecommunications [Document title] Model Driven Architecture Assessments of relevant technologies Editor: Olaf Kath, IKV++ Technologies AG Project leader: Sune Jakobsson, Telenor AS Project supervisor: Anastasius Gavras, EURESCOM EURESCOM published project result; EDIN 0001-xxxx 2002 EURESCOM Participants in Project P1149 Disclaimer This document contains material which is the copyright of certain EURESCOM PARTICIPANTS, and may not be reproduced or copied without permission. All PARTICIPANTS have agreed to full publication of this document. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the report is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using this information. This document has been approved by EURESCOM Board of Governors for distribution to all EURESCOM Shareholders.

3 DRAFT EURESCOM Project Report page 3 (34) Preface The EURESCOM study on Impacts of changes in enterprise software construction for telecommunications P1149, undertook investigations to identify the impact of the Model Driven Architecture (MDA) for telecommunications operators with respect to the specifics of telecommunication systems. Techniques were studied, that can be used to utilize the MDA in the telecommunication arena. Moreover, the study proposes an evolution path for how the MDA needs to be adapted or specialised in order to enable its efficient utilization in the telecommunication domain. The main objectives of the project were to: Analyse the foundation of the Model Driven Architecture and identify its constituting parts Identify fields in the telecom domain where MDA or parts of it are applicable, focusing on the key elements of MDA and their telecom specific capabilities. Investigate necessary adaptations to or specialisations of the Model Driven Architecture to reflect telecommunications needs Explore the market for available products that support identified key technologies relevant to MDA, with a focus on telecom specific capabilities The study started in November 2001 and concluded in February 2002 with an overall budget of 12 person months. Participants in the study were Deutsche Telekom AG, France Télécom R&D and Telenor AS. The study participants were supported by experts of IKV++ Technologies AG. Project leader is Sune Jakobsson, from Telenor AS. This is the first of two deliverables of this study and is titled: Model Driven Architecture Assessments of relevant Technologies. The other deliverable is titled: Model Driven Architecture Adaptations and impacts for the telecom domain. This deliverable introduces the Model Driven Architecture as such, its driving technologies and describes application scenarios for these technologies EURESCOM Participants in Project P1149 EDIN 0001-xxxx

4 page 4 (34) DRAFT EURESCOM Project Report Executive Summary Computing infrastructures are expanding their reach in every dimension. New platforms and applications must interoperate with legacy systems. New implementation platforms are continually coming down the road, each claiming to be "the next big thing". To protect investments and maximize flexibility, telecom operators buy hardware that implements open interconnection standards, and software that uses open interface standards like CORBA and EJB. But, those interconnection standards evolve rapidly. How can telecom operators ensure that their mission-critical information systems are rooted in standards that will adapt to new hardware capabilities and software platforms? The Object Management Group addresses this reality with the Model Driven Architecture (MDA). With MDA, systems are constructed by modelling system aspects using formal and semi formal modelling techniques and by transformations between the resulting models. The core of the MDA is made up by a number of important, already available and industry wide supported OMG standards: The Unified Modeling Language (UML), the Meta Object Facility (MOF), the XML Metadata Interchange (XMI), and the Common Warehouse Metamodel (CWM). These standards define the core infrastructure of the MDA, and have greatly contributed to the current state-of-theart of systems modelling. The discussion in this deliverable shows, that core technologies which are necessary to apply model driven architectures in the telecom industries are already available. Some of them (UML, MOF, CWM) are well established and mature, a variety of products are available on the market. Others, especially those that are required for model transformation (EDOC) will soon be realized. Based on these core technologies scenarios will be identified, demonstrating how the model driven architectures can be applied in the business domain of telecom operators. These scenarios are not restricted to telecom system development but include also data warehousing and information management. Besides the scenarios identified in this deliverable, the great potential and impact of model driven architectures for the telecom industries was shown. Almost every new technology or paradigm which is recently appeared has drawbacks or open problems. The risks identified by this deliverable include the unpredictable acceptance of modelling by system designers and developers, the lack of tools which enable the model transformation and the re-engineering of existing models and code and the large amount of nonstandardized and incompatible modelling profiles. However, none of these risks is a killing factor for model driven approaches. EDIN 0001-xxxx 2002 EURESCOM Participants in Project P1149

5 DRAFT EURESCOM Project Report page 5 (34) List of Authors Mariano Belaunde (France Télécom R&D) Marc Born (IKV++ Technologies AG) Michael Herzog (Deutsche Telekom AG) Sune Jakobsson (Telenor AS) Olaf Kath (IKV++ Technologies AG) Thomas Unterschütz (Deutsche Telekom AG) 2002 EURESCOM Participants in Project P1149 EDIN 0001-xxxx

6 page 6 (34) DRAFT EURESCOM Project Report Table of Contents Preface...3 Executive Summary...4 List of Authors...5 Table of Contents...6 List of Figures...7 Abbreviations Introduction The Model Driven Architecture The Importance of Shared Metadata The Importance of Common Services and Programming Models The Importance of Platform Specifications Model Driven Architecture Core Technologies The Unified Modelling Language The Meta Object Facility CORBA Technology Mapping for MOF Java Technology Mapping for MOF Enterprise Distributed Object Computing Model Driven Aspects in Middleware Technologies The Construction Paradigm Model Transformation Model Transformation in EDOC Model Transformation in CWM Precise Modelling a Precondition for Model Transformation Putting the Pieces together An Example Application Scenario Platform Independent Model with the EDOC Profile Platform Specific Models PSM based on the EJB Profile, EJB and JMI PSM based on the CCM Metamodel, CORBA and MOF MDA in Practice Known Application Scenarios for MDA Type Management in Middleware Infrastructures Information Management Scenarios Data Warehouse Management Scenarios Software Development Scenarios Risk and Opportunities of MDA Conclusion...33 References...34 EDIN 0001-xxxx 2002 EURESCOM Participants in Project P1149

7 DRAFT EURESCOM Project Report page 7 (34) List of Figures Figure 1 System Construction Paradigms...10 Figure 2 Shared Metadata Infrastructure...12 Figure 3 The MOF Layers...15 Figure 4 Practical Relations between XMI and MOF...16 Figure 5 The Metadata Hierarchy for Assemblies...18 Figure 6 Model Transformation Foundation...20 Figure 7 The Common Warehouse Metamodel...21 Figure 8 Community Specification...24 Figure 9 Seller Port Structure and Choreography...24 Figure 10 Internal view onto the Seller...25 Figure 11 J2EE Platform Specific Model...26 Figure 12: An Implementation of the procurement system based on CCM...26 Figure 13 Re-Engineering of existing (meta)models...31 Figure 14 Business Impacts of MDA EURESCOM Participants in Project P1149 EDIN 0001-xxxx

8 page 8 (34) DRAFT EURESCOM Project Report Abbreviations CORBA CWM EDOC J2EE JMI MDA MOF OLAP OMA UML XMI Common Object Request Broker Architecture Common Warehouse Metamodel Enterprise Distributed Objects Computing Java 2 Enterprise Edition Java Metadata Interface Model Driven Architecture Meta Object Facility On-Line Analytical processing Object Management Architecture Unified Modelling Language XML Metadata Interchange EDIN 0001-xxxx 2002 EURESCOM Participants in Project P1149

9 DRAFT EURESCOM Project Report page 9 (34) 1 Introduction MDA addresses the challenges of today's highly networked, constantly changing systems environment, providing an architecture that assures: Portability, increasing application re-use and reducing the cost and complexity of application development and management, now and into the future. When moving from a vertical business model to a horizontal model business model, something the telecom operators currently to a large extent are doing, MDA provides the means to reengineer old and legacy applications and deploy these on new types of networks. The deliverable D2 document "Model Driven Architecture Adaptations and impacts for the telecom domain", available end of 1Q2002 should also stimulate a discussion at an appropriate standardization body (OMG, ITU-T) to use MDA in the telecommunication domain. Some benefits for potential MDA users: Reduced cost throughout the application life-cycle Reduced development time for new applications Improved application quality Increased return on technology investments Rapid inclusion of emerging technology benefits into their existing systems MDA provides a solid framework that frees system infrastructures to evolve in response to a neverending parade of platforms, while preserving and leveraging existing technology investments. It enables system integration strategies that are better, faster and cheaper. This document provides general descriptions on the key elements in the MDA, with some known or proposed practical examples. The discussion in this deliverable shows, that core technologies which are necessary to apply model driven architectures in the telecom industries are already available. Some of them (UML, MOF, CWM) are well established and mature, a variety of products are available on the market. Others, especially those that are required for model transformation (EDOC) will soon be realized. Based on these core technologies scenarios will be identified, demonstrating how the model driven architectures can be applied in the business domain of telecom operators. These scenarios are not restricted to telecom system development but include also data warehousing and information management. Besides the scenarios identified in this deliverable, the great potential and impact of model driven architectures for the telecom industries was shown. In subsequent deliverables of this study, it will be detailed, how the telecom operators can follow the model driven approach. Almost every new technology or paradigm which is recently appeared has drawbacks or open problems. The risks identified by this deliverable include the unpredictable acceptance of modelling by system designers and developers, the lack of tools which enable the model transformation and the re-engineering of existing models and code and the large amount of nonstandardized and incompatible modelling profiles. However, none of these risks is a killing factor for model driven approaches. In the ongoing work of the study it will be determined how the risks can be reduced as much as possible so that telecom operators which apply model driven architectures for their businesses can gain optimal results EURESCOM Participants in Project P1149 EDIN 0001-xxxx

10 page 10 (34) DRAFT EURESCOM Project Report 2 The Model Driven Architecture The object technology programming paradigm has replaced the more than twenty years old procedural refinement paradigm by the philosophy of object composition. Recently, this evolution itself is triggering today another even more drastic change in system construction, towards model transformation. As a concrete sketch of this, the Object Management Group (OMG) is hurriedly moving from its Object Management Architecture vision (OMA) to the Model-Driven Architecture (MDA). The main characteristics of this movement are outlined in this document. Based on this document, the project will further focus on the main ingredients of the architecture, the model driven technologies available today and the impact of the movement towards model transformation system construction for the Telecom industry. C O M P L E X I T Y C Pascal M odula Model Driven Architectures M eta Object Facilit y and UM L Shared M etadata Environment s (.NET, CWM, JM I) C++ Java Smalltalk step-wise procedural refinement CORBA Java RM I EJB object composit ion paradigm. distribut ed object s t echnology model transformation paradigm FLEXIBILITY Figure 1 System Construction Paradigms Since November 2000, the Object Management Group introduces the Model-Driven Architecture (MDA) as the successor of its Object Management Architecture (OMA). The OMA provided the roadmap for the problem that the OMG was always approaching, the problem of system integration. The MDA initiative is an approach to system specification, system portability and interoperability based on the use of formal and semi formal models. Systems are constructed by modelling system aspects using formal and semi formal modelling techniques and by transformations between the resulting models. The yet identified main categories of models are platform independent and platform specific models: As defined by MDA, platform-independent models (PIMs) are expressed in a platformindependent modelling language, such as UML. The platform-independent model is subsequently translated to a platform-specific model (PSM), mapping the PIM to some implementation language or platform (e.g., J2EE, CORBA or.net) using formal or semi-formal transformation rules 1. The core of the MDA is made up by a number of important, already available and industry wide supported OMG standards: The Unified Modeling Language (UML), the Meta Object Facility (MOF), the XML Metadata Interchange (XMI), and the Common Warehouse Metamodel (CWM). These standards define the core infrastructure of the MDA, and have greatly contributed to the current state-of-the-art of systems modelling. 1 Note that UML can also be used for PSM models, using specific UML profiles, such as the UML profile for EJB. EDIN 0001-xxxx 2002 EURESCOM Participants in Project P1149

11 DRAFT EURESCOM Project Report page 11 (34) The MDA represents a major evolutionary step concerning the process the OMG defines interoperability standards. For a very long time, interoperability was based mainly on CORBA standards and services. Heterogeneous software systems interoperate at the level of standardized interfaces. However, the MDA process places system models and not just interfaces - at the core of the interoperability problem. The most significant quality of this approach is the independence of the system specification (i.e. a set of models) from the implementation technology or platform. The system definition exists independently of any implementation model and has formal mappings to many possible system infrastructures. The MDA has significant implications for the specification of metadata, also known as metamodelling. Interoperability in heterogeneous environments is ultimately achieved via shared metadata. E.g. only a metadata architecture allows the.net platform to function properly. Sharing and understanding metadata consists of the automated development, publishing, management, and interpretation of models. Sharing of metadata is well adopted to build systems that are loosely coupled (in contrast to tight coupling, based on sharing interfaces that depend on the middleware). XML is the de facto format used for this purpose, when exporting and importing data On the other hand, the MDA will be an important driver for the Adaptive Object Models (AOM) technology. A system with an Adaptive Object Model defines an explicit object model that it interprets at execution time. If the object model is changed, the system behaviour will be changed. For example, a lot of workflow systems have an Adaptive Object-Model. Objects have states and respond to events by changing state. The Adaptive Object Model defines the objects, their states, the events, and the conditions under which an object changes state. With the AOM technology, business rules can be stored in an Adaptive Object Model that makes it easy to evolve the way a company does their business. The AOM technology provides dynamic system behaviour based on run-time interpretation of models. Architectures based on AOM are highly interoperable and portable, easily extendable at run-time, and entirely dynamic in terms of their overall behavioural specifications (i.e., their range of behaviour is not bound by hard-coded logic). The core standards of the MDA (UML, MOF, XMI, CWM) form the basis for building consistent schemes for composing, publishing, and managing models within a model-driven architecture. As one example for the applicability of the MDA, there is a corresponding trend currently introduced in the software industry towards the realization of the MDA in the J2EE platform (i.e., standardized mappings of platform independent models onto platform dependent models of the Java platform). This is a sensible implementation strategy, since development and integration is greatly facilitated through common platform services and programming. Java 2 Platform, Enterprise Edition (J2EE), has become a leading industry standard for implementing and deploying component-based, distributed applications in multi tier, web centric environments. Current efforts within the Java Community Process aim at the development of pure Java programming models realizing OMG standards in the form of J2EE standard APIs (i.e., the Java Metadata Interface JMI is based on OMG s MOF and CWM specifications) further enhance the metadata-based interoperability of distributed applications. 2.1 The Importance of Shared Metadata The sharing of metadata is crucial to all aspects of interoperability within any heterogeneous environment. More precisely, metadata is the primary means by which interoperability is achieved (interoperability can be facilitated by standardized APIs, but ultimately requires shared metadata as the definitions of system semantics and capabilities). Any MDA based system must have the ability to store, manage and publish both application and system metadata (including descriptions of the infrastructure itself). Applications, tools, data storages, and other components hook into the infrastructure and discover metadata descriptions pertaining to the infrastructure. A component introduced into the infrastructure can also publish its own metadata to the rest of the infrastructure EURESCOM Participants in Project P1149 EDIN 0001-xxxx

12 page 12 (34) DRAFT EURESCOM Project Report Business Model Usage Model Test Model Resource Model Design Model Shared Metadata Infrastructure Deployment Model Architecture Model Exception Model Execution Model Figure 2 Shared Metadata Infrastructure Having masses of shared, descriptive metadata (omnipresent metadata) facilitates software interoperability between platform components in very specific ways, such as: Meta data and data interchange, transformation, and mappings between data resources can be driven by formal metadata descriptions of the transformations, data types, and type-system mappings. This approach is fundamental to scenarios of services marketplace and data warehousing. After exchanging metadata information, software components with no prior knowledge of the capabilities, interfaces, and data representations of each other can interoperate, if in the metadata exchange phase each exposes its features and assesses those of the other. Note that this exchange of knowledge does not always need to be complete, but to the extent that components can make sense of each other's capabilities, they can interact with one another. Intelligence and visualization functions in business processes utilize metadata in the processing and formatting of data for analysis and display. The metadata descriptions for such processes define the semantics of data that analysts may need in order to make sense of data (e.g., definitions of business terms, glossaries, taxonomies, nomenclatures are part of the shared metadata). An MDA system does not necessarily require that internal representations of metadata already present within applications, tools, and databases have to be modified to match the shared metadata definitions. Product specific internals and programming models remain as they are. Shared metadata consists of externalised definitions that are interchanged between participating components. These external definitions are readily understood by components that agree on the metamodel describing the metadata (e.g., CWM). External definitions are highly generic, but also possess sufficient semantic completeness, and are, therefore, understood by a wide range of participants. Highly product specific metadata that does not fit the generic model is handled through the use of extension mechanisms that are pre defined as part of the generic models (e.g., the use of UML extension mechanisms, such as tagged values, stereotypes, and constraints 2 ). 2 One motivation to use UML extensions packaged in UML profiles is that people want to use a concrete graphical notation implemented in an existing CASE tool. A UML profile is often defined in conjunction with a specific metamodel capturing the domain specific concepts independently of how they can be expressed in UML. EDIN 0001-xxxx 2002 EURESCOM Participants in Project P1149

13 DRAFT EURESCOM Project Report page 13 (34) 2.2 The Importance of Common Services and Programming Models Another key aspect with respect to interoperable systems is the standardization of common systemand application-level services, along with the application programming interfaces (APIs) used to access these services. This leads to the definition of platform specific models for common infrastructures. This form of standardization simplifies clients and facilitates the integration of new components into the MDA based infrastructure. Clients using common services have a smaller footprint and are less complex, because they only need to be coded to one interface, regardless of how services are actually implemented in a particular deployment. Conversely, service providers implementing standard APIs are readily available for use by a large number of clients. 2.3 The Importance of Platform Specifications A Platform Specification is basically the complete definition of the metadata interoperability and interchange strategies, common services, and standard APIs that any instance of an MDA based system is capable of supporting. Each MDA-based system instance includes a descriptor that specifies those features actually supported by that particular deployment. Software tools for specifying and integrating system components generate the descriptor, and tools for configuring, installing, and bootstrapping an instance of the system are driven by the descriptor EURESCOM Participants in Project P1149 EDIN 0001-xxxx

14 page 14 (34) DRAFT EURESCOM Project Report 3 Model Driven Architecture Core Technologies 3.1 The Unified Modelling Language UML is standardized by the Object Management Group (OMG). UML is used in the development process of many object-oriented and especially component-based systems. Integrating a number of known object-oriented methods, such as Objectory, OMT, Booch, UML facilitates the description of object-oriented systems from different perspectives. It is possible to describe the static structure of a system as well as the dynamic behaviour, the instances of objects and their distribution. Forward and reverse engineering in terms of generation of code in programming language or other description language, and vice versa, are (partially) supported by UML tools. One of the main advantages of the UML is its flexibility. The UML notations can be customized for a special purpose or application in a specific domain. Three mechanisms of extending the UML exist: Stereotypes represent new modelling elements for the UML, which have a special semantic. Stereotypes are normally based on standard UML elements like Class. An example is the stereotype Use Case. Tagged Values represent new modelling attributes for modelling elements. An example for a tagged value is the location attribute whose value determines on what node the instance of a class resists. Constraints may be used to define new semantics for modelling elements. This is especially necessary when new modelling elements are introduced via stereotypes and their usage has to be defined. UML 2.0 is the next major evolution of the UML (Unified Modeling Language) notation. Since the UML 1.1 adopted specification in September 1997, several revisions were made to address the issues that users and tool vendors raised when using or implementing UML. The UML 1.3 version was adopted in 1999 and, more recently, UML 1.4 in However, in the meantime, UML has become very popular. Users tend to use it as a general-purpose language even if it was not designed and built to cope with this. In 2001, the OMG issue several RFPs to enable a major evolution to UML that will we able to address in a consistent way the unexpected new requirements on UML. The UML 2.0 Infrastructure RFP deals with the core constructs of UML, on top of which all of the UML capabilities will be defined (e.g. what is containment, generalization, packaging and so on); The UML 2.0 Superstructure RFP deals with all the standard capabilities of UML. A large set of modelling paradigms need to be covered and connected in a properly way (use cases, statetransition diagrams, activity diagrams, collaborations, sequence diagrams, and so on). Other RFPs deals with the upgrade of the OCL constraint language (used in UML to enhance the precision of the diagrams), and also an RFP to address the problem of interchanging the graphical information in UML diagrams (no standard way to achieve this is currently available using XMI). The initial submissions for these RFP were published in 2001, in August for the infrastructure and in October for the superstructure. The revised and joint submissions are expected to be available in August In this section we will point out what are the relevant changes that are in the progress to be made, specifically those that concern the telecom domain and those that may impact the application of the MDA. We will point out the new features in UML 2.0 based on the initial U2 partners submission [ad/2001-xx-xx] which groups the most influent partners in the Analysis and Designs task force in the OMG (IBM, Rational, Unisys, Telelogic, Softeam, etc.). 3.2 The Meta Object Facility The extensive application of models and modelling techniques within the scope of the development and use of CORBA-system lead to the requirement of a unique and standardized framework for the EDIN 0001-xxxx 2002 EURESCOM Participants in Project P1149

15 DRAFT EURESCOM Project Report page 15 (34) management, manipulation and exchange of models and meta-models. This need has been addressed by the OMG with the Meta-Object-Facility (MOF, [4]). The architecture of MOF is based on the traditional four-layer approach to meta-modelling: Layer M0 the instances: The information (data) that describes a concrete system at a fixed point in time. The M0-layer consists of instances of elements of the M1-layer. Layer M1 the model: The definition of the structure and behaviour of a system using a well defined set of general concepts. The M1-layer forms a blueprint for a system. Layer M2 the meta-model: The definition of the elements and the structure of a concept space (i.e. of the modelling language). An M1-layer model consists of instances of the M2- layer. Layer M3 the meta-meta-model: The definition of the elements and the structure for the description of a meta-model. An M2-layer model consists of instances of the M3-layer. <<metamodel>> MOF Metametamodel M3 Layer: Specifies meta-metaclasses for the UML metamodel <<instanceof>> <<metamodel>> UML Metamodel M2 Layer: Specifies metaclasses for the UML metamodel, such as Class <<instanceof>> User Model M1 Layer: Specifies classes for the UML user models, such as Passenger, Ticket, TravelAgency <<instanceof>> :Foo <<instanceof>> :Bar <<instanceof>> :Baz M0 Layer: User objects that are instances of UML user model classes, such as instances of Passenger, Ticket, TravelAgency Figure 3 The MOF Layers Although further levels (i.e. for the definition of the elements to specify the M3-layer) seem to be necessary, MOF as well as other meta-modelling frameworks stop at M3. This is due to the application of a so-called hard-wired meta-meta-model: Elements and structure of the M3-layer are directly derived from a well-known formalism, in case of MOF this formalism is object-orientation. In fact the MOF concepts are defined using MOF itself. Consequently the MOF-model as M3-layer consist of the following major concepts for the definition of meta-models: Classes: Classes are first-class modelling constructs. Instances of classes (on M1-layer) have identity, state and behaviour. The structural features of classes are attributes, operations and references. Classes can be organized in a specialization/generalization hierarchy. Associations: Associations reflect binary relationships between classes. Instances of associations at the M1-layer are links between class instances and do not have state nor identity. Special properties of association ends may be used to specify the name, the multiplicity or the type of the association end. MOF distinguishes between aggregate (composite) and non-aggregate associations. Data types: Data types are used to specify types whose values have no identity. Currently MOF comprises the CORBA data types and IDL interface types EURESCOM Participants in Project P1149 EDIN 0001-xxxx

16 page 16 (34) DRAFT EURESCOM Project Report Packages: The purpose of packages is to organize (modularise, partition and package) metamodels. Applicable mechanisms here are generalization, nesting, import and clustering. The MOF specification defines these concepts as well as supporting concepts in detail. Because there is no explicit notation for MOF, the UML notation has been deliberately used to visualize selected concepts. The interface to the conceptual framework of MOF is formally defined in the CORBA-IDL modules Model (meta-model specific interfaces) and Reflective (generic interfaces), where all interfaces in Model directly or indirectly inherit from Reflective-interfaces CORBA Technology Mapping for MOF 1.4 The MOF-interfaces allow to stepwise create a new meta-model in the MOF by creating new objects, change an existing meta-model in the MOF, extract information from a meta-model using query and traversal functions, and request a validation of the meta-model. In addition to that functions are defined to produce an external representation of a meta-model (externalise) or to create a meta-model in MOF from such an external representation (internalise). Currently two specific mappings from MOF to external formats are defined: MOF-IDL-mapping: This mapping generates the IDL-specification of a meta-data service from a MOF-meta-model specification. This service (e.g. repository) can be used to store or manipulate models (M1-layer) that conform to the meta-model. An example for such a service is the UML CORBA facility generated from the UML-meta-model but also the MOF itself (generated from the MOF-meta-model). XMI (XML based model interchange): This mapping defines rules to derive an XML Document Type Definition (DTD) from a meta-model in MOF and to externalise meta-model data (i.e. a model) from MOF into an XML document structured according to the before mentioned DTD and vice versa. The UML DTD and the MOF DTD are examples for such Document type descriptions. Tool/Ap Tool/Ap write MOF::Reflective Reflective read XML Intermediate Stream/File (XML) Generated Interfaces for metamodel EAI EC CW UML Figure 4 Practical Relations between XMI and MOF The advantage of the MOF-approach is that it makes the definition of (meta)-models independent of the concrete application domain of the models themselves and that it provides a concise and unique set of concepts for the definition of meta-models. Moreover, multiple meta-models can be managed by the MOF. Further investigations have to show, how relations between meta-models can be utilized as a basis for a transformation of models based on these meta-models. The integration of MOF into CORBA enables applications to access meta-information about application objects during runtime (using the repository interface). The XMI as well as the proprietary externalise/internalise functions enable an application of MOF and MOF-based repositories in a scope wider than CORBA. EDIN 0001-xxxx 2002 EURESCOM Participants in Project P1149

17 DRAFT EURESCOM Project Report page 17 (34) Java Technology Mapping for MOF 1.4 The Java TM Metadata Interface (JMI) Specification implements a dynamic, platform-neutral infrastructure that enables the creation, storage, access, discovery, and exchange of metadata. JMI is based on the MOF specification from OMG. The MOF standard consists of a base UML model and a set of IDL interfaces. The MOF specification provides a programming mechanism that allows applications to query a meta-model at run time to determine the structure and semantics of the modelled system. JMI is a Java technology mapping of the MOF IDL interfaces that will allow Java components and applications to access and manipulate metadata. Using JMI, applications and tools that specify their meta-models using MOF-compliant UML can have the Java interfaces to the models automatically generated. Further, meta-model and metadata interchange via XML is also automatically enabled by JMI's use of the XML Metadata Interchange (XMI) specification. 3.3 Enterprise Distributed Object Computing The RFP "UML Profile for EDOC [12] called for a standard way to use UML for designing distributed enterprise systems, with the assumption that the design will adopt a component-oriented approach and that it will be "mapable" to the existing software component frameworks (i.e. the CCM, the EJB, etc.). The final submission, recommended to adoption in September 2001 is a "melting-pot" of distinct interesting works, but containing also a lot of inconsistencies. There are specific UML profiles for modelling event-driven systems, as well as for business process. Anyway, the Enterprise Collaborative Architecture (ECA) which is part of the EDOC submission, has proposed a general composition model, that summarizes well the state of the art on components: Recursion in composition, port specification using protocols, configuration properties, etc. In addition, a graphical notation has been proposed to be used as an alternative to the standard UML icons. An ECA component has an external view that includes the declaration of ports. A port is simple or composite (containing sub-ports). It plays either the role of an "initiator" or the role of a "responder". The interaction through the ports needs to conform to a protocol specification. A protocol may imply complex interactions between the two parties. A protocol choreography, which is represented by an activity diagram in UML, is used to describe the ordering of the messages. Note that an interface (a collection of synchronous operations) is treated as a particular case of a protocol). A community is a special kind of composite that reflects a collaboration of top-level component instances. An ECA component may expose its internal structure (its inside) or it may declare a "performer" role that implements it. In the former case, the internal view of the component is described as a collaboration of other component instances (usages of other components). The connections between the ports of the component instances are explicitly described. A choreography may be used to describe in detail the behaviour of this collaboration. 3.4 Model Driven Aspects in Middleware Technologies The UML is widely used to specify, visualize, construct, and document the types of enterprise applications for which the EJB architecture was designed. Conversely, the EJB architecture is widely used to implement the types of enterprise applications most frequently described by UML models. There is therefore significant motivation for ensuring that the UML can be used to describe EJB-based software systems. While the UML already provides standards for the design of object-oriented systems in general, including enterprise-computing systems, it does not provide everything necessary for the design of systems based on specific implementation architectures. In particular, it does not explicitly capture the semantics expressible in the EJB architecture. The UML was designed to be extensible, however, and provides standard extension mechanisms for defining new semantic constructs. These mechanisms can be used to define constructs describing EJB-based software artefacts. Ad hoc attempts to do this have been made by the 2002 EURESCOM Participants in Project P1149 EDIN 0001-xxxx

18 page 18 (34) DRAFT EURESCOM Project Report industry over the past several years. To ensure the interoperability of tools and frameworks from different vendors, and the portability of the applications they support, this specification defines a standard set of UML extensions for modelling EJB-based software systems. In addition, since tool and framework vendors often place UML models describing EJB-based artefacts in the EJB-JARs that contain those artefacts to support display, automation and reflection, this specification defines a standard format for storing a UML model that describes the contents of an EJB-JAR within the EJB-JAR. Collectively, these definitions comprise the UML Profile for EJB. The UML Profile for EJB can be used to develop models describing EJB-based implementation artefacts, and to round trip engineer between the models and the artefacts. The Microsoft.NET Framework introduces the notion of an assembly. An assembly is a group of resources and types, along with metadata about those resources and types, which is deployed as a unit. The metadata is called an assembly manifest and includes information such as a list of types and resources visible outside the assembly and type descriptions and information about any external assemblies that the current assembly refers to. This includes dependencies, such as the version of the assemblies used when the assembly was built. These metadata make some things a lot easier: One of the biggest wins of the metadata in.net is the greatly improved ability to easily use code written in different languages. Because every module has metadata that describes all of its methods and their parameter, their calling conventions, the class members, and their visibilities it is possible to inherit classes over language borders. Any.NET compiler or scripting language can read in the metadata and gain access to the same level of information. Different languages will use different syntaxes to import metadata, but they'll all end up with the same information. Developers or administrators can specify versioning policies to indicate whether the runtime should load the latest version of a referred assembly installed on the system, a specific version, or the version used at build time. Although it has always been possible for multiple copies of a software component to reside on the same system, only one of these copies could have been registered with the operating system or loaded for execution. This is different in.net. Because assemblies are self-describing, no explicit registration with the operating system is required. Application deployment can be as simple as copying files to a directory tree. It is even possible to produce metadata for legacy applications. These metadata comprise among other things their interfaces and used data types, which enables.net programs to access the non-.net modules properly. Assembly Modules Module Types Type Foo Global Method Type Foo Methods Fields Method MyFoo Parameters Parameter int mda2001 Properties Events Collections Single Instances Figure 5 The Metadata Hierarchy for Assemblies The metadata facility in.net supports many of the interoperability features a MDA system has to have. This includes EDIN 0001-xxxx 2002 EURESCOM Participants in Project P1149

19 DRAFT EURESCOM Project Report page 19 (34) A formal language (syntax and semantics) for representing metadata. Although the metadata language of.net is not possible to express business or the like models, it is rich enough to describe components exact. An interchange format for exchanging and publishing metadata. As mentioned above this is only true for component not for e.g. business model metadata. See Figure 5 for a rough structure of the metadata structure. A programming model for metadata access and discovery. Several APIs for reading and writing Metadata support this EURESCOM Participants in Project P1149 EDIN 0001-xxxx

20 page 20 (34) DRAFT EURESCOM Project Report 4 The Construction Paradigm Model Transformation Model transformations play an important role within the MDA. This includes transformation between PIMs and PSMs but also transformations of data models as supported by the CWM standard. In both cases, the transformation is defined by the provision of rules on the metamodellevel. The rules describe, how instances of the source metamodel elements are transformed to instances of the target metamodel elements. MOF Meta M eta Model Source Meta Model e.g. Business Meta Model Define Formal Transformation Rules Target M eta Model e.g. Platform Meta Model Source Model e.g. Business Model Apply Transformation Rules Target Model e.g. Platform Specific Software Components Figure 6 Model Transformation Foundation In the subsequent sections, the model transformation in EDOC and CWM are explained as example for the two application scenarios for model transformations as described above Model Transformation in EDOC Currently, the OMG suggests using the recently adopted EDOC (Enterprise Distributed Object Computing) Profile for UML as one possible metamodel for PIMs. This specification does also contain metamodels for two target infrastructures: The CORBA Component Model (CCM) and Enterprise Java Beans. Transformation rules are provided in the EDOC specification on the basis of metamodels for both infrastructures. That means, for each concept of the PIM metamodel (EDOCprofile) it is defined, how it maps to concepts of both of the target PSM metamodels (CCM and EJB metamodel). The following table contains an example from the EDOC on how the mapping is defined. EDOC metamodel Process Component Description A ProcessComponent represents the contract for a component that performs actions it does something. A ProcessComponent may realize a set of Ports for interaction with other ProcessComponents and it may be configured with properties EJB metamodel Maps to an <<EnterpriseBean>> (in this description) but can also naturally map to higher (Business Process) or lower (Object) level concepts. Although the EDOC profile is a first step towards the application of the MDA, the profile does not fully reflect the needs of the telecom domain. As an example, Quality of Service descriptions are not part of the EDOC profile. As a conclusion of this project, it is suggested to define a telecom specific metamodel for PIMs and to apply the technology of EDOC (metamodel based transformation) to define the transformation to PSMs. EDIN 0001-xxxx 2002 EURESCOM Participants in Project P1149

21 DRAFT EURESCOM Project Report page 21 (34) Model Transformation in CWM A key aspect of data warehousing is to extract, transform, and load data from operational resources to a data warehouse or data mart for analysis. Extraction, transformation, and loading can all be characterized as transformations. In fact, whenever data needs to be converted from one form to another in data warehousing, whether for storage, retrieval, or presentation purposes, the application of transformation rules is involved. Transformation, therefore, is central to data warehousing. Warehouse M anagement Warehouse Process Warehouse Operation Analysis Transformation OLAP Data M ining Information Visualization Business Nomenclature Resources Object- Oriented (ObjectModel) Relational Record- Oriented Multi Dimensional XM L Foundation Business Information Data Types Expressions Keys Index Type Mapping Software Deployment ObjectModel (Core, Behavioral, Relationships, Instance) Figure 7 The Common Warehouse Metamodel The CWM standard addresses this problem by providing a separate package as part of the CWM metamodel - the transformation package. The Transformation package contains classes and associations that represent common transformation metadata used in data warehousing. It covers basic transformations among all types of data sources and targets: object-oriented, relational, record, multidimensional, XML, OLAP, and data mining. The Transformation package is designed to enable interchange of common metadata about transformation tools and activities. Specifically it is designed to: Relate a transformation with its data sources and targets. These data sources and targets can be of any type (e.g., object-oriented, relational) or granularity (e.g., class, attribute, table, column). They can be persistent (e.g., stored in a persistent storage) or transient. Accommodate both "black box" and "white box" transformations. In the case of "black box" transformations, data sources and targets are related to a transformation and to each other at a coarse-grain level. One knows that the data sources and targets are related through the transformation, but one doesn t know how a specific piece of a data source is related to a specific piece of a data target. In the case of "white box" transformations, however, data sources and targets are related to a transformation and to each other at a fine-grain level. One knows exactly how a specific piece of a data source is related to a specific piece of a data target through a specific part of the transformation. Allow grouping of transformations into logical units. At the functional level, a logical unit defines a single unit of work, within which all transformations must be executed and completed together. At the execution level, logical units can be used to define the execution grouping and sequencing (either explicitly through precedence constraints or implicitly through data dependencies). A key consideration here is that both parallel and sequential executions (or a combination of both) can be accommodated EURESCOM Participants in Project P1149 EDIN 0001-xxxx

22 page 22 (34) DRAFT EURESCOM Project Report The Transformation package assumes the existence of other CWM packages that represent types of potential data sources or targets: Object Model (object-oriented), Relational, Record, Multidimensional, XML, OLAP, and Data Mining. A transformation transforms a set of source objects into a set of target objects. The elements of a data object set can be any object model elements, but typically are tables, columns, or model elements that represent transient (in memory) objects. Data object sets can be both sources and targets for different transformations. In particular, a given data object set can be the target of one transformation and the source of one or more transformations within the same logical unit. This is often the case with transformations that produce and consume temporary objects. Transformations allow a wide range of types (and granularity) to be defined for their data sources and targets. For example, the source type of a transformation can be an XML schema while the target type is a column, if the transformation deals with storing an XML document in a column of a relational database. More typically, the source types of a transformation are classes and attributes while the target types are tables and columns, or vice versa, if the transformation deals with converting object data into relational data, or vice versa. The Transformation package contains metamodel elements that support the following functions: Transformation and data lineage. These classes and associations deal with transformations and their sources, targets, constraints, and operations. Transformation grouping and execution. These classes and associations deal with grouping of transformations to form logical units and to define execution sequences. Specialized transformations. These classes and associations define specialized, "white box", transformations that are commonly used in data warehousing. The transformation package of the CWM standard provides a metamodel, where actual models are used to define transformation. In that sense, the CWM standard does (in contrast to EDOC) not contain a concrete set of transformation rules but the vocabulary to define a transformation rule from a data source to a data target Precise Modelling a Precondition for Model Transformation A model is a representation of (a part of) a systems structure, function and/or behaviour at a certain level of abstraction. During model transformation in the sense of a PIM to PSM mapping, the information contained in a PIM has to be transformed to a representation in a PSM, which is equivalent to that contained in the PIM. As long as this transformation only concerns structural aspects, model transformation in most cases is not that difficult. An UML class providing an UML interface can easily be transformed to a Java class with a Java interface or a CORBA component supporting a CORBA interface. For structural definitions in most cases it is not difficult to define a structural equivalent representation in a richer modelling world the normal case when going from PIM to PSM. However, as the model definition says, not only structures have to be considered but also function and behaviour. At that level, in the past the most often used language for PIMs (UML) has had semantical problems. Behaviour specifications in UML were not be mapped to code or transformed to PSMs since they were not precisely, unambiguously defined. One solution for that problem is UML profiling. In that case, the profile restricts the semantic of UML and, by doing so, it reduces the ambiguity and enables the implementation of model transformation components. Another solution is the evolution towards an action semantics definition for UML and the precise OCL (Object Constraint Language) definition as part of the upcoming major revision of UML (UML 2.0). The action semantics specification for UML was recently adopted by the OMG. The objective of the specification is to define, what kind of actions can be used to specify the semantics of UML descriptions. The specification provides a metamodel for the actions, defining what kind of different actions exists, how they are related to the existing UML metamodel and what information belongs to an action specification. EDIN 0001-xxxx 2002 EURESCOM Participants in Project P1149