Project Report. Impacts of changes in enterprise software construction for telecommunications

Project Report Impacts of changes in enterprise software construction for telecommunications Model Driven Architecture Adaptations and impacts for the telecom domain Editor: Michael Herzog, Deutsche Telekom AG Abstract This document embraces the findings on the analyse what kind of system design, construction, manufacturing, integration, deployment and maintenance problem solutions can be improved by the rigorous application of the MDA and covered techniques. The focus of this study is the telecom operators view and their business cases. The investigations are undertaken in the following areas: Quality of Service in a telecom middleware platform, Telecommunication Service Access and Subscription, Telecommunication Management Network, modelling Parlay applications and service creation. These areas seam to be most promising for the application of MDA. The investigations focus on the limitations of today s modelling and analyse the problem kinds that can be solved by the rigorous application of the MDA. The document also outlines the necessary adaptations, standardisations and specialisations that need to be done in order to use the MDA approach in the telecom filed. The document also suggests how legacy systems need to be reengineered, to be usable in MDA context. EDIN 0289-1149 Project P1149 For full publication March 2002

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 Adaptations and impacts for the telecom domain Editor: Michael Herzog, Deutsche Telekom AG Project leader: Sune Jakobsson, Telenor AS Project supervisor: Anastasius Gavras, EURESCOM EURESCOM published project result; EDIN 0289-1149 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.

EURESCOM Project Report page 3 (38) 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 utilise 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 utilisation 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 second of two deliverables of this study and is titled: Model Driven Architecture Adaptations and impacts for the telecom domain. The other deliverable is titled: Model Driven Architecture Assessments of relevant Technologies. This deliverable outlines necessary adaptations, standardisations and specialisations that need to be done in order to use the Model Driven Architecture approach in the telecom filed. 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149

page 4 (38) EURESCOM Project Report Executive Summary The Model Driven Architecture (MDA) of the OMG has turned out to address the challenges of today s highly networked, distributed and constantly changing systems environment, providing an architecture that assures Portability Increased application component re-use and Reduction of cost and complexity of application development and management, now and into the future. The success of MDA crucially depends on the availability of tools. These tools should support the creation and transformation of models as well as the code generation for the targeted platforms. So far there are a few tools that support a MDA based development of software. Also most of the CASE-tool vendors have made announcements to support MDA in the future. Especially for the evaluated software engineering use cases like Parlay or TMN, the existing tools are generally applicable and allow a MDA based approach. Telecommunication specific modelling profiles can be integrated in these tools as well as specific code generators targeting the telecom infrastructure(s). Another important matter especially in the telecom domain is the re-engineering of legacy applications. Only with the support of tools, which assist and automate the re-engineering process, it will be possible to include legacy applications in a MDA context. Currently there are tools that facilitate reengineering of programming languages such as C++ and Java. However, they do not support an abstracted view on the re-engineered code as would be required if a Platform Independent Model (PIM) should be populated. Nevertheless, it seems possible that there will be (semi-) automatic tools, which allow a full re-engineering. In these areas further research and development is necessary. This document embraces the findings on the analysis of what kind of system design, construction, manufacturing, integration, deployment and maintenance problem solutions can be improved by the rigorous application of the MDA and covered techniques. This study concluded that the Model driven Architecture is a promising paradigm especially for the telecom domain. EDIN 0288-1149 2002 EURESCOM Participants in Project P1149

EURESCOM Project Report page 5 (38) List of Authors Babak Farshchian, Telenor AS Erik Berg, Telenor AS Marc Born, IKV++ Technologies AG Mariano Belaunde, France Telecom R&D Michael Herzog, Deutsche Telekom AG Olaf Kath, IKV++ Technologies AG Sune Jakobsson, Telenor AS 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149

page 6 (38) EURESCOM Project Report Table of Contents Preface...3 Executive Summary...4 List of Authors...5 Table of Contents...6 List of Figures...7 Abbreviations...8 1 Introduction...9 2 Two MDA Case Studies...10 2.1 UBS...10 2.2 Wells Fargo...10 2.2.1 The Wells Fargo Processing Environment...10 2.2.2 Model Driven Development...11 2.2.3 MDA Provides a Bridge to the Future...12 3 Examples from the telecom domain that can be improved by the application of MDA...13 3.1 Telephony Networks...13 3.1.1 Parlay / OSA...13 3.1.2 IN -networks...14 3.1.3 SIP-Network...16 3.1.4 MDA Approach...17 3.1.5 Evolution towards MDA for Telephony Networks...18 3.2 Telecommunication Service Access and Subscription...18 3.2.1 Description...18 3.2.2 Traditional Approach...19 3.2.3 Limitations of traditional Approach...20 3.2.4 MDA Approach...21 3.2.5 Evolution towards MDA for TSAS...23 3.3 Quality of Service in a telecom middleware platform...23 3.3.1 Description...23 3.3.2 Limitations of the traditional Approach...24 3.3.3 MDA Approach...24 3.3.4 Evolution towards MDA for QoS...28 3.4 MDA for Telecommunication Management Network...28 3.4.1 Description...28 3.4.2 Traditional Approach...29 3.4.3 MDA approach for TMN...32 3.4.4 Evolution towards MDA for TMN...35 4 Necessary adaptations of MDA for application in the telecom operators domain...36 5 Conclusion...37 References...38 EDIN 0288-1149 2002 EURESCOM Participants in Project P1149

EURESCOM Project Report page 7 (38) List of Figures Figure 1 UBS Migration Repository Prototype Architecture...10 Figure 2 Wells Fargo s BOS Processing Environment...11 Figure 3 Creating and Maintaining the Wells Fargo Environment from a Model...12 Figure 4 PARLAY/OSA API s...13 Figure 5 Telenor IN network...15 Figure 6 SIP network...16 Figure 7 SIP service...17 Figure 8: Main classes of the transport network metamodel...33 Figure 9 An example of a textual rendering of a network configuration...34 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149

page 8 (38) 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 0288-1149 2002 EURESCOM Participants in Project P1149

EURESCOM Project Report page 9 (38) 1 Introduction MDA is a very recently defined framework and the market of tools and technologies supporting the MDA is not fully established at this time. However, there are already some early assumptions made on the market volume, which can be captured by MDA related products. These assumptions are based on the IDC 1999 numbers for the Component Construction, CASE and OO Visual Modelling Tool markets, which were $1,000 Million ($ 1 US Billion) total volume. There was also the projection that this market will have a volume of $3,000 Million in 2004. However, due to the current economic slowdown it is more realistic to assume $2,000 Million in 2005. From this whole market, MDA will probably capture 20% in 2005 and up to 50% in 2007. In numbers, this equals a total volume for MDA of $400 Mill in 2005 and $1.000 Million in 2007. This document embraces the findings on the analyse what kind of system design, construction, manufacturing, integration, deployment and maintenance problem solutions can be improved by the rigorous application of the MDA and covered techniques. The focus of this study is the telecom operators view and their business cases. The investigations are undertaken in the following areas: Quality of Service in a telecom middleware platform, Telecommunication Service Access and Subscription, Telecommunication Management Network, modelling Parlay applications and service creation. These areas seam to be most promising for the application of MDA. The investigations focus on the limitations of today s modelling and analyse the problem kinds that can be solved by the rigorous application of the MDA. The document also outlines the necessary adaptations, standardisations and specialisations that need to be done in order to use the MDA approach in the telecom field. The document also suggests how legacy systems need to be re-engineered, to be usable in MDA context. 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149

page 10 (38) EURESCOM Project Report 2 Two MDA Case Studies 2.1 UBS The most recent success has been in the area of data migration facilities using the Common Warehouse Model (CWM ) standard from the Object Management Group (OMG ). As part of the transition, UBS required a mechanism to migrate their existing legacy data and code into the new component-based environment. In order to control the migration, an appropriate repository and standardised means of modelling transformations between physical and logical data structures was essential. OMG's CWM seemed to fit the bill. Legacy System CWM -Based COBOL record structures MOF (XMI, CORBA/ Java) CWM -Based ER Models CWM -Based Transformation Models Migration Repository Prototype MOF (XMI, CORBA/ Java) UML-Based Object Models MOF (XMI, CORBA/ Java) CWM -Based ER Models New Component Based System (OMG, J2EE) New CWM Based Data Warehouse Transformation (Courtesy Hans-Peter Hoidn UBS) Figure 1: UBS Migration Repository Prototype Architecture Using the CWM standard in this important project, UBS was able to not only rapidly construct a prototype repository, but also validate the standard. During the validation process it was found that explicit extensions to the standards were required by UBS. These extensions have now been formally incorporated into CWM as the COBOL Data Division and Entity Relationship extensions. This is an important proof that a CWM-based repository can successfully be used to hold information necessary to support data migration. The CWM extensions proved successful and have now been formally adopted by UBS. 2.2 Wells Fargo Wells Fargo bank is known world-wide as a financial institution. The bank has had an aggressive expansion of its business in the past, and, thereby, expended its operations. This includes acquiring other companies and integrating them into Wells Fargo s IT infrastructure. 2.2.1 The Wells Fargo Processing Environment The physical complexity of Wells Fargo's business processing environment, with its numerous platforms is shown in Figure 2. This example is the Wells Fargo Business Object Services (BOS) system. EDIN 0288-1149 2002 EURESCOM Participants in Project P1149

EURESCOM Project Report page 11 (38) Figure 2: Wells Fargo s BOS Processing Environment Wells Fargo is a typical company that has a large number of mainframe-based applications as well as a number of client applications that are based on both the Windows/Intel and Unix environment. Wells Fargo also has Unix systems typically hosting Informix or Oracle applications and a CTI (computer telephone integration) environment that connects the voice response units. On top of all that, the company -like most banks- requires that all its critical systems be capable of handling high-volume processing, rapid response times and high availability. 2.2.2 Model Driven Development Several of the online Wells Fargo applications are created by development teams that require the co-operative work of three groups: A client group (e.g., Internet banking), the BOS group and the systems organisation that maintains back-end systems and records. In effect, the BOS group contributes the UML-based business model, which defines the core business objects and the interfaces, and the middleware infrastructure for the project. Reusing objects defined in the BOS infrastructure and, in some cases, extending those objects creates the actual application. The application developers create the UML diagrams that describe the specific applications they are developing and then generate the IDL message code, which is used to generate the CORBA stubs and repository entries that will be used in actually passing messages between application components. First they define the application in PIM using UML tools. From that, they generate the implementation models (PSM) that are actually needed for the application. These platform-specific models are then augmented with additional code and any additional logic that may be needed. They are not trying to generate a complete application but only those portions that can be efficiently generated by a model. Last, they generate the actual application programs. Figure 3 illustrates how Wells Fargo uses its UML models to generate and maintain its middleware environment. 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149

page 12 (38) EURESCOM Project Report Figure 3: Creating and Maintaining the Wells Fargo Environment from a Model In this example, a UML model defines the relationship between client applications, server and legacy support. The model describes the calls and responses that flow between the customer application, the middle-tier server application and the legacy data systems. The UML model is maintained on Rational Rose. Once the UML model is created or modified, the UML tool generates codes to be used in the existing middleware environment. Since Wells Fargo is using CORBA, the UML model generates CORBA code (proxies and IDL) as well as some objects needed to support the various linkages. 2.2.3 MDA Provides a Bridge to the Future At the same time, Wells Fargo is experimenting with more advanced Java techniques (EJB, RMI) and with XML and SOAP (Simple Object Access Protocol). While not committed to moving to these newer technologies at this time, the IT department doesn t anticipate any problems if Wells Fargo decides to do so. Once again, his confidence is based on the fact that Wells Fargo s middleware environment is described in UML and is not directly linked to a specific implementation system. At the same time that MDA makes it possible to move to another technology, it also makes it easy to support multiple technologies simultaneously. The legacy systems are not going to go away, and many of the current CORBA platforms will remain, even if new technologies are added. But MDA provides a bridge between multiple infrastructure technologies and ensures that they all can be managed within a common model. EDIN 0288-1149 2002 EURESCOM Participants in Project P1149

EURESCOM Project Report page 13 (38) 3 Examples from the telecom domain that can be improved by the application of MDA 3.1 Telephony Networks 3.1.1 Parlay / OSA 3.1.1.1 Description The past years have shown an enormous increase in efforts to open up telecom network functionality for application development. Parlay/OSA is such an effort, dating back to 1998 with the formation of the Parlay Group. Later 3GPP and ETSI with their OSA framework joined in and together formed the Joint API Group, which continues the work on the Parlay/OSA architecture. The opening of the telecom network functionality means that applications can access core network functionality by means of open standardised APIs based on open technology. A consequence of this is that it enables new business models where applications can be developed and provided by enterprises outside the traditional network operator domain. Applications can be built with standard (off-the-shelf) IT technology tools. Figure 4: PARLAY/OSA API s The APIs naturally form the interface between what is called the application layer or Service Network on one side, and the core network on the other side. Applications, deployed on application servers (which can be any standard IT platform), use the capabilities defined in Parlay/OSA, provided by Service Capability Servers and offered to applications through the APIs. Communication between the application and the SCS is done using standard IT middleware infrastructure, and is not restricted or limited to only one technology. So far Parlay/OSA interfaces have been modelled using IDL, DCOM and UML. The Parlay/OSA Framework consists of a family of interfaces, which includes capabilities for trust and security management, registration, creation and discovery of new services, as well as load balancing, fault managing, event notification and contract management (e.g., management of contracts between application provider and network operator). 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149

page 14 (38) 3.1.1.2 Traditional approach EURESCOM Project Report Parlay/OSA is mainly a set of API definitions that describe the capabilities offered to 3 rd party developers. These APIs can be defined in any middleware, but it seems that CORBA is the one preferred the most. This meant that only generic middleware and programming environments was available for implementing and developing Parlay/OSA services. Developers implemented services as they would implement any other CORBA client. No specific tools for implementation, testing or validation existed. But that situation has been changed a bit. Several vendors have come up with some kind of tools and development environments. 3.1.1.3 Tools for modelling Parlay applications At the present time there are very few tools for modelling and developing Parlay/OSA applications. Those that exist are somewhat limited, and merely facilitate the development process. The functionality offered is in the form of components and wizards, no real UML-like modelling tool exists so far, and the current products seem to be connected with (and dependent on) other proprietary solutions. Appium technologies (www.appium.com) offer some such tools. Namely the Appium-GBox, which is an application development environment that enables efficient creation, validation and testing of new communication applications implemented in J2EE, CORBA and JSP technologies. GBox is a development environment for developing Parlay based telecom applications, and is integrated with Borland JBuilder. GBox supports the developer with wizards and templates providing the skeletons and examples of popular applications like click-to-dial or number translation. The GBox also offer validation capabilities, enabling the testing of arbitrary complex applications without any access to a real telecom network. A Parlay-Lab environment is also provided, enabling the functional testing of applications in a development or deployment environment using VoIP network infrastructure. Incomit (www.incomit.com) also provide a wizard and template tool for telecom application development that supports Parlay/OSA: The Incomit Movade solution. It consists of three building blocks: The Movade Network Service Platform, the Movade Application Server and the Movade Development Studio. The Network Service Platform offers Parlays/OSA interfaces. The application server (which is based on Parlay/OSA) offers APIs that hide the complexity of the telecom network. The Development studio offers amongst other things automatic code generation through drag and drop functionality (templates), with easy deployment to their application server. It is a graphical service creation environment for the Movade Application Server, and thus not a generic development tool for Parlay/OSA services. 3.1.1.4 Limitations to the traditional approach The traditional approach is to implement Parlay/OSA services either manually (by using the APIs directly) or using some kind of tool that facilitates the process (wizards, templates, easy-touse components). Although the interfaces are standardised, the way to implement application/services (i.e., interface clients) is not. Even though CORBA seems to be the preferred middleware, there is no guarantee that this will be used by the Service Capability Servers of every network operator. There is thus no guaranteed interoperability, and developers must then convert their applications by hand to other types of middleware if using such a service. 3.1.2 IN -networks 3.1.2.1 Description Telenor have IN equipment from Ericsson as the main supplier, as shown in Figure 5. EDIN 0288-1149 2002 EURESCOM Participants in Project P1149

EURESCOM Project Report page 15 (38) Findesigner Master Mirror of Master SCP GIN SS#7 IP SSP IVR Figure 5: Telenor IN network The SMS and SCE are two service independent management systems from Ericsson for the Intelligent Network and the SSI located in a SCP or SSCP node. They act as an interface to the network elements and provide functions for the design and management of IN services. SMS is used for management of IN services, such as allocating customer data. SCE is used to create new IN services or to modify existing services. SMS and SCE are not part of the AXE system. They are separate management systems hosted on a SUN Solaris platform. 3.1.2.2 Traditional approach The Service Management System (SMS), the Service Creation Environment (SCE) and the SMA Base are three separate management tools products that provide a user-friendly interface to the SCP and SDP based on graphical presentations. Telenor has extended the Ericsson SMS with own tools like Fin-designer that can populate the SCE database with customer data. The Fin-designer provides a graphical tool that configures modules like time of day routing, etc., which are then deployed on the SCP. The Fin-designer relies on scripts created with the SCE. 3.1.2.3 Limitations to the traditional approach The SCP has no standard access to external peripherals, or non-in devices, like databases. The SCP forwards INAP messages to GIN (Gateway to IN). The GIN provides a bridge between the SS#7 IN network and IP based network. The GIN platform is then connected on an IP network, and can access and control other units like IVR, and external databases. The IVR used is controlled from the IP side, and delivers fixed speech messages into the SS7 network. A call leg is set up to the IVR, and the voice message is delivered to the other call leg. The call leg can set up as bridge or transfer, depending on the dialogue. Future versions of the IVR could be VoiceXML based instead. 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149

page 16 (38) 3.1.3 SIP-Network EURESCOM Project Report 3.1.3.1 Description Additionally, we at Telenor are investigating SIP (Session Initiation Protocol) as a possible direction in the future networks, see Figure 6. In a SIP network all devices are connected to an IP network, and they are not as tightly interconnected as in the IN SS#7 network. The VoiceXML device will in this case support SIP messages directly, so the access and control is simplified compared to the IN case. SIP is a simple signalling protocol for establishing, modifying or terminating sessions between two or more parties. SIP is simple and has only a few messages and message types. SIP uses heavily principles and protocols from other TCP/IP protocols like http, MIME, SMTP. VXML SIP proxy SIP client PSTN GW 3.1.3.2 Traditional approach Figure 6: SIP network Services in the SIP network can be viewed as shown in Figure 7. The service is provided through an API on the SIP proxy for the IP network. Services are coded in some high-level language using libraries with SIP functionality. Java provides such a package for SIP API s. The main components in a SIP network are: User agents initiate SIP requests and are usually the final destination for such requests. IP telephones, conferencing bridges and gateways are examples of user agents. Registrars. User agents may register their SIP addresses with one or more registrars, such that other SIP entities may determine that a given SIP address (e.g., a phone number) may be reached on a specific IP address and port number. Location servers store the data that are registered with the registrar. SIP does not specify the protocol between the location server and other SIP servers. Typical examples are SQL databases and LDAP/X.500 servers. Proxy servers are application layer routers that forward SIP requests and responses. Redirect servers receive requests and then return the location of another SIP user agent or server where the user might be found. Different SIP servers are often combined in one physical unit, like combined registrar, proxy and naming server. The PARLAY specification enables a SIP server to be accessed through a PARLAY server, when the SIP server is a Service Capability Server. EDIN 0288-1149 2002 EURESCOM Participants in Project P1149

EURESCOM Project Report page 17 (38) Service SI Service API Media stream SIP proxy SIP-telephone Soft phone IP (media) PSTN Figure 7: SIP service 3.1.3.3 Limitations to the traditional approach Gateway The SIP services are only based on the protocol descriptions, and not modelled in any modelling language. There are, however, currently attempts to encapsulate SIP on a higher level like SIP Servlets, but that only simplifies some of the underlying details of the SIP protocol. But when adding gateways to other networks, like IN that have a much richer capability sets, SIP has some shortcomings. Similar problems exist with QoS, reliability and availability for SIP networks. 3.1.4 MDA Approach Service creation in IN networks is hampered by the shortcomings of the existing modelling and development tools. The tool used by Telenor, Ericsson s Service Creation Environment (SCE) provides very limited wizard-like interfaces for service developers. Telenor has already done some effort in developing front-end tools for SCE (an example being Fin-designer tool) where the service developer can configure services by composing graphical symbols. The tool enables a salesperson to customise a service for a specific customer, and later install this in the IN network. Fin-designer is the only tool of its kind that we know of. Not only such tools are rare in the market, they also have at least three limitations: They are still far behind state-of-the-art visual modelling formalisms such as UML. They are necessarily targeted towards a single service execution environment (i.e., IN). These tools provide very limited access to developing services that make use of external entities from other domains, e.g., databases, user profile servers, etc. An alignment in the direction of MDA seems to promise considerable improvements to the situation. MDA can improve IN service development by allowing service developers to focus on the business aspects of their services through the use of e.g., UML and the creation of PIMs for their services. The developed PIMs are transparent with regard to the underlying IN platform or a possibly mixed execution environment. The development life cycle is changed in the following way: A PSM for a specific IN platform is developed that allows the mapping of PIMs on to an IN network implementation. PSMs for other types of platforms that are going to be used in conjunction with the IN networks are developed, or might exist already (e.g., a Java LDAP PSM). Mapping rules for mapping from PIMs to the developed PSMs are specified. 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149

page 18 (38) EURESCOM Project Report PIMs for the specific services are created to address specific business problems without taking into consideration what kind of platform-specific implementation will be generated. The MDA framework and MDA-enabled tools are used to generate an executable service running on a mixture of IN and external platforms. A clear benefit is that the same service definition (PIM) can be used to develop services on other platforms through other PSMs. For instance, a Parlay PSM will allow the mapping of an IN PIM on to a Parlay implementation. Another benefit is that IN services can be developed using advanced visual modelling formalisms such as UML. These formalisms offer a higher level of expressive power and are more fit to the business area to be supported. There are a number of steps to perform in order to enable an MDA-enabled IN service development environment: The development of a set of guidelines on how to use UML to develop typical IN services. The development of PSM for IN. This PSM should also address the issue of integrating external entities as part of an IN service through some API The development of mapping rules for mapping from PIMs to PSMs. Use the CS-1 specification as a starting point for the service modelling. 3.1.5 Evolution towards MDA for Telephony Networks 3.1.5.1 How has the design flow to be changed with MDA? To support MDA the current services need to be modelled in some modelling language. Some of the previously described systems like PARLAY already have API s and IDL s defined and standardised. These could then be used as a starting point for a PIM model. When the model is complete the generated PSM should conform to the defined API s and IDL s. For SIP based systems they can either be accessed through PARLAY, or be used standalone. In the standalone version, SIP Servlets can provide some level of bundling SIP functionality or the MDA tools could code generate modules that use the SIP protocol for communication with SIP compliant nodes. The PIM would need to be defined out of the behavioural descriptions of the SIP protocol. For IN based systems, the most obvious point of integration would be at INAP protocol level. The MDA tools could code generate modules that would be gateways to the IN platform. Similarly IN scripts should be exported from the MDA tools and imported into the SCE and SMS on the IN platform. 3.1.5.2 How to handle legacy? Legacy systems that must be reused in a model should preferably be re-engineered instead of wrapped with some suitable middleware system. Legacy systems tend to already be wrapped in several levels throughout their lifecycle, from the initial creation to a constantly expanding system with expansions added, as they are needed. The legacy system should instead be modelled at some abstraction level, in a PIM model. This will in the long run simplify the transformation into MDA based systems. 3.2 Telecommunication Service Access and Subscription 3.2.1 Description The management of users, customers, services, service providers and their various profiles in connection with the control of access rights is one of the main problems of telecommunication operators. The Object Management Group has tried to solve this problem with the provision of the Telecommunication Service Access and Subscription specification. The problem addressed by this specification is described below. EDIN 0288-1149 2002 EURESCOM Participants in Project P1149

EURESCOM Project Report page 19 (38) Network operators have traditionally followed a network-centric approach to delivering scalable, reliable and economic services to consumers and enterprises. The basic functions that are required to support services such as 800 numbers, call waiting and personal numbering have been under the exclusive control of the network operators. Enterprises and service providers wishing to offer value-added solutions, such as call centres, have had to rely on an edge-of-network approach and have been denied access to useful information and capabilities within the network. The disadvantages of this separation are significant in today s marketplace. Network operators employing a network-centric approach are unlikely to have the resources and flexibility necessary to respond to the specialised requirements of different customer markets. Similarly, solution providers adopting an edge of network approach, whilst they may have the flexibility required for customising services, are unable to gain the efficiency of using in-network functions and information. The architecture of the Telecommunication Service Access and Subscription (TSAS) specification combines the benefits of the network centric approach of economies of scale with the flexibility of the edge-of-network approach. The set of interfaces contained within this specification provide the domain facilities through which network operators can offer 3 rd party enterprises secure access to the capabilities of the network. Capabilities such as call control and user location can be offered (through their own interfaces) or by 3 rd party value-added services and solutions. Of course, this approach is not only applicable to providing access to embedded network capabilities. It can also be used for a wide range of commercial models supporting customer-tobusiness or business-to-business relationships for ecommerce and the Application Service Provider market in general. Provision of functions for billing and payment can be easily integrated. It is not within the scope of TSAS to restrict the breadth of (component) services that could be offered by it. This specification is technically aligned with that of the Parlay Group. Consequently, the service interfaces specified in the Parlay API can be offered using this specification. 3.2.2 Traditional Approach The TSAS specification is mainly a set of segmented IDL interface definitions together with data types that describe the information structures. It contains an access-related part and a part, which deals with subscription. An example for the IDL of the access related part is provided below: module SessCtrl { interface SessionControl : SegmentBase { void list_service_sessions ( in SpecifiedAccessSession as, in SessionSearchProperties desired_properties, out SessionList sessions ) raises ( SpecifiedAccessSessionError, PropertyError, ListError ); void end_sessions ( in SessionIdList session_id_list ) raises ( SessionError ); void end_my_participations ( in SessionIdList session_id_list ) raises ( SessionError ); 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149

page 20 (38) void resume_session ( in SessionId session_id, in ApplicationInfo app, out SessionInfo session_info ) raises ( SessionError, ApplicationInfoError ); EURESCOM Project Report }; }; void resume_my_participation ( in SessionId session_id, in ApplicationInfo app, out SessionInfo session_info ) raises ( SessionError, ApplicationInfoError ); The Subscription related part does also contain an information model. This model is depicted below: Implementations of TSAS implement the IDL interfaces of the specification typically on top a CORBA based infrastructure. The information itself is stored in one or more databases. The information model is translated by hand into a database schema (in case of a relational database) and it is the responsibility of the developer to connect the access via CORBA with the database. In some environments the CORBA based implementation is wrapped by other access mechanisms like web access. Also this has to be implemented by hand. 3.2.3 Limitations of traditional Approach The traditional way of the provision of the specification and the normal approach for its implementation contains several drawbacks: EDIN 0288-1149 2002 EURESCOM Participants in Project P1149

EURESCOM Project Report page 21 (38) The specification of the interfaces is provided in IDL and by that platform specific. Implementations on top other platforms then CORBA are not straightforward. Mappings to these platforms have to be done by hand. The information model and the IDL data structures are independently defined. Consistency is not automatically ensured. In fact, in many realisations of TSAS the information model is just documentation and not really used. Changes or adaptations of the information structures have to be integrated into the IDL by hand and in many different places, which implies a lot overhead. There is no exchange format for the contents of the underlying databases. Exchange formats have to be specified by hand and in case of changes to the information model, they have to be changed by hand again. Integration of databases has to be provided by the developers by hand. 3.2.4 MDA Approach In a MDA approach for the scenario there would be 2 general modelling activities: The development of platform independent model of the defined interfaces and information structures. In addition, the MDA would require the modelling of the behaviour of the interfaces in order to enable an automatic generation of code or the transformation to a platform specific model. The definition of the information model as a MOF metamodel. The information elements of the metamodel will also be used as information structures for the interface definitions of the previous task. From these two models the MDA development process leads to one or more platform specific models (or implementation code directly) for the interface realisations and to an implementation of the MOF based repository derived from the metamodel. One example of a platform specific model would be a platform specific model for CORBA possible with an analogue structure to the existing TSAS specification. This could be automatically derived from the platform independent model using MDA development tools. The implementation for the CORBA model could also be automatically generated depending on the degree of completeness of the behaviour descriptions in the model. The information structures necessary to define the platform independent interfaces can be extracted from the metamodel as to be seen in the following example: The struct Property is defined in the actual specification. In addition, there is a sequenced PropertyList for that type. struct Property { PropertyName name; PropertyValue value; }; typedef sequence<property> PropertyList; 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149

page 22 (38) This information structure is replaced by the following MOF metamodel: EURESCOM Project Report Property value : Subscription::Any <<collection>> PropertyList +values 0..n property_type +type 1 PropertyType propertyname : String type : Subscription::TypeId If IDL is generated from that metamodel in case of mapping to a CORBA environment, the following structures 1 are generated: interface Property; typedef sequence < Property > PropertyList; interface PropertyType; interface PropertyClass: ::Reflective::RefObject { readonly attribute ::Subscription::PropertySet all_of_type_property; readonly attribute ::Subscription::PropertySet all_of_class_property; ::Subscription::Property create_property ( in ::Subscription::Any value) raises ( ::Reflective::MofError); }; interface Property: PropertyClass { ::Subscription::Any value ( ) raises ( ::Reflective::MofError); void set_value (in ::Subscription::Any new_value) raises (::Reflective::MofError); ::Subscription::PropertyType type ( ) raises (::Reflective::MofError); }; void set_type ( in ::Subscription::PropertyType new_value) raises ( ::Reflective::MofError); A part of the MOF metamodel, which will replace the information model, is depicted below. Out of that model IDL interfaces and programming languages API to access repositories, which contain the information (i.e., the model) conforming to the metamodel are generated. In addition, all the implementation of the repository itself is generated, including the connection to a database. Furthermore, XML DTDs or Schemas are generated applying the XMI standard. 1 Only parts of the generated IDL are shown. EDIN 0288-1149 2002 EURESCOM Participants in Project P1149

EURESCOM Project Report page 23 (38) Provider +providers 1..n +providers 0..n +theprovider 1 provider_customer contarct_provider services +providedservices Service 0..n 1 +theservice +customers 0..n Customer +thecustomer 1 +contracts 0..n +thecustomer +contracts Contract 1 contract_customer 0..n 1 +contract +contracts 0..n contract_service customer_user +users 1..n User entitlement_contract +users 1..n usergroup_user +entitlement 1 0..n Entitlement +entitlements 0..n +groups UserGroup 0..n +contains entitlement_usergroup +entitledgroups 0..n 0..n +containedin contained_ugroups 3.2.5 Evolution towards MDA for TSAS The evolution path towards a MDA development approach for the above scenario is straightforward: MOF technology has to be applied to formalise the information model MOF repositories replace the former hand coded database access MOF and XMI replace the hand written XML DTDs for initialisation and model exchange UML interface models in conjunction with the MOF model replace the former IDL interfaces and data structures UML action semantics is used to formalise the behaviour of the UML interfaces MDA Code generation replace the hand written implementation for the TSAS specification. 3.3 Quality of Service in a telecom middleware platform 3.3.1 Description Global telecom operators own a heterogeneous infrastructure on top of which they operate many different distributed services. The components of these services have to communicate with each other increasingly. In addition, new services are frequently added to this infrastructure. Of course, these new services have to be implemented and tested for every used operating system in a short time in order to gain market advantages. For this reason middleware platforms are often used to 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149

page 24 (38) EURESCOM Project Report give the heterogeneous infrastructure a homogeneous layer. This eases the implementation and testing of new service components. Besides off-the-shelf services can be bought and integrated, which lowers also the costs for new services. Quality of service is needed in these middleware platforms for three reasons: First of all a middleware platform separates the services from the underlying operating system. As a result some quality of services like bandwidth and dependability cannot be realised any more by the services, since the operating system functions are no longer reachable. The middleware platform has to provide interfaces for quality of service. The second reason is that most telecom operators are switching to IP based platforms. Since IP offers no reliable Quality of Service itself, there have to be mechanisms to provided Quality of Service. Last but not least quality of service in a middleware platform enables a concept for modern services: Differentiation between customer groups. This approach fits best in a middleware platform since it offers a homogeneous infrastructure for new services no matter how heterogeneous the telecom operator s infrastructure is. The procedure for a normal phone call is the best example for the advantage of quality of service in middleware: A whole line between the two partners is reserved no matter how much and often they speak. Of course, this assures the best possible quality of service but the telecom operator offers more bandwidth than the customer needs. A load depended use of the bandwidth would save resources without the customer even noticing. 3.3.2 Limitations of the traditional Approach The traditional approach was to include the quality of service in every service. So for every service and every operating system the calls and procedures had (and have) to be implemented over and over again. This is not only time consuming it also costs manpower and money. It even increases the susceptibility to errors because of the many different implementations for one quality of service. There are no standardised interfaces or development environments. With quality of service in a middleware platform and a standardised approach like MDA one has to make the concept (PIM) only once. The supporting tools and code generators would support the adoption to different hardware and operating systems (PSM) without a manual intervention. As a result, time to market for new services with quality of service is shortened, since implementation and testing time is reduced. In addition, the reusability is better, as the business logic has not to be changed when a new platform arises. Even the operation and management of quality of service services would be easier with a combined middleware and MDA approach: Centralised management and monitoring tools can be used since the standardised interfaces enable the inter-working of services from different vendors. These tools must not be written on ones own. The standardised APIs allow the use of off-the-shelf tools. But even if for some reasons these tools have to be written on its own it will be more simple than today: Services generated in a MDA way describe their interfaces clearly. So for the development of tools to support quality of service in a middleware platform MDA is the canonical way. 3.3.3 MDA Approach To solve the problem, the MDA modelling concepts have to be defined in terms of a MOF metamodel. Such modelling concepts normally include Contract Types, which are used to define the QoS properties of certain QoS categories. An example for a category is Availability, where an example for a property is the required uptime. Furthermore, the contract types have to be bound to contexts. A context is a part of the model where the bound contract might be subject for negotiation at runtime. Examples for such contexts are interfaces or operations. The concrete contexts depend on the available modelling concepts for the functional modelling of the system. An initial attempt to model these concepts might look like this: EDIN 0288-1149 2002 EURESCOM Participants in Project P1149

EURESCOM Project Report page 25 (38) Dimension ordering : Ordering unit : Unit DimensionBase name : String +dimension 1..n DimensionUnionMember label : Any +dimension 1..n +union 1 DimensionUnion +contract 1 +child 0..n ContractType generalization name : String +type 1 0..n +parent Context +context 1 +binding 0..n +binding Binding 0..n +binding 0..n <<enumeration>> Ordering DECREASING INCREASING <<enumeration>> Unit AMOUNT BYTE PERCENT MSEC +element 0..n InteractionElement The QoS contract metamodel has to address two key issues Allow the specification of contracts for every possible QoS category Define a binding that connects interfaces, methods and the like with contract types. The described attempt follows the approach of QML [1] and defines a contract type as a composition of dimensions. Therefore, the metaclasses Dimension and ContractType are introduced. Both are indirectly connected by a composition, which specifies that a ContractType is composed of an arbitrary number of Dimensions. A ContractType has one attribute called name. This attribute is used to store the name of the QoS category that is described by the contract type, i.e., Availability or Bandwidth. In addition, it is required that there must not exist two contract types with the same name in one namespace. The metaclass Generalisation allows to model multiple inheritances among contract types. One obvious constraint is that circular inheritance is forbidden. Specialisations of a contract type inherit all dimensions of its generalisations. As mentioned above, the QoS metamodel has to be integrated with modelling concepts for the modelling of functional aspects. One metamodel for that purpose is the CORBA Component Model (CCM). The CCM contains a Component Implementation Framework (CIF) that supports the designer by the provision of modelling support for the functional aspects of components. The CIF is defined in terms of a metamodel. This metamodel extends the basic IDL modelling capabilities by concepts, which allow to define component types who s instances interact via a set of well-defined interfaces. Such interfaces can be declared either as being provided or used by a certain component type. In the first case, the component types instance has the server role, whereas in the second case it has the client role. In addition to the operational interaction via (IDL-) interfaces components can interact asynchronously by exchanging events. To model a component based system with the above modelling concepts the metamodel is defined as an extension of the IDL metamodel. It is structured in packages as follows: 2002 EURESCOM Participants in Project P1149 EDIN 0288-1149