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

Size: px
Start display at page:

Download "Project Report. 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 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 Project P1149 For full publication March 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 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 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 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 EURESCOM Participants in Project P1149 EDIN

4 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 EURESCOM Participants in Project P1149

5 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

6 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 Introduction Two MDA Case Studies UBS Wells Fargo The Wells Fargo Processing Environment Model Driven Development MDA Provides a Bridge to the Future Examples from the telecom domain that can be improved by the application of MDA Telephony Networks Parlay / OSA IN -networks SIP-Network MDA Approach Evolution towards MDA for Telephony Networks Telecommunication Service Access and Subscription Description Traditional Approach Limitations of traditional Approach MDA Approach Evolution towards MDA for TSAS Quality of Service in a telecom middleware platform Description Limitations of the traditional Approach MDA Approach Evolution towards MDA for QoS MDA for Telecommunication Management Network Description Traditional Approach MDA approach for TMN Evolution towards MDA for TMN Necessary adaptations of MDA for application in the telecom operators domain Conclusion...37 References...38 EDIN EURESCOM Participants in Project P1149

7 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 EURESCOM Participants in Project P1149 EDIN

8 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 EURESCOM Participants in Project P1149

9 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 However, due to the current economic slowdown it is more realistic to assume $2,000 Million in From this whole market, MDA will probably capture 20% in 2005 and up to 50% in In numbers, this equals a total volume for MDA of $400 Mill in 2005 and $1.000 Million in 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 EURESCOM Participants in Project P1149 EDIN

10 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 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 EURESCOM Participants in Project P1149

11 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 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 EURESCOM Participants in Project P1149 EDIN

12 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 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 EURESCOM Participants in Project P1149

13 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 Parlay / OSA 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) EURESCOM Participants in Project P1149 EDIN

14 page 14 (38) 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 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 ( 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 ( 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 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 IN -networks Description Telenor have IN equipment from Ericsson as the main supplier, as shown in Figure 5. EDIN EURESCOM Participants in Project P1149

15 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 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 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 EURESCOM Participants in Project P1149 EDIN

16 page 16 (38) SIP-Network EURESCOM Project Report 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 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 EURESCOM Participants in Project P1149

17 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 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 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 EURESCOM Participants in Project P1149 EDIN

18 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 Evolution towards MDA for Telephony Networks 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 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 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 EURESCOM Participants in Project P1149

19 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 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

20 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 Limitations of traditional Approach The traditional way of the provision of the specification and the normal approach for its implementation contains several drawbacks: EDIN EURESCOM Participants in Project P1149

21 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 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

22 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 EURESCOM Participants in Project P1149

23 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 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 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

24 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 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 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 EURESCOM Participants in Project P1149

25 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

Impacts of changes in enterprise software construction for telecommunications

Impacts of changes in enterprise software construction for telecommunications 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

More information

Model Driven Architecture - The Vision

Model Driven Architecture - The Vision Model Driven Architecture - The Vision Marko Fabiunke Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik marko.fabiunke@first.fraunhofer.de The Fraunhofer FIRST Institut Your partner We support

More information

Executive Summary. Round Trip Engineering of Space Systems. Change Log. Executive Summary. Visas

Executive Summary. Round Trip Engineering of Space Systems. Change Log. Executive Summary. Visas Reference: egos-stu-rts-rp-1002 Page 1/7 Authors: Andrey Sadovykh (SOFTEAM) Contributors: Tom Ritter, Andreas Hoffmann, Jürgen Großmann (FHG), Alexander Vankov, Oleg Estekhin (GTI6) Visas Surname - Name

More information

Model Driven Architecture

Model Driven Architecture Model Driven Architecture Vision VS Reality EDOC 2001 September 4-7, Seattle, USA Sridhar Iyengar Unisys Fellow Member, OMG Architecture Board sridhar.iyengar2@unisys.com Slide 1 Model Driven Architecture

More information

From Models to Components. Rapid Service Creation with

From Models to Components. Rapid Service Creation with From Models to Components Rapid Service Creation with Marc Born, Olaf Kath {born kath}@ikv.de Evolutions in Software Construction C O M P L E X I T Y Model Driven Architectures Meta Object Facility and

More information

Analysis of Effectiveness of Open Service Architecture for Fixed and Mobile Convergence

Analysis of Effectiveness of Open Service Architecture for Fixed and Mobile Convergence Analysis of Effectiveness of Open Service Architecture for Fixed and Mobile Convergence Kyung-Hyu Lee* Jeung-Heon Hahn* Electronics and Telecommunications Research Institute* Email: {khyulee, stevehahn

More information

Application Servers in E-Commerce Applications

Application Servers in E-Commerce Applications Application Servers in E-Commerce Applications Péter Mileff 1, Károly Nehéz 2 1 PhD student, 2 PhD, Department of Information Engineering, University of Miskolc Abstract Nowadays there is a growing demand

More information

Model driven Engineering & Model driven Architecture

Model driven Engineering & Model driven Architecture Model driven Engineering & Model driven Architecture Prof. Dr. Mark van den Brand Software Engineering and Technology Faculteit Wiskunde en Informatica Technische Universiteit Eindhoven Model driven software

More information

(9A05803) WEB SERVICES (ELECTIVE - III)

(9A05803) WEB SERVICES (ELECTIVE - III) 1 UNIT III (9A05803) WEB SERVICES (ELECTIVE - III) Web services Architecture: web services architecture and its characteristics, core building blocks of web services, standards and technologies available

More information

METADATA INTERCHANGE IN SERVICE BASED ARCHITECTURE

METADATA INTERCHANGE IN SERVICE BASED ARCHITECTURE UDC:681.324 Review paper METADATA INTERCHANGE IN SERVICE BASED ARCHITECTURE Alma Butkovi Tomac Nagravision Kudelski group, Cheseaux / Lausanne alma.butkovictomac@nagra.com Dražen Tomac Cambridge Technology

More information

Appendix A - Glossary(of OO software term s)

Appendix A - Glossary(of OO software term s) Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component

More information

Model Driven Architecture Targets Middleware Interoperability Challenges

Model Driven Architecture Targets Middleware Interoperability Challenges Model Driven Architecture Targets Middleware Interoperability Challenges by Richard Soley Chairman and Chief Executive Officer Object Management Group and the OMG Staff Strategy Group "CORBA was a powerful

More information

Second OMG Workshop on Web Services Modeling. Easy Development of Scalable Web Services Based on Model-Driven Process Management

Second OMG Workshop on Web Services Modeling. Easy Development of Scalable Web Services Based on Model-Driven Process Management Second OMG Workshop on Web Services Modeling Easy Development of Scalable Web Services Based on Model-Driven Process Management 88 solutions Chief Technology Officer 2003 Outline! Introduction to Web Services!

More information

Overview. Distributed Systems. Distributed Software Architecture Using Middleware. Components of a system are not always held on the same host

Overview. Distributed Systems. Distributed Software Architecture Using Middleware. Components of a system are not always held on the same host Distributed Software Architecture Using Middleware Mitul Patel 1 Overview Distributed Systems Middleware What is it? Why do we need it? Types of Middleware Example Summary 2 Distributed Systems Components

More information

MDA-based Service Creation for OSA/Parlay within 3Gbeyond Environments

MDA-based Service Creation for OSA/Parlay within 3Gbeyond Environments MDA-based Service Creation for OSA/Parlay within 3Gbeyond Environments Thomas Magedanz 1, Karsten Knüttel 1, Olaf Kath 2 1 TU Berlin/FhG FOKUS 2 TU Berlin/IKV ++ Technologies AG { magedanz, knüttel }@fokus.fraunhofer.de,

More information

IMS Adoption Fueled by the Open IMS Core Project and MySQL

IMS Adoption Fueled by the Open IMS Core Project and MySQL IMS Adoption Fueled by the Open IMS Core Project and MySQL Overview The project was launched in 2006 to promote IMS (IP Multimedia Subsystem) technology adoption in next-generation telecommunications networks,

More information

Computation Independent Model (CIM): Platform Independent Model (PIM): Platform Specific Model (PSM): Implementation Specific Model (ISM):

Computation Independent Model (CIM): Platform Independent Model (PIM): Platform Specific Model (PSM): Implementation Specific Model (ISM): viii Preface The software industry has evolved to tackle new approaches aligned with the Internet, object-orientation, distributed components and new platforms. However, the majority of the large information

More information

FIPA Agent Software Integration Specification

FIPA Agent Software Integration Specification FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS FIPA Agent Software Integration Specification Document title FIPA Agent Software Integration Specification Document number XC00079A Document source FIPA Architecture

More information

* Corresponding Author

* Corresponding Author A Model Driven Architecture for REA based systems Signe Ellegaard Borch, Jacob Winther Jespersen, Jesper Linvald, Kasper Østerbye* IT University of Copenhagen, Denmark * Corresponding Author (kasper@it-c.dk)

More information

Defining Generic Architectural Requirements for the Service Delivery Platform

Defining Generic Architectural Requirements for the Service Delivery Platform Defining Generic Architectural Requirements for the Service Delivery Platform Rolan Christian and Hu Hanrahan Centre for Telecommunications Access and Services 1 School of Electrical and Information Engineering

More information

Distributed systems. Distributed Systems Architectures. System types. Objectives. Distributed system characteristics.

Distributed systems. Distributed Systems Architectures. System types. Objectives. Distributed system characteristics. Distributed systems Distributed Systems Architectures Virtually all large computer-based systems are now distributed systems. Information processing is distributed over several computers rather than confined

More information

Converging towards Service Centric Networks: Requirements for a Service Delivery Platform Framework

Converging towards Service Centric Networks: Requirements for a Service Delivery Platform Framework Converging towards Centric Networks: Requirements for a Delivery Platform Framework Rolan Christian and Hu Hanrahan Centre for Telecommunications Access and s 1 School of Electrical and Information Engineering

More information

Distributed Systems Architectures. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 12 Slide 1

Distributed Systems Architectures. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 12 Slide 1 Distributed Systems Architectures Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 12 Slide 1 Objectives To explain the advantages and disadvantages of different distributed systems architectures

More information

Developing in OMG s Model-Driven Architecture

Developing in OMG s Model-Driven Architecture Developing in OMG s Model-Driven Architecture Jon Siegel and the OMG Staff Strategy Group Object Management Group White Paper November, 2001 Revision 2.6 In an accompanying white paper 1, the Object Management

More information

Technologies and Guidelines for Service Creation in NGN

Technologies and Guidelines for Service Creation in NGN http://exp.telecomitalialab.com Technologies and Guidelines for Service Creation in NGN P. Falcarin, C. A. Licciardi ABSTRACT - NETWORK OPERATORS CAN SEE NEXT GENERATION NETWORKS (NGN) AS NEW REVENUE STREAM

More information

The Specifications Exchange Service of an RM-ODP Framework

The Specifications Exchange Service of an RM-ODP Framework The Specifications Exchange Service of an RM-ODP Framework X. Blanc (*+), M-P. Gervais(*), J. Le Delliou(+) (*)Laboratoire d'informatique de Paris 6-8 rue du Capitaine Scott F75015 PARIS (+)EDF Research

More information

Introduction. Enterprise Java Instructor: Please introduce yourself Name Experience in Java Enterprise Edition Goals you hope to achieve

Introduction. Enterprise Java Instructor: Please introduce yourself Name Experience in Java Enterprise Edition Goals you hope to achieve Enterprise Java Introduction Enterprise Java Instructor: Please introduce yourself Name Experience in Java Enterprise Edition Goals you hope to achieve Course Description This course focuses on developing

More information

Service Architecture for 3rd Party Operator s Participation

Service Architecture for 3rd Party Operator s Participation Service Architecture for 3rd Party Operator s Participation F. Sarabchi, A. H. Darvishan, H. Yeganeh, and H. Ahmadian Abstract Next generation networks with the idea of convergence of service and control

More information

QoS-aware model-driven SOA using SoaML

QoS-aware model-driven SOA using SoaML QoS-aware model-driven SOA using SoaML Niels Schot A thesis submitted for the degree of MSc Computer Science University of Twente EEMCS - TRESE: Software Engineering Group Examination committee: Luís Ferreira

More information

SCOS-2000 Technical Note

SCOS-2000 Technical Note SCOS-2000 Technical Note MDA Study Prototyping Technical Note Document Reference: Document Status: Issue 1.0 Prepared By: Eugenio Zanatta MDA Study Prototyping Page: 2 Action Name Date Signature Prepared

More information

Middleware. Adapted from Alonso, Casati, Kuno, Machiraju Web Services Springer 2004

Middleware. Adapted from Alonso, Casati, Kuno, Machiraju Web Services Springer 2004 Middleware Adapted from Alonso, Casati, Kuno, Machiraju Web Services Springer 2004 Outline Web Services Goals Where do they come from? Understanding middleware Middleware as infrastructure Communication

More information

The Open Application Platform for Secure Elements.

The Open Application Platform for Secure Elements. The Open Application Platform for Secure Elements. Java Card enables secure elements, such as smart cards and other tamper-resistant security chips, to host applications, called applets, which employ Java

More information

Issues surrounding model consistency and QVT

Issues surrounding model consistency and QVT Issues surrounding model consistency and QVT Laurence Tratt, Tony Clark laurie@tratt.net, anclark@dcs.kcl.ac.uk December 6, 200. Introduction This document is intended to outline some of the issues surrounding

More information

Real-time Communications Security and SDN

Real-time Communications Security and SDN Real-time Communications Security and SDN 2016 [Type here] Securing the new generation of communications applications, those delivering real-time services including voice, video and Instant Messaging,

More information

Object Security. Model Driven Security. Ulrich Lang, Rudolf Schreiner. Protection of Resources in Complex Distributed Systems

Object Security. Model Driven Security. Ulrich Lang, Rudolf Schreiner. Protection of Resources in Complex Distributed Systems Object Security TM The Security Policy Company Protection of Resources in Complex Distributed Systems Ulrich Lang, Rudolf Schreiner ObjectSecurity Ltd. University of Cambridge Agenda COACH Project Model

More information

An introduction to MOF MetaObject Facility.

An introduction to MOF MetaObject Facility. An introduction to MOF MetaObject Facility pierre-alain.muller@irisa.fr About The MetaObject Facility Specification is the foundation of OMG's industry-standard standard environment where models can be

More information

The Unified Modelling Language. Example Diagrams. Notation vs. Methodology. UML and Meta Modelling

The Unified Modelling Language. Example Diagrams. Notation vs. Methodology. UML and Meta Modelling UML and Meta ling Topics: UML as an example visual notation The UML meta model and the concept of meta modelling Driven Architecture and model engineering The AndroMDA open source project Applying cognitive

More information

Incorporating applications to a Service Oriented Architecture

Incorporating applications to a Service Oriented Architecture Proceedings of the 5th WSEAS Int. Conf. on System Science and Simulation in Engineering, Tenerife, Canary Islands, Spain, December 16-18, 2006 401 Incorporating applications to a Service Oriented Architecture

More information

Cisco Unified Presence 8.0

Cisco Unified Presence 8.0 Cisco Unified Presence 8.0 Cisco Unified Communications Solutions unify voice, video, data, and mobile applications on fixed and mobile networks, enabling easy collaboration every time from any workspace.

More information

XML in the bipharmaceutical

XML in the bipharmaceutical XML in the bipharmaceutical sector XML holds out the opportunity to integrate data across both the enterprise and the network of biopharmaceutical alliances - with little technological dislocation and

More information

White Paper Subcategory. Overview of XML Communication Technologies

White Paper Subcategory. Overview of XML Communication Technologies Subcategory Overview of XML Communication Technologies Executive Summary A significant shift has occurred in the communications infrastructures deployed today. This shift is the result of the acceptance

More information

4.2 IMS Service Creation

4.2 IMS Service Creation 4.2 IMS Service Creation 63 IMS service layer application servers IMS basic telephony Simulation servers Subscriber data HSS -AS #1 -AS #2 MMTel application servers Cx IP access network Gm P-CSCF Mw S-CSCF

More information

Beginning To Define ebxml Initial Draft

Beginning To Define ebxml Initial Draft Beginning To Define ebxml Initial Draft File Name Version BeginningToDefineebXML 1 Abstract This document provides a visual representation of how the ebxml Architecture could work. As ebxml evolves, this

More information

EntireX Highlights of new Features

EntireX Highlights of new Features EntireX 7.3 - Highlights of new Features Crossvision Product Management Software AG EntireX 7.3 Highlights March 2007 Seite 1 EntireX Key Enhancements Key Enhancement areas CentraSite EntireX Workbench

More information

From Object Composition to Model Transformation with the MDA

From Object Composition to Model Transformation with the MDA From Object Composition to Transformation with the MDA Jean Bézivin University of Nantes 2, rue de la Houssinière, BP 92208 44322 Nantes cedex 3, France Jean.Bezivin@sciences.univ-nantes.fr Abstract The

More information

Developing Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach

Developing Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach Developing Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach Ninat Wanapan and Somnuk Keretho Department of Computer Engineering, Kasetsart

More information

Developing Java TM 2 Platform, Enterprise Edition (J2EE TM ) Compatible Applications Roles-based Training for Rapid Implementation

Developing Java TM 2 Platform, Enterprise Edition (J2EE TM ) Compatible Applications Roles-based Training for Rapid Implementation Developing Java TM 2 Platform, Enterprise Edition (J2EE TM ) Compatible Applications Roles-based Training for Rapid Implementation By the Sun Educational Services Java Technology Team January, 2001 Copyright

More information

innoq Deutschland GmbH innoq Schweiz GmbH D Ratingen CH-6330 Cham Tel Tel

innoq Deutschland GmbH innoq Schweiz GmbH D Ratingen CH-6330 Cham Tel Tel innoq Deutschland GmbH innoq Schweiz GmbH D-40880 Ratingen CH-6330 Cham Tel +49 2102 77 1620 Tel +41 41 743 01 11 www.innoq.com Stefan Tilkov, stefan.tilkov@innoq.com 1 Goals Introduce MDE, MDA, MDD, MDSD,...

More information

The Model-Driven Semantic Web Emerging Standards & Technologies

The Model-Driven Semantic Web Emerging Standards & Technologies The Model-Driven Semantic Web Emerging Standards & Technologies Elisa Kendall Sandpiper Software March 24, 2005 1 Model Driven Architecture (MDA ) Insulates business applications from technology evolution,

More information

Agent-Enabling Transformation of E-Commerce Portals with Web Services

Agent-Enabling Transformation of E-Commerce Portals with Web Services Agent-Enabling Transformation of E-Commerce Portals with Web Services Dr. David B. Ulmer CTO Sotheby s New York, NY 10021, USA Dr. Lixin Tao Professor Pace University Pleasantville, NY 10570, USA Abstract:

More information

VoIP Core Technologies. Aarti Iyengar Apricot 2004

VoIP Core Technologies. Aarti Iyengar Apricot 2004 VoIP Core Technologies Aarti Iyengar Apricot 2004 Copyright 2004 Table Of Contents What is Internet Telephony or Voice over IP? VoIP Network Paradigms Key VoIP Protocols Call Control and Signaling protocols

More information

Database code in PL-SQL PL-SQL was used for the database code. It is ready to use on any Oracle platform, running under Linux, Windows or Solaris.

Database code in PL-SQL PL-SQL was used for the database code. It is ready to use on any Oracle platform, running under Linux, Windows or Solaris. Alkindi Software Technology Introduction Alkindi designed a state of the art collaborative filtering system to work well for both largeand small-scale systems. This document serves as an overview of how

More information

Parlay Service Access Architecture

Parlay Service Access Architecture Parlay Service Access Architecture Approved Version 1.0 27 Apr 2010 Open Mobile Alliance OMA-AD-Parlay_Service_Access-V1_0-20100427-A OMA-AD-Parlay_Service_Access-V1_0-20100427-A Page 2 (10) Use of this

More information

IBM Rational Developer for System z Version 7.5

IBM Rational Developer for System z Version 7.5 Providing System z developers with tools for building traditional and composite applications in an SOA and Web 2.0 environment IBM Rational Developer for System z Version 7.5 Highlights Helps developers

More information

1Z Oracle. Java Enterprise Edition 5 Enterprise Architect Certified Master

1Z Oracle. Java Enterprise Edition 5 Enterprise Architect Certified Master Oracle 1Z0-864 Java Enterprise Edition 5 Enterprise Architect Certified Master Download Full Version : http://killexams.com/pass4sure/exam-detail/1z0-864 Answer: A, C QUESTION: 226 Your company is bidding

More information

Object-Oriented Middleware for Distributed Systems

Object-Oriented Middleware for Distributed Systems Object-Oriented Middleware for Distributed Systems Distributed Systems Sistemi Distribuiti Andrea Omicini andrea.omicini@unibo.it Ingegneria Due Alma Mater Studiorum Università di Bologna a Cesena Academic

More information

WBEM Web-based Enterprise Management

WBEM Web-based Enterprise Management 1 WBEM Web-based Enterprise Management Outline What is Enterprise Management? What are the drivers in Enterprise Mgt.? Distributed Management Technology Forum (DMTF) Web Based Enterprise Management (WBEM)

More information

IBM Rational Application Developer for WebSphere Software, Version 7.0

IBM Rational Application Developer for WebSphere Software, Version 7.0 Visual application development for J2EE, Web, Web services and portal applications IBM Rational Application Developer for WebSphere Software, Version 7.0 Enables installation of only the features you need

More information

Conceptual Modeling and Specification Generation for B2B Business Processes based on ebxml

Conceptual Modeling and Specification Generation for B2B Business Processes based on ebxml Conceptual Modeling and Specification Generation for B2B Business Processes based on ebxml HyoungDo Kim Professional Graduate School of Information and Communication, Ajou University 526, 5Ga, NamDaeMoonRo,

More information

DS 2009: middleware. David Evans

DS 2009: middleware. David Evans DS 2009: middleware David Evans de239@cl.cam.ac.uk What is middleware? distributed applications middleware remote calls, method invocations, messages,... OS comms. interface sockets, IP,... layer between

More information

Cisco Application Policy Infrastructure Controller Data Center Policy Model

Cisco Application Policy Infrastructure Controller Data Center Policy Model White Paper Cisco Application Policy Infrastructure Controller Data Center Policy Model This paper examines the Cisco Application Centric Infrastructure (ACI) approach to modeling business applications

More information

Ubiquitous Access to Personalised Services

Ubiquitous Access to Personalised Services Ubiquitous Access to Personalised Services 1 Tore E. J{lSnvik, 2 Anne Marie Hartvigsen & 3 Do van Thanh 1. Unik - University of Oslo - Norway - tif: +4790199176 - torejoen@iji.uio.no 2. AgderUniversity

More information

Chapter 1 GETTING STARTED. SYS-ED/ Computer Education Techniques, Inc.

Chapter 1 GETTING STARTED. SYS-ED/ Computer Education Techniques, Inc. Chapter 1 GETTING STARTED SYS-ED/ Computer Education Techniques, Inc. Objectives You will learn: The IDE: Integrated Development Environment. MVC: Model-View-Controller Architecture. BC4J: Business Components

More information

All you need are models Anneke Kleppe, Klasse Objecten

All you need are models Anneke Kleppe, Klasse Objecten Model Driven Architecture All you need are models Anneke Kleppe, Klasse Objecten Contents Limited Vision on MDA Modeling Maturity Levels Models Model Driven Development Model Driven Architecture MDA in

More information

Migration to Service Oriented Architecture Using Web Services Whitepaper

Migration to Service Oriented Architecture Using Web Services Whitepaper WHITE PAPER Migration to Service Oriented Architecture Using Web Services Whitepaper Copyright 2004-2006, HCL Technologies Limited All Rights Reserved. cross platform GUI for web services Table of Contents

More information

Accelerate Your Enterprise Private Cloud Initiative

Accelerate Your Enterprise Private Cloud Initiative Cisco Cloud Comprehensive, enterprise cloud enablement services help you realize a secure, agile, and highly automated infrastructure-as-a-service (IaaS) environment for cost-effective, rapid IT service

More information

Control and Management of Home Networks Using a CORBA Enabled Residential Gateway

Control and Management of Home Networks Using a CORBA Enabled Residential Gateway Control and Management of Home Networks Using a CORBA Enabled Residential Y.C. Shou 1, R. Prasad, S. Mohapi and H.E. Hanrahan Centre for Telecommunications Access and Services School of Electrical and

More information

Telecommunication Services Engineering Lab. Roch H. Glitho

Telecommunication Services Engineering Lab. Roch H. Glitho 1 Introduction Signaling protocol neutral service engineering technology Service architecture applicable to NGNs using any signalling protocol Next Generation signalling protocols SIP H.323 Example already

More information

The Migration to Ipv6

The Migration to Ipv6 GSM Europe The European interest group of the GSM Association http://gsmeurope.gsmworld.com The Migration to Ipv6 GSM Europe Policy Statement for the IPv6 Task Force- GSME, 6 August 2001 1. Background

More information

Best Practices for Deploying Web Services via Integration

Best Practices for Deploying Web Services via Integration Tactical Guidelines, M. Pezzini Research Note 23 September 2002 Best Practices for Deploying Web Services via Integration Web services can assemble application logic into coarsegrained business services.

More information

Performance Evaluation of Telephony Routing over IP (TRIP)

Performance Evaluation of Telephony Routing over IP (TRIP) Performance Evaluation of Telephony Routing over IP (TRIP) Matthew C. Schlesener Master s Thesis Defense November 25, 2002 Defense Committee: Dr. Victor Frost (Chair) Dr. Joseph Evans Dr. Gary Minden Presentation

More information

Model Driven Architecture and Rhapsody

Model Driven Architecture and Rhapsody Model Driven Architecture and Rhapsody Dr. Bruce Powel Douglass Chief Evangelist Telelogic Model Driven Architecture and Rhapsody Abstract MDA, short for Model Driven Architecture, is a unification by

More information

Technology Assessment of Middleware for Telecommunications

Technology Assessment of Middleware for Telecommunications Project Report Technology Assessment of Middleware for Telecommunications Telecommunication Application Domains Editor: Peter Loosemore, BT British Telecommunications plc Abstract This document details

More information

Component-based Architecture Buy, don t build Fred Broks

Component-based Architecture Buy, don t build Fred Broks Component-based Architecture Buy, don t build Fred Broks 1. Why use components?... 2 2. What are software components?... 3 3. Component-based Systems: A Reality!! [SEI reference]... 4 4. Major elements

More information

Experiences in the management of an EJB-based e- commerce application. Abstract

Experiences in the management of an EJB-based e- commerce application. Abstract Experiences in the management of an EJB-based e- commerce application Juan I. Asensio, Víctor A. Villagrá, Jorge E. López de Vergara, Roney Pignaton, Julio J. Berrocal. Department of Telematic Systems

More information

The Eclipse Modeling Framework and MDA Status and Opportunities

The Eclipse Modeling Framework and MDA Status and Opportunities The Eclipse Modeling Framework and MDA Status and Opportunities David Frankel Consulting df@davidfrankelconsulting.com www.davidfrankelconsulting.com Portions adapted from the book Model Driven Architecture:

More information

BLU AGE 2009 Edition Agile Model Transformation

BLU AGE 2009 Edition Agile Model Transformation BLU AGE 2009 Edition Agile Model Transformation Model Driven Modernization for Legacy Systems 1 2009 NETFECTIVE TECHNOLOGY -ne peut être copiésans BLU AGE Agile Model Transformation Agenda Model transformation

More information

Distribution and web services

Distribution and web services Chair of Software Engineering Carlo A. Furia, Bertrand Meyer Distribution and web services From concurrent to distributed systems Node configuration Multiprocessor Multicomputer Distributed system CPU

More information

OMG Specifications for Enterprise Interoperability

OMG Specifications for Enterprise Interoperability OMG Specifications for Enterprise Interoperability Brian Elvesæter* Arne-Jørgen Berre* *SINTEF ICT, P. O. Box 124 Blindern, N-0314 Oslo, Norway brian.elvesater@sintef.no arne.j.berre@sintef.no ABSTRACT:

More information

FIPA Agent Management Support for Mobility Specification

FIPA Agent Management Support for Mobility Specification 1 2 3 4 5 6 FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS FIPA Management Support for Mobility Specification 7 8 Document title FIPA Management Support for Mobility Specification Document number PC000087B

More information

to pay for it) has been waning. The Internet further changed the game.

to pay for it) has been waning. The Internet further changed the game. As the old telephone business models break down and new service paradigm takes over, communication companies must combine voice with the new services of the network. The SCI-Platform (Service Convergence

More information

<Insert Picture Here> Enterprise Data Management using Grid Technology

<Insert Picture Here> Enterprise Data Management using Grid Technology Enterprise Data using Grid Technology Kriangsak Tiawsirisup Sales Consulting Manager Oracle Corporation (Thailand) 3 Related Data Centre Trends. Service Oriented Architecture Flexibility

More information

Oracle Communications Diameter Signaling Router

Oracle Communications Diameter Signaling Router Oracle Communications Diameter Signaling Router Centralizing Diameter routing with cloud deployable Oracle Communications Diameter Signaling Router creates a secure signaling architecture that reduces

More information

Carlos Samitier Joaquin Luque Fernando Gonzalo DIMAT S.A. Manuel Mejías Grupo Endesa Spain Universidad de Sevilla (Spain) Spain

Carlos Samitier Joaquin Luque Fernando Gonzalo DIMAT S.A. Manuel Mejías Grupo Endesa Spain Universidad de Sevilla (Spain) Spain Carlos Samitier Joaquin Luque Fernando Gonzalo DIMAT S.A. Manuel Mejías Grupo Endesa Spain Universidad de Sevilla (Spain) Spain NETWORK MANAGEMENT ARCHITECTURE FOR POWER UTILITY NETWORKS ABSTRACT Telecommunication

More information

Distributed Objects. Object-Oriented Application Development

Distributed Objects. Object-Oriented Application Development Distributed s -Oriented Application Development Procedural (non-object oriented) development Data: variables Behavior: procedures, subroutines, functions Languages: C, COBOL, Pascal Structured Programming

More information

IBM Rational Software Architect

IBM Rational Software Architect Unifying all aspects of software design and development IBM Rational Software Architect A complete design & development toolset Incorporates all the capabilities in IBM Rational Application Developer for

More information

A MODEL FOR INTERCONNECTION IN IP-BASED NETWORKS

A MODEL FOR INTERCONNECTION IN IP-BASED NETWORKS Electronic Communications Committee (ECC) within the European Conference of Postal and Telecommunications Administrations (CEPT) A MODEL FOR INTERCONNECTION IN IP-BASED NETWORKS Vilnius, October 2005 Page

More information

Meltem Özturan misprivate.boun.edu.tr/ozturan/mis515

Meltem Özturan misprivate.boun.edu.tr/ozturan/mis515 Meltem Özturan misprivate.boun.edu.tr/ozturan/mis515 1 2 1 Selecting the Best Alternative Major Activities in the Analysis Phase Gather information Define system requirements Prototype for feasibility

More information

MDA and Integration of Legacy Systems: An Industrial Case Study

MDA and Integration of Legacy Systems: An Industrial Case Study MDA and Integration of Legacy Systems: An Industrial Case Study Parastoo Mohagheghi 1, Jan Pettersen Nytun 2, Selo 2, Warsun Najib 2 1 Ericson Norway-Grimstad, Postuttak, N-4898, Grimstad, Norway 1 Department

More information

Model-Based Social Networking Over Femtocell Environments

Model-Based Social Networking Over Femtocell Environments Proc. of World Cong. on Multimedia and Computer Science Model-Based Social Networking Over Femtocell Environments 1 Hajer Berhouma, 2 Kaouthar Sethom Ben Reguiga 1 ESPRIT, Institute of Engineering, Tunis,

More information

FROM A RIGID ECOSYSTEM TO A LOGICAL AND FLEXIBLE ENTITY: THE SOFTWARE- DEFINED DATA CENTRE

FROM A RIGID ECOSYSTEM TO A LOGICAL AND FLEXIBLE ENTITY: THE SOFTWARE- DEFINED DATA CENTRE FROM A RIGID ECOSYSTEM TO A LOGICAL AND FLEXIBLE ENTITY: THE SOFTWARE- DEFINED DATA CENTRE The demand for cloud infrastructure is rapidly increasing, the world of information is becoming application and

More information

ASSURING DATA INTEROPERABILITY THROUGH THE USE OF FORMAL MODELS OF VISA PAYMENT MESSAGES (Category: Practice-Oriented Paper)

ASSURING DATA INTEROPERABILITY THROUGH THE USE OF FORMAL MODELS OF VISA PAYMENT MESSAGES (Category: Practice-Oriented Paper) ASSURING DATA INTEROPERABILITY THROUGH THE USE OF FORMAL MODELS OF VISA PAYMENT MESSAGES (Category: Practice-Oriented Paper) Joseph Bugajski Visa International JBugajsk@visa.com Philippe De Smedt Visa

More information

1.264 Lecture 16. Legacy Middleware

1.264 Lecture 16. Legacy Middleware 1.264 Lecture 16 Legacy Middleware What is legacy middleware? Client (user interface, local application) Client (user interface, local application) How do we connect clients and servers? Middleware Network

More information

SECURE INFORMATION EXCHANGE: REFERENCE ARCHITECTURE

SECURE INFORMATION EXCHANGE: REFERENCE ARCHITECTURE SECURE INFORMATION EXCHANGE: REFERENCE ARCHITECTURE MAY 2017 A NEXOR WHITE PAPER NEXOR 2017 ALL RIGHTS RESERVED CONTENTS 3 4 5 6 8 9 10 11 12 14 15 16 INTRODUCTION THREATS RISK MITIGATION REFERENCE ARCHITECTURE

More information

EntireX Modernized EntireX Workbench

EntireX Modernized EntireX Workbench EntireX 7.3 - Modernized EntireX Workbench Crossvision Product Management Software AG EntireX 7.3 Workbench April 2007 Seite 1 Modernized EntireX Workbench With EntireX 7.3 the EntireX Workbench will be

More information

WHITESTEIN. Agents in a J2EE World. Technologies. Stefan Brantschen. All rights reserved.

WHITESTEIN. Agents in a J2EE World. Technologies. Stefan Brantschen. All rights reserved. WHITESTEIN Technologies 1 Agents in a J2EE World Stefan Brantschen ttt.info.j2ee v1.6 2002-02-10 SBR Copyright 2002 by Whitestein Technologies AG, Switzerland Goal and Outline Goal Present how J2EE EJB

More information

Chapter 18. Software Reuse

Chapter 18. Software Reuse Chapter 18 Software Reuse Ian Sommerville Lutz Prechelt Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 1 Objectives To explain the benefits of software reuse and some

More information

An Approach to Software Component Specification

An Approach to Software Component Specification Page 1 of 5 An Approach to Software Component Specification Jun Han Peninsula School of Computing and Information Technology Monash University, Melbourne, Australia Abstract. Current models for software

More information

JAIN TM and Open Networks

JAIN TM and Open Networks JAIN TM and Open Networks A white paper describing the positioning of the JAIN Application Programming Interfaces (APIs) within open network architectures August 2003 http://java.sun.com/products/jain

More information

Tools to Develop New Linux Applications

Tools to Develop New Linux Applications Tools to Develop New Linux Applications IBM Software Development Platform Tools for every member of the Development Team Supports best practices in Software Development Analyst Architect Developer Tester

More information