Project Report. Impacts of changes in enterprise software construction for telecommunications
|
|
- Arline Scott
- 6 years ago
- Views:
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
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 informationModel 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 informationExecutive 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 informationModel 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 informationFrom 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 informationAnalysis 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 informationApplication 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 informationModel 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)
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 informationMETADATA 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 informationAppendix 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 informationModel 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 informationSecond 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 informationOverview. 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 informationMDA-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 informationIMS 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 informationComputation 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 informationFIPA 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
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 informationDefining 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 informationDistributed 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 informationConverging 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 informationDistributed 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 informationDeveloping 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 informationTechnologies 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 informationThe 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 informationIntroduction. 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 informationService 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 informationQoS-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 informationSCOS-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 informationMiddleware. 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 informationThe 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 informationIssues 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 informationReal-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 informationObject 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 informationAn 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 informationThe 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 informationIncorporating 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 informationCisco 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 informationXML 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 informationWhite 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 information4.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 informationBeginning 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 informationEntireX 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 informationFrom 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 informationDeveloping 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 informationDeveloping 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 informationinnoq 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 informationThe 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 informationAgent-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 informationVoIP 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 informationDatabase 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 informationParlay 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 informationIBM 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 information1Z 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 informationObject-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 informationWBEM 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 informationIBM 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 informationConceptual 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 informationDS 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 informationCisco 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 informationUbiquitous 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 informationChapter 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 informationAll 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 informationMigration 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 informationAccelerate 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 informationControl 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 informationTelecommunication 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 informationThe 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 informationBest 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 informationPerformance 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 informationModel 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 informationTechnology 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 informationComponent-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 informationExperiences 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 informationThe 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 informationBLU 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 informationDistribution 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 informationOMG 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 informationFIPA 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 informationto 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
Enterprise Data using Grid Technology Kriangsak Tiawsirisup Sales Consulting Manager Oracle Corporation (Thailand) 3 Related Data Centre Trends. Service Oriented Architecture Flexibility
More informationOracle 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 informationCarlos 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 informationDistributed 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 informationIBM 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 informationA 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 informationMeltem Ö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 informationMDA 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 informationModel-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 informationFROM 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 informationASSURING 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 information1.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 informationSECURE 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 informationEntireX 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 informationWHITESTEIN. 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 informationChapter 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 informationAn 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 informationJAIN 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 informationTools 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