ational support systems (OSS), increase agility, and design the OSS infrastructure to ..... activation, trouble ticket, billing, QoS, inventory, SLA management, etc).
Model-driven systems development and integration environment M Azmoodeh, N Georgalas and S Fisher
Telecommunications operators are undergoing massive transformations in order to metamorphose themselves into the ICT world and compete with agile, lean IT organisations. The main challenges facing telecommunications operators, such as BT, are to reduce costs and increase agility in deploying software systems for provisioning ICT services. Despite using reusable capabilities and COTS packages, the major source of increased cost lies in the heavy integration tax we incur for integrating diverse systems implemented on diverse platforms and middleware, with heterogeneous data and process models. This paper looks at cost implications of lengthy and often manual migration to-and-from systems and platforms, and shows the clear business benefits of model-driven development (MDD) as defined by the Object Management Group (OMG). It is clearly demonstrated that model-driven development has matured into a practical, industrialised, scalable and evolvable technology, culminating from decades of R&D on specification and design languages, executable formalisms and domainspecific languages and language transformations.
1.
Introduction
Telecommunications operators are undergoing massive transformations in order to move into the ICT world and compete with agile, lean IT organisations. Some of their main challenges are to reduce the costs of their IT operational support systems (OSS), increase agility, and design the OSS infrastructure to cover the IT and communications estate. A major contributing factor in the cost of running OSS systems is integration tax, which is incurred when we integrate COTS and other legacy OSS systems together. These stem from the multiplicity of platforms and middleware we use — often point-topoint integration of these systems and lack of standards in both APIs for OSS capabilities as well as data models used by various systems to represent OSS data. Although some advances are being made by the OSS industry towards standardising OSS capabilities and data models, through the OSS/J initiative [1] and the TeleManagement Forum [2], systems are still designed around specific middleware technologies such as CORBA, J2EE, and .NET. Heavy migration costs are also incurred in porting to new versions of such platforms. This paper focuses on using the model-driven architecture (MDA) technology of the OMG in conjunction with other approaches, such as use of component-based next generation OSS [3] and OSS through Java (OSS/J) standards, to drastically tackle the issues of cost and time to market for OSS solutions. We have created a vision (see Fig 1) of an OSS integration 96
BT Technology Journal • Vol 23 No 3 • July 2005
environment where all designers and architects in the company can develop/integrate/reuse OSS capabilities through automated tool support in a technology-neutral environment using MDA technology. Thus, we will safeguard our intellectual property assets and create coherence in our OSS infrastructure as new technologies are introduced or requirements for OSS functionality changes. This is in contrast to the stovepipe solution approach we currently deploy. An MDA approach will also allow us to achieve a much greater BT business processes
BT common model-driven solution design environment
BT standard GUI
standard API
COTS component (application logic/data)
standard infrastructure (security, persistence, transactions, ..)
Fig 1 Vision of a technology-independent solution design environment supported by a standard component-based architecture.
Model-driven systems development and integration environment
level of reuse of all our artefacts in the OSS development life cycle, from capability and integration logic specifications, to implementation and deployment artefacts, all achieved through consistent meta-data repositories. BT has already recognised the value of a componentised capability-based approach in its network and system transformation programme. We believe the next major step in its effective realisation will come from using MDA to capture architectural and design guidelines, and to automatically generate/ integrate OSS capabilities into existing application infrastructures, without the need to delve into the technological and platform details of the multiple systems and middleware we use. Tackling these problems by means of MDA involves the specification of systems (capabilities, integration logic, business rules, etc) as high-level businessoriented abstract models. These models hide implementation and middleware details which are not needed by business-focused architects and designers. In MDA parlance, these are described as computationally independent models (CIMs) and platform independent models (PIMs). CIMs predominantly describe business processes, data objects and business requirements. PIMs describe the computational objects, which realise the business models. These models are not merely abstract structural descriptions of these domains (as we employ in current UML models), but they contain behavioural descriptions (such as constraints, business operations, etc) to the degree that the models can be executable, if needed. This powerful feature allows models to be validated against user requirements, before even code development commences, and hence improves the quality of software subsequently generated. Furthermore, MDA provides standards and automated tools for representing transformations from these PIMs into platform specific models (PSMs) as well as the necessary bridges to interconnect components running over different middleware platforms. Technologies have existed in the past to enable such a development process; however, with the powerful meta-modelling proposed by MDA, we can define domain specific languages (DSLs) for modelling all systems’ artefacts, specifically geared towards various facets of OSS design in a large telco environment. This implies that we are not bound to use one modelling language such as UML for all purposes in the company, but we can define multiple modelling languages suited for our various domains in the company. The metamodelling facility of MDA enables us to define such domain- specific languages and more importantly generate language-specific tools for defining models and transforming them to implementations of our
choice. Once generation of these tools is under our control, we can embody our own best practice modelling guidelines, architectural principles and coding guidelines in an automated environment. This allows all models developed in the company to be validated against company-wide architectural guidelines, and hence ensure true reuse and interoperability of OSS capabilities. This paper outlines our vision of BT designing its OSS components as high-level semantically rich models (using domain-specific UML languages enriched with precise semantics using MDA standards) with automated tool support to map these into platformspecific solutions, thus reducing time to market as well as ensuring longevity of our OSS solution designs. Other papers describe our earlier work [4—7]. We have already built a proof of concept demonstration of an inventory OSS application based on OSS/J interface standard specifications. We have also built an OSS test bed based on OSS/J components, with the integration logic autogenerated using MDA tools. We have used an advanced meta-modelling tool from Xactium [8] to model our integration case studies from which J2EE models and code are automatically generated and deployed. BT business units are also beginning to consider MDA technology in various forms to overcome the shortcomings of traditional UML modelling. An early case study for automatic translation of OSS information models is reported later in section 5. The main thrust of business units’ focus on MDA can be summarised as:
•
more precise behaviour specification in models,
•
potential reuse of models and their transforms,
•
reduce cost by defining transformations from model to model/code once,
•
own the description of modelling languages and model transformations, thus providing an ability to adapt the languages to domain-specific needs,
•
less reliance on vendors’ tools and language support.
The structure of the paper is as follows. Section 2 briefly describes the current state of BT systems. Section 3 introduces the fundamental concepts of MDA, its standards and tools, and their industrial take-up. Section 4 describes TMF’s new generation operations, systems and software (NGOSS) and OSS/J, and their relationship to an MDA approach. Section 5 describes the current MDA activities in BT, within both research and development units. Finally section 6 discusses lessons learned and our future research work. BT Technology Journal • Vol 23 No 3 • July 2005
97
Model-driven systems development and integration environment
2.
Current BT OSS
BT currently has many hundreds of operational support systems, with over hundreds of million pounds spend per annum on OSS. As we move towards a more dynamic ICT enterprise, these costs are bound to increase. One of the major contributing costs of our OSS estate stems from the complexity of these systems, the often point-to-point integration used, and the various middleware and integration technologies. It is recognised that up to 90% [9] of the total cost is in maintenance and integration of our OSS capabilities. BT has already undertaken a massive initiative in using a unified approach to requirements capture, system and component design, and centralised model repository management using Borland UML modelling tool-kits. In the face of rapid service launches, it is increasingly recognised that modelling itself is not sufficient to guarantee quality, development speed and reuse of software. There are still, mainly manual, costly operations in moving from requirements for new/ existing system capabilities to putting working operational systems in place. At the heart of modelling activities lies the problem of lack of precision in these models so that the resulting specifications become open to interpretation and hence lead to poor interoperability between different teams and organisational boundaries. Also, this leaves many significant design decisions to be taken by developers which are not reflected in the design nor are they checked for consistency and completeness. Another relevant and very important factor of the approach taken by BT is the use of commercial-off-theshelf (COTS) packages, as opposed to in-house development of software systems. Although such an approach may have a big impact on procurement strategies of such systems, the integration tax of multiple COTS as well as legacy applications still remain a costly operation. The integration cost is compounded by the fact that COTS packages are often monolithic applications which require customisation for a particular domain. Such customisations are costly operations using vendors’ development environments which are based on particular technologies and tools. Even within a telco environment, it is not uncommon to have multiple instances of such COTS packages deployed with different customisations. Therefore, apart from cost, such an approach hinders reusability of these packages. To facilitate rapid service creation and deployment of new ICT services, definition of BT-wide repositories of standard engineering and systems capabilities are envisaged so that new services and their surrounding support systems can be built rapidly from existing COTS components, which provide the standardised capabilities. Once again, lack of precision in specifying such capabilities will significantly reduce 98
BT Technology Journal • Vol 23 No 3 • July 2005
interoperability and their wider reuse at the specification, implementation and operational levels. With the current regime of agile development, ninety-day cycles and hot-housing principles, the adoption of tools and approaches that apply advanced model-driven techniques in the development of OSS components, and integrated OSS solutions, becomes even more important. This is due to the enhanced automation capacity of model-driven techniques to further reduce the overall cost, effort and time necessary to verify and validate requirements, and to develop, test and integrate new applications with existing BT systems.
3.
MDA principles, benefits, tools and industry take-up
MDA is a set of OMG defined standards, which aims at modelling structure, behaviour and orchestration of system components at higher levels of abstraction, while hiding details of platforms, middleware, etc, of system implementations. These models are constructed using precise meta-models which are descriptions of modelling languages for a particular level of abstraction, e.g. one meta-model might be the description of a component-based OSS language as a specialisation of UML (see Fig 2). Precise meta-models defined in this manner (instead of conventional UML profiles) offer a number of advantages:
•
complex language semantics can be specified as constraints,
•
customary tools can be generated which enforce language semantics, and therefore, while designing models, they can be instantly verified,
•
transformations can be specified between these models, and tools can execute these transformations to generate new models (or code) — this also ensures upward compatibility with any new design/modelling language which may emerge in the future.
The core standard in OMG MDA is the meta object facility (MOF), used for defining modelling languages (UML or other domain-specific languages). The query/ view/transformations (QVT) language is based on MOF and will be the standard language for writing transformations and mappings between MOF-defined languages. MDA employs the object constraint language (OCL) in order to express constraints and add precision to these language specifications (for both language descriptions, i.e. meta-models, as well as models expressed in these languages). Models now can be verified against precise constraints (see Fig 3). Also, MDA introduces an action semantics language (ASL)
Model-driven systems development and integration environment
computationindependent model
platformindependent model
technologyindependent models technologyspecific models
platformspecific model
running system
Fig 2
Automated transformations between models at different level of abstraction.
MOF
UML
meta-language
DSLs
QVT
EJB
languages
rules
OCL
rules EJB code or
platformindependent model
Fig 3
platformspecific model
MDA standards for defining domain-specific languages and transformations.
which allows for arbitrary behavioural specifications to be added to models. In addition to being a meta-language and providing an API for model repositories, MOF also provides a stream-based (file-based) interchange format for all models. This is based on XML and is called XML metadata interchange (XMI). XMI is a standard interchange mechanism used between various tools, repositories and middleware. XMI can also be used to automatically produce XML DTDs (as well as XML schemata) from UML and MOF models, providing an XML serialisation mechanism for these artefacts. The Java community has also defined a metadata interchange language, the Java meta-model interface (JMI), which is based on Java. Another MDA standard is the common warehouse meta-model (CWM), which is
the OMG’s standard proposition for data warehouses. CWM covers the full life cycle of designing, building and managing data warehouse applications and supports management of the life cycle. Also, numerous UML profiles are defined both by OMG as well as other bodies for platforms such as CORBA, .NET, J2EE, EAI, SQL, C++ and EDOC as a basis for writing PIMs or PSMs. These standards, together with XMI, ensure full interoperability over different vendors’ MDA tools. MDA envisages a variety of tools for defining metamodels, models and transformations between them, as well as model repositories where all modelling artefacts can be managed and shared by an organisation. Figure 4 shows the range of such tools, all communicating using various exchange mechanisms [10] (primarily based on XMI). BT Technology Journal • Vol 23 No 3 • July 2005
99
Model-driven systems development and integration environment
transform Def editor
model editor
transformation tool
interchange of models (XMI, JMI, IDL) and transformations
transform Def repository
model validator
Fig 4
model repository
MDA tool sets.
There are many industrial MDA tools in the market, offering a variety of functionality for MDA support. However, to date, most tools do not cover the entire life cycle of software development and integration. A variety of industries, including the communications industry, have been quick at benefiting from the MDA technology. For instance, Kennedy Carter [11] used its MDA tools with its implementation of an action semantics language to generate 100% of the code for the Lockheed Martin F16 cross-platform mission management system. Other companies, such as TSystems, Siemens and Focus/IKV++, have used MDA for developing billing systems, inventory tracking systems, OSA/Parlay service delivery platforms, etc, with great success. Of course, in an enterprise systems strategy, we do not always wish to generate models and code. Often, as part of the IT strategy, we are using COTS and/or legacy systems. It is recognised that one of the major sources of costs in any IT organisation is the integration of COTS/legacy systems. It is expected that these costs will be drastically reduced as MDA would allow, without interfering with the implementation, the modelling of the services/APIs of these systems to define integration logic and to automatically configure COTS/legacy systems through precise transformations. Additionally, by having made the MDA-based models semantically rich, new applications can, when necessary, be regenerated for new/existing platforms (for cases such as adding new features, etc). All these processes will be carried out with the automated support of customised tools, which embody BT’s architectural and design guidelines, rather than the generic multiplicity of vendor tools and methodologies (see the single-model-driven solution design environment in Fig 1).
4.
OSS industry standards NGOSS, OSS/J and their relation to MDA
In response to the challenging goals of reducing cost, increasing agility and managing IT and telco resources 100
BT Technology Journal • Vol 23 No 3 • July 2005
in an integrated fashion, the OSS community, through the TMF, has defined a number of fundamental principles for designing the next generation OSS. In summary, NGOSS applies a top-level approach for the specification of an OSS architecture where:
•
technology-neutral and technology-specific architectures are separated,
•
the more dynamic ‘business-process’ logic is separated from the more stable ‘component’ logic ,
•
components present their services through well defined ‘contracts’ with clear semantics,
•
policies are used to provide a flexible control of behaviour in an overall NGOSS system,
•
the infrastructure services, such as naming, invocation, directories, transactions, security and persistence, are provided as a common deployment and run-time framework for use by all OSS components and business processes over a service bus,
•
a common shared information and data model (SID), where all data used by components, processes and policies will follow an agreed standard format.
Furthermore, the OSS/J Initiative [1] is producing OSS Java API standards based on the J2EE platform, where some of these APIs have become mature and are being used by the vendor community (e.g. service activation, trouble ticket, billing, QoS, inventory, SLA management, etc). These OSS APIs are based on the process framework eTOM [12], developed by TMF, and they cover the entire OSS functionality from service fulfilment, to assurance, to billing processes spread across customer relationship management, service management, resource management, and to supplier/partner management functionality layers. The NGOSS principles together with standard OSS/J APIs ensure a more coherent, scalable approach to building OSS of the future, paving the path for a truly plug-and-play OSS infrastructure with support from the growing market for OSS components. Furthermore, the TMF NGOSS proposes a methodology for developing OSS components. The NGOSS life cycle, depicted in Fig 5, consists of four views. The business view captures business requirements irrespective of how automated computerised systems will realise these. The system view describes the system capabilities in a technology-neutral manner. The implementation view describes technology-specific
Model-driven systems development and integration environment
system capabilities. Finally, the deployment view captures the run-time components of the system. In each life-cycle view a number of modelling artefacts are generated that populate the common knowledge repository and drive the realisation of OSS solutions. Therefore the NGOSS life cycle and methodology is inherently a model-driven methodological framework for OSS development. The augmentation of NGOSS with MDA principles, as shown in Fig 5, can further facilitate the end-to-end NGOSS life-cycle management and the traceability of interrelated NGOSS artefacts across the life-cycle views and among numerous stakeholders involved in the development process of OSS. Section 5.3 reports on BTled activities recently initiated within the TMF that concentrate on these issues.
5.
MDA work in BT
Within BT, we have recognised the potential value and benefits of the MDA approach and have engaged in a number of endeavours to demonstrate them. In section 5.1, we describe the use of MDA in developing an inventory OSS application entirely from semantically rich models. Section 5.2 describes our embryonic OSS
technology-neutral view
computationindependent model
service provider view
business capabilities, constraints and context
technology-specific view
business
test bed, based on NGOSS and OSS/J component specifications whereby abstract business process models specifying the OSS integration logic are mapped on to technology-specific models facilitating the automatic generation of the integration code. Section 5.3 describes our leading work in the TMF, together with other major industrial partners, to apply MDA to the NGOSS life-cycle methodology. Section 5.4 describes our collaborative work to apply MDA for generating decentralised management solutions for dynamic networks. Already the potential value of MDA has been recognised throughout BT, and we are actively identifying application areas where MDA can be used to achieve substantial cost reduction and the delivery of high-quality complex services. One such application area is described in section 5.5 where MDA is being used to automate the mapping of various proprietary information models in a common information model within the Transform OSS. Other planned work is to use MDA to validate UML models against BT’s modelling guidelines and architectural principles.
5.1
Inventory OSS
To get some insight into the MDA technology, based on the OSS/J specification of inventory APIs, we used an
service developer view
platformindependent model
system capabilities, constraints and context system
deployment deployment capabilities, constraints and context
implementation implementation capabilities, constraints and context
platformspecific model
running system
automated tool support based on MDA
Fig 5
Using model driven technology to manage OSS life cycle.
BT Technology Journal • Vol 23 No 3 • July 2005
101
Model-driven systems development and integration environment
advanced meta-modelling tool (XMF from Xactium) to generate a complete inventory application and associated GUI. The main reason behind choosing the OSS/J inventory was the lack of an OSS/J reference implementation for this particular API, hence an opportunity to contribute an MDA-based implementation which could quickly verify the specification. An inventory-specific meta-model was specified, embodying concepts of the original OSS/J specification, such as entities, specifications and associations, and thus defining a special domain-specific language for OSS/J-compliant inventories. Among these entities, where appropriate, sub-classifications are defined for products, services and resources. Using xOCL, an extended OCL language, constraints are defined over this meta-model to constrain the valid inventory models which can be defined in the tool. Using this metamodel, a model of BT VPN products, services and specifications (see Fig 6) has been developed which contains rich specification of these entities, and their structural and behavioural features (using xOCL). Transformations are then defined from inventory meta-models to Java, J2EE and GUI meta-models. Execution of these transformations in the Xactium XMF tool generates 100% code for the entire inventory application together with its GUI (see Fig 7). We have clearly demonstrated how changing requirements, such
Fig 6
102
as adding new attributes as well as new operations, can be provided by the models and how new applications can be generated within minutes. A more extensive description of this work is given by Georgalas et al[6].
5.2
MDA-enabled integration of standards-based OSS components
As part of endeavours to explore the use of modeldriven technologies in the area of OSS component integration, we have built an internal test bed using OSS component reference implementations made available by the OSS/J community. Based on the functionality provided by the test bed, the goal of this work was set on using MDA to precisely specify in a model the way some of the components integrate and then automatically generate the code representing the technology-specific realisation of the integration logic. To facilitate this goal, it is important to expose the relevant component functionality early on in the development process through appropriate PSMs and PIMs. Therefore, it is necessary to work bottom-up, i.e. reverse-engineer the available OSS components, understand their capabilities and capture this
Model of BT IPVPN services and products based on a prescriptive meta-model (bottom left hand elements).
BT Technology Journal • Vol 23 No 3 • July 2005
Model-driven systems development and integration environment
Fig 7
100% autogenerated OSS inventory application together with its graphical user interface.
knowledge in reusable PSMs and PIMs. When the component capabilities are exposed in model form, designers can forward-engineer and use these capabilities in new PIMs and PSMs which specify the component integration. The reverse- and forward-engineering tasks are driven by a number of technology-independent and technology-specific meta-models, namely, component, process and Java meta-models. These provide domainspecific language frameworks, based on which PIMs and PSMs can be generated, more precisely:
•
the component meta-model describes a set of concepts, such as component, provided and required capabilities, operations, input and output data, which are necessary to specify an OSS software component at the PIM layer — this metamodel fully complies with the UML 2.0 component model,
•
the process meta-model describes a set of concepts, such as process, activity, flow, input and output data, which are necessary to specify a process at the PIM layer in the form of a UML activity diagram, and then a process integrates component capabilities in a sequence of process activities — this meta-model is fully compliant with UML 2.0 activity diagrams,
•
the Java meta-model describes key elements of the Java language, such as classes, methods and input parameters — it is used to generate a PSM, i.e. Java, representation of the integration logic, represented at the PIM layer as an activity diagram.
Another key element of the meta-modelling layer is the definition of transformations between technologyindependent and technology-specific meta-models. More specifically, a set of transformation rules are specified that map entities of the process meta-model on to entities of the Java meta-model. These rules BT Technology Journal • Vol 23 No 3 • July 2005
103
Model-driven systems development and integration environment
define the way activity diagrams, i.e. component integration models, transform into Java, thereby allowing the automatic generation of executable integration logic.
component capabilities. Finally, the JavaSourceCode package indicates the Java code that is automatically generated by the Process2Java transformation and implements the ServiceAssuranceProcess PIM.
All models, meta-models and transformations are defined in Xactium’s XMF tool [8]. BEA WebLogic is used as the hosting platform for the OSS/J component test bed. Currently, four OSS/J components, namely billing, service activation, QoS and trouble ticketing are deployed. These are the respective OSS/J reference implementations freely available by the OSS/J Initiative. Other components, such as inventory and workforce management, are simulated. We have used these components in two application scenarios.
A more extensive description of this work is presented elsewhere by Georgalas [7].
•
•
The NGOSS/MDA TMF Catalyst
This process starts when network faults or performance alarms are received by the QoS OSS component. The impact of these events is correlated against services and customers from an inventory OSS, after which trouble tickets are generated in a trouble ticketing OSS component. Trouble tickets are dispatched to a workforce OSS where faults are rectified and service returns to its normal operational state.
While MDA contributes a useful set of standard technologies to support software development, it lacks the rigour of a precise methodology that can guide developers step by step through the process. The TMF closes this gap with the provision of the ‘NGOSS Lifecycle and Methodology’ standard that provides a thorough methodological framework for OSS development. BT have initiated and lead in the TMF a number of activities that are aimed at investigating how NGOSS and MDA can come together in one package in order to generate maximum value for the telecommunications industry by facilitating end-to-end OSS life-cycle management, increasing development speed, reducing costs and enhancing quality of the end product. The NGOSS/MDA TMF Catalyst project [3, 13—16] is a first proof-of-concept piece of work towards the above directions, motivated by the following key drivers:
Service provisioning
•
This process starts when a customer creates a new order for a product through the service activation OSS. Checks are carried out, appropriate entries are made in the inventory OSS, service provisioning OSS will configure the service and resources, appropriate SLAs are set up in the QoS manager OSS, and finally the billing OSS is notified to start billing for the usage of the service.
the large integration tax incurred by service providers when new OSS components are deployed and integrated with each other as well as with legacy systems,
•
the disconnect between the knowledge driving the solution development process, such as design models and system specifications, and the live, operating OSS components,
•
the difficulty of reusing elements of the current OSS infrastructure in the delivery of new solutions.
Service assurance
Figure 8 provides a high-level view of the model and meta-model layers for the service assurance application scenario. PIMs, PSMs and meta-models are shown in the form of UML packages with dependencies running across them. The OSSComponentMetaModel, Process MetaModel and JavaMetaModel packages represent the component, process and Java meta-models described above. The invokesCompCapability dependency signifies that process activities are delivered by the invocation of component capabilities. Process2Java indicates the transformation between the process and Java meta-models. The QoSComp, TroubleTicketComp and WorkforceMgmtComp packages contain the respective PIMs of OSS components used in the scenario. The ServiceAssuranceScenario package contains the activity diagram that models the service assurance process and integrates the scenario’s OSS component through invocation dependencies that connect activities of ServiceAssuranceScenario to 104
5.3
BT Technology Journal • Vol 23 No 3 • July 2005
The NGOSS/MDA Catalyst project aims at practically realising NGOSS as a model-driven and knowledgebased problem-solving methodology. It aims to improve understanding and communication of the problem by establishing one common model-driven approach and by using the NGOSS standards and principles commonly across the stakeholder community throughout the life cycle. It also intends to automate NGOSS by using tools to capture traceable knowledge artefacts in all NGOSS life-cycle views and by linking models to system capabilities of the existing OSS infrastructure, hence bridging the gap between technology-neutral specifications and technology-specific solution implementations. The short-term objective of the NGOSS/MDA Catalyst project is to evaluate the state of the art by:
Model-driven systems development and integration environment
domain
invokesCompCapability
ProcessMetaModel
Process2Java range
OSSComponentMetaModel
JavaMetaModel
metaPackage
metaPackage
model layer
metaPackage
metaPackage
metaPackage
meta model layer
invokesQoSPerfManCapab
QoSComp
invokesQoSFaultManCapab
TroubleTicketComp
invokesTTCap
ServiceAssuranceProcess
invokesWorkforceManCapab
WorkforceMgmtComp PIMs PSMs JavaSourceCode
Fig 8
•
•
•
Meta-models and models driving the OSS/J component integration.
practically applying the NGOSS life cycle and methodology on a service assurance case-study provided by the OpenOSS Catalyst — the aim is to generate an applicable set of guidelines for using the NGOSS model-driven approach in practice,
•
BT,
•
QinetiQ,
•
AutoMagic,
•
AT&T,
demonstrating the model-driven approach through a number of tools — the aim is to study the current maturity of OMG MDA standards, such as XMI, in various modelling tools and to what degree these can facilitate stakeholder collaboration,
•
Sonic Software,
•
Tata Consultancy Services.
exhibiting how NGOSS, as a model-driven approach, can facilitate the specification of a solution in a technology-neutral form and the realisation of this solution through different technology-specific implementations.
The NGOSS/MDA Catalyst project consortium of international partners consists of:
The project results were presented at the TeleManagement World Conference in Nice, France in May 2005 [2]. There is a longer term objective of the NGOSS/MDA initiative which is to facilitate the wider adoption by the industry of the NGOSS standards through:
•
standardising the artefacts and rationalising the application of the NGOSS methodology in practice, BT Technology Journal • Vol 23 No 3 • July 2005
105
Model-driven systems development and integration environment
•
providing an illustrative common repository for the NGOSS content,
•
demonstrating the methodology with instrumentation to capture and consistently manage repository content,
•
facilitating the interoperation of different tools used by different stakeholders who collaborate during the problem-solving process,
•
identifying opportunities for enhanced collaboration among TMF, OMG, OSS/J and other communities to support round-trip engineering.
BT are currently leading a recently established TMF working team called NGOSS Model Driven Design and Development (NGOSS/MD3) which falls under the umbrella of the NGOSS Lifecycle and Methodology team and constitutes the formal scheme within TMF aimed at steering ahead the longer term efforts in this area.
5.4
Celtic Madeira project
Madeira is a collaborative project run under the auspices of the Celtic cluster of the EUREKA programme. The project’s objective is to develop a decentralised network management platform with the aim of facilitating the explosive emergence of new generation services. The platform’s design will break away from a hierarchical network management philosophy and will aim to make network nodes more self-managed, self-aware and self-healing, guaranteeing seamless end-to-end service delivery even across multiple domains. Autonomic computing, peer-to-peer techniques and policy-based management will be used to achieve this. One aspect on which Madeira puts strong emphasis is the use of model-driven methodologies and techniques, such as OMG’s MDA, TMF’s NGOSS and DEN-ng for specifying interfaces and information, e.g. node configuration and their semantics, in a transparent way and independent of network or technology paradigms. This need originated because the end-toend delivery of services to end users involves the collaboration of multiple commercial parties, which may own parts of the network and/or service delivery platforms. Each party will make autonomous decisions regarding technologies and paradigms for the platforms, networks and OSS they govern. Therefore it is imperative, for the eventual delivery of the contracted service QoS levels to the customers, that information flows and collaboration of systems/applications across business boundaries are smooth and based on technology-independent specifications and models. 106
BT Technology Journal • Vol 23 No 3 • July 2005
The Madeira project is a case-study focusing on fault and configuration management issues of nodes in a mobile infrastructure. This will be a good example of a fluid network environment, where the infrastructure changes routinely with new boxes moving in, or others taken away or constantly changing position; hence a very flexible configuration and fault management functionality becomes key for the sustainability of the network. In this setting, we intend to apply modeldriven techniques to capture adaptive management capabilities of components that communicate on a peer-to-peer basis to resolve emerging unstable situations. We will also be using the OSS/J reference implementation components to simulate a back-end environment of support systems investigating the impact of the changing network circumstances on the operator’s OSS systems. Feedback will be provided both to the OSS/J Initiative and the TMF. The Madeira consortium consists of BT, Waterford Institute of Technology (Ireland), Ericsson Ireland, Ericsson Sweden, Siemens Austria, Telefonica and Universitat Politècnica de Catalunya. A more extensive overview of the work is presented by Zach et al [17].
5.5
BT Transform
BT Global Services (BTGS) is a major supplier of managed ICT services. The BT Transform [18, 19] programme provides a world-wide IP network supporting a business services platform and is a response by BT to the changing face of ICT services development and management. These changes have also driven the MDA effort throughout the industry. Over the last five years the nature of the challenge that BT has faced has changed radically with consumers of ICT services relying ever more on these services to provide a real advantage within their core business. The diversity and agility now evident in the way that businesses work are reflected in the demands upon the IT infrastructure supporting ICT services. These demands are not only for more complex solutions, but have also affected the rate at which new services are introduced and at which users can select and de-select services. The stable world of five years ago has become much more dynamic. The impact upon BT has been a re-appraisal of the way in which services are provided, and combined with the adoption of an IP-only platform, led to the BT Transform programme. A major part of the BT Transform programme has been the development of an advanced fit-for-purpose OSS. Previous work within BT on directory-enabled networking had illustrated the benefits of an information model within OSS development and subsequently led to the production of a prototype OSS structure based upon TMF NGOSS within BTGS. The envisaged demands on the OSS represented a challenge
Model-driven systems development and integration environment
in terms of the scale and complexity of Transform OSS functionality and legacy integration. Furthermore, it is essential for the quality of OSS development that it rested on a technology neutral basis. These factors were addressed by adopting TMF NGOSS as a cornerstone of the OSS design and by the use of a model-driven approach in the development and deployment of OSS solutions. The Transform OSS is being introduced in stages. After developing an information model, based on the TMF SID, the first stage of systems development has been a data services layer implemented through a model-driven approach. The data services layer provides a virtual repository for OSS applications, where the schema of the repository is the information model, i.e. OSS applications are presented with a view structured according to the information model that sits on top of the collection of management data sources within the OSS. The data services layer handles all details concerned with access and data-source-specific schemata and mappings. Any changes to the data source collection are not observed by the OSS applications (as long as a data source for each information model element exists) and allows their design to depend on the logical view of management information provided by the information model. The Transform OSS, through reasons of legacy and customer requirements, may be required to use any from a range of management systems that perform network and systems management and will be sources of management data. Figure 9 provides an overview of the data services layer. The data services layer generator is a custom made tool that creates three types of artefact:
•
information model view artefact,
•
mapping artefacts, which implement mapping rules for data transformation,
•
gateway artefacts, which implement physical data source access.
The task of the data services layer generator (DSLG) is to create artefacts that will do the necessary decision making, mapping and data processing required to map requests by OSS applications against the management data sources. There are three inputs to the DSLG. The information model is an XMI formatted representation of the Transform information model. The management data source knowledge comprises details of the schemata held within known management data sources and other details such as physical address and account details. The third input is that of the map designer. The purpose of a map designer is to make decisions that map management data source elements to elements of the information model. The map designer provides steer to the mapping process and provides a set of map directives. These map directives take the form of XML data items, are proprietary, and are currently defined as required by the project. They can specify broad areas of mapping, such as ‘the PRM is to be mapped one-to-one to a management data source X’, or can specify individual class, relationship or attribute mappings. The role of map designer is needed, as it is not possible to determine, in an automated fashion, how specific model-element-to-data-source-element mapping should occur. There is no standard way of describing which fragment of an information model a particular data source holds. Typically, with the current
information model (XMI)
map directives
Transform information model (TRIM) management data source knowledge
data services layer generator
map designer
OSS application
RDBMS RDBMS
information model view
mapping layer
gateway layer
DIR DIR others others (e.g. JDO) (e.g. JDO)
Fig 9
Transform data services layer.
BT Technology Journal • Vol 23 No 3 • July 2005
107
Model-driven systems development and integration environment
state of awareness and adoption of information model concepts, data sources would not be aware that they are participating in a model-driven system. It would be possible, however, to model, and represent the model fragment distribution of, a collection of management data sources and the benefits of this to the project are currently being evaluated. The data services layer has been used on live customer operations from May 2005 within the Transform Phase II Release 1 OSS. The Transform information model for PIIR1 comprises around 350 classes and a similar number of relationships. In the current Transform solution (release 1), the DSLG is developed as a stand-alone bespoke application to generate various data model schemata from the generic Transform Information Model (TRIM) which is in XMI format. Figure 10 shows how MDA technology can be used to engineer a solution for the DSLG. Using MDA, languages for specifying TRIM models, as well as JSM, RDBMS, etc, as well as other proprietary COTS packages’ data models can be formally captured in a declarative form as meta-models. These meta-models can be expressed in the MDA standard language of MOF; and the transformation between these metamodels can be defined using the MDA QVT standard. This gives a greater degree of openness in how metamodels and transformations are defined. Thus changes to these transformations as well as the introduction of new meta-models for new COTS data models, etc, can be added to the system’s solution in a very short space
Transform information model (TRIM)
TRIM metamodel
mapping specifications
JDO metamodel
model driven transformation engine
JDM data model
RDBMS metamodel SQL metamodel
RDBMS data model
SQL data model
Fig 10
108
Model-driven approach to Transform data services architecture.
BT Technology Journal • Vol 23 No 3 • July 2005
of time. As these languages are standardised, any MDAcompliant transformation engine can be used to execute the transformations, and, taking a particular TRIM as input, generate a multiplicity of specific data models. Using a standards-based approach for defining data model descriptions and transformations enables increased productivity and reuse of mapping definitions, tool interoperability and ease of changes to data models, as well as transformations when new requirements emerge or due to the need to interface to new systems.
6.
Conclusions
MDA is the culmination of over 20 years research and development in software specification, modelling and formal methods. Unlike many similar endeavours in the past which did not come to industrial fruition, MDA shows a promising momentum of industrial adoption. The fundamental concept behind the success of MDA is that instead of attempting to define a single language for all specification languages, it sets out a framework whereby domain-specific modelling languages can be defined together with transformations to other languages, and ultimately code. Compared to existing modelling tools, MDA tools enable a meta-modelling framework, which allows a tool customised for domainspecific requirements to be configured. This is unlike the existing modelling tools where typically only one dialect or version of UML is supported. Using MDA implies that our designers and architects are not bound and locked into only one language and one tool. Furthermore, the MDA framework provides mechanisms for writing automated transformations/mappings between such modelling languages. With this approach, within a company we are able to choose our modelling languages for specific domains; and we can choose the level of abstraction of these languages (a continuum from computational business models to platformindependent models to platform-specific models, and ultimately to code for specific implementation environments). Many tool vendors provide MDA tools with various degrees of sophistication — and many industries are already reaping the benefits of this approach. In the telecommunications domain, following two earlier European collaborative projects on using MDA, a recent IST project — Modelware [20] — is launched with clear targets of bridging the gap between academic research and large-scale industrial use with the objective of enabling a 15—20% productivity increase of software systems development based on model-driven development (MDD).
Model-driven systems development and integration environment
Within BT, our leading research work is under way to develop a domain-specific MDD and integration environment, i.e. tools embodying BT’s architectural and design guidelines for new ICT service creation and their accompanying OSS capabilities. Also, as mentioned in section 5.5, we are automating information model mapping for the Transform OSS to demonstrate the effectiveness of the MDA approach in terms of increased productivity and accuracy of model transformations. Our leading work in the NGOSS/MDA TMF Catalyst with strong links into the Open OSS TMF Catalyst [16, 21] and the NGOSS/MD3 TMF working team will ensure industry’s alignment in the use of MDA technology at various stages of the software development life cycle.
Acknowledgments The authors would like to express their grateful thanks for many fruitful discussions with and suggestions by their colleagues, especially Jim Hardwicke, Phil Holmes, and Shumao Ou.
References
10 Warmer J et al: ‘MDA Explained: The Model Driven Architecture’, Addison Wesley (2003). 11 Kennedy Carter — http://www.kc.com/ 12 TMF process framework (eTOM) — http://www.tmforum.org/ browse.asp?catID=1647 13 Model Driven Architecture — http://www.omg.org/mda/ 14 Georgalas N: ‘NGOSS/MDA: Realising NGOSS as a Model Driven Approach’, Catalyst project, TeleManagement World Conference, Nice, France (March 2005) — http://www.tmforum.org/browse. asp?catID=2248&linkID=29971 15 Strassner J, Fleck J, Huang J, Faurer C and Richardson T: ‘TMF White Paper on NGOSS and MDA’, TeleManagement Forum/ Object Management Group (February 2004) — http://www.tm forum.org/browse.asp?catID=1875&sNode=1875&Exp=Y&link ID=28972 16 TMF Catalyst project, using XML and OSS/J to integrate COTS for a service provisioning process — http://www.tmforum.org/ browse.asp?catID=786 17 Zach M, Parker D, Fallon L, Unfried C, Ponce de Leon M, van der Meer S, Georgalas N and Nielsen J: ‘CELTIC Initiative Project Madeira: A P2P Approach to Network Management’, Proceedings of the Eurescom Summit 2005 on Ubiquitous Services and Applications, Heidelberg, Germany (April 2005).
1 OSS through Java Initiative — http://www.ossj.org/ 2 TeleManagement Forum — http://www.tmforum.org/
18 BT Transform home page (BT people only) solutions.intra.bt.com/mcs/transform/default.cfm
3 TeleManagement Forum, NGOSS — http://www.tmforum.org/ browse.asp?catID=1911
19 McDonnell E G et al: ‘BT Transform — an IP-enabled business platform’, BT Technol J, 23, No 3, pp 121—136 (July 2005).
4 Azmoodeh M and Hardwicke J: ‘Astute Manager’s Guide to Technology Neutral Architectures for OSS Software Development’, BT Internal report (September 2003).
20 Modelware — http://www.modelware-ist.org/
5 Georgalas N and Azmoodeh M: ‘Using MDA in Technologyindependent Specifications of NGOSS Architectures’, 1st European Workshop on MDA (MDA-IA 2004), Enschede, The Netherlands (March 2004). 6 Georgalas N, Azmoodeh M, Clark T, Evans A, Sammut P and Willans J: ‘MDA-Driven Development of Standards Compliant OSS Components: The OSS/J Inventory Case Study’, Proceedings of the 2nd European Workshop on Model Driven Architecture with Emphasis on Methodologies and Transformations (EWMDA 2004), Canterbury, UK (September 2004). 7 Georgalas N, Azmoodeh M and Ou S: ‘Model Driven Integration of Standards Based OSS Components’, Proceedings of the Eurescom Summit 2005 on Ubiquitous Services and Application, Heidelberg, Germany (April 2005). 8 Xactium — http://www.xactium.com 9 Compuware — http://www.compuware.com/
—
http://
21 Bruce G L et al: ‘The potential for open source software in telecommunications operational support systems’, BT Technol J, 23, No 3, pp 79—95 (July 2005).
Dr Manooch Azmoodeh joined BT after 5 years lecturing at Essex University and researching intelligent database models and graphical query languages. Since then he has been active in various aspects of research into designing management systems for broadband networks and services, intelligent diagnostic engines, object oriented specification languages and query languages for system’s interactions, information modelling languages, management of IP and ATM networks, service description languages for OSS services, and lately researching technologies to design the next generation of OSS. He leads a team looking into technologies such as model driven development, policy based management, and autonomic computing to automate much of the OSS integration of BT systems across all ICT infrastructure and services.
BT Technology Journal • Vol 23 No 3 • July 2005
109
Model-driven systems development and integration environment
Nektarios Georgalas holds a Diploma in Electrical and Computer Engineering from University of Patras, Greece, an MPhil in Computer Science from UMIST, Manchester, UK, and is currently completing his PhD in Computer Science at the University of London. He joined BT in 1998. He has since been actively involved in and managed numerous collaborative and internal research projects in areas such as active networks, market-driven data management systems, policy-based management, distributed information systems and Web Services. He currently leads the NGOSS/MDA Catalyst project and the NGOSS/MD3 working team in TMF, manages the MDA aspects of the Celtic-MADEIRA project, technically directs the Model-driven Process-based OSS/J component integration project and looks into opportunities to downstream results of the MDA work throughout BT via a number of case studies. He holds 5 patents and has authored more than 18 papers.
110
BT Technology Journal • Vol 23 No 3 • July 2005
Steve Fisher holds a BSc(Hons) in Electronic Engineering from the University of Sussex. After graduating he worked on real time and network systems. On joining BT in 1991 he worked on BT’s public and private Directory services and contributed to the X.500 standards development for BT. From then his activities have moved to a number of areas concerned with network and systems management. He has worked on a number of directory-enabled networking projects and currently works within the BT Transform OSS programme.
