NGOSS Tutorial

NGOSS ArchitectureTechnology Neutral Specification

TMF 053

Public EvaluationVersion 2.5May, 2002

� TeleManagement Forum 2002

TM Forum NGOSS Technology Neutral Architecture

ii �TeleManagement Forum 2002 TMF 053 v2.5

NOTICE

The TeleManagement Forum (“TM Forum”) has made every effort to ensure that the contents of this documentare accurate. However, no liability is accepted for any errors or omissions or for consequences of any use made ofthis document.

This document is a draft working document of TM Forum and is provided to the public solely for comments andevaluation. It is not a Forum Approved Document and is solely circulated for the purposes of assisting TM Forumin the preparation of a final document in furtherance of the aims and mission of TM Forum. Any use of thisdocument by the recipient is at its own risk. Under no circumstances will TM Forum be liable for direct or indirectdamages or any costs or losses resulting from the use of this document by the recipient.

This document is a copyrighted document of TM Forum. Without the appropriate permission of the TM Forum,companies that are not members of TM Forum are not permitted to make copies (paper or electronic) of this draftdocument other than for their internal use for the sole purpose of making comments thereon directly to TM Forum.

This document may involve a claim of patent rights by one or more TM Forum members, pursuant to theagreement on Intellectual Property Rights between TM Forum and its members, and by non-members of TMForum.

Direct inquiries to the TM Forum office:

1201 Mt. Kemble AvenueMorristown, NJ 07960 USATel No: +1 973-425-1900Fax No: +1 973-425-1515TM Forum Web Page www.tmforum.org

http://www.tmforum.org/

TMF 053 v2.5 �TeleManagement Forum 2002 iii

ACKNOWLEDGMENTS

The TeleManagement Forum would like to acknowledge the contribution made to this effort by the followingpeople:

Steve Afrin, ComInsights

Francis Anderson, Tivoli

Francesco Caruso, Telcordia Technologies

Geoff Coleman, RateIntegration

Giuseppe Covino, CSELT

Tony Dean, TeleManagement Forum

Petre Dini, Cisco Systems

Paul Doyle, ADC Telecommunications

Jane Fox, Telcordia Technologies

Cindy Cullen, Telcordia Technologies

Wedge Green, Worldcom (sponsor)

Carlton Hall, CH2M Hill

Martin Huddleston, Defense Evaluation and Research Agency (UK)

Matt Izzo, Agilent

Paul Levine, Telcordia Technologies

Alain Lemoine, Eftia OSS Solutions (current co-editor)

Dan Matheson, Hewlett-Packard

Bruce Murrill, TeleManagement Forum

Christopher Prowse, Defense Evaluation and Research Agency (UK)

Jonas Rabin, Lucent Technologies

Dave Raymer, Motorola (team lead)

Jean-Luc Richard, Evidian

Tony Richardson, TeleManagement Forum

Jeff Risberg, TIBCO

Ken Roberts, Cisco Systems

Edward Scott, PrismTech

John Strassner, Intelliden (current editor)

Al Vincent, TeleManagement Forum

Jim Willits, Hewlett-Packard


iv �TeleManagement Forum 2002 TMF 053 v2.5

ABOUT THIS DOCUMENT

TM Forum Documents

The NGOSS Technology Neutral Architecture Specification is being issued as Public Evaluation Version 2.5.

The purpose of an Evaluation Version is to encourage input based on experience of members and the public asthey begin to use the document. Following the Evaluation Period, documents that are seen to deliver value arecandidates for formal approval by the TM Forum. All documents approved by the TM Forum undergo a formalreview and approval process.

This document will continue under formal change control. Further work will be reflected in revisions to thisdocument.

Revision History

Version Date Who Purpose

1.0 2001.01.01 TMF Release for member evaluation (reformatted)

1.01 2001.01.13 D. Raymer

R. Trivedi

Updates based on TMF membership evaluation

1.02 2001.01.16 A. Vincent Dublin Meeting Rough Changes

1.03 2001.01.24 A Vincent Post Dublin Review

1.04 2001.01.29 A. Vincent Post Dublin Review 2

1.08 2001.02.09 D. Lewis Dublin input edited for consistency

1.09 2001.03.30 D. Raymer,R. Trivedi

Rework from Dublin, ParisInclusion of ARCs and Comments from BAC/SDM

1.5 2001.04.27 TMF Updated for Member Evaluation

1.60 2001.08.21 D. Raymer Updates based on Long Beach TAW review

1.99 2001.09.07 D. Raymer Updates based on TSA input.

Release for working team evaluation, prior to general memberevaluation.

2.1 2002.05.02 J. Strassner Edits per 053_series_update_team, concentrating on policy, theshared information/data model, and process. Minor editing andclarification updates also included throughout the document.

2.5 2002.05.27 TMF Formatted for Public Evaluation


TMF 053 v2.5 �TeleManagement Forum 2002 v

Time Stamp

This version of the NGOSS Architecture Technology Neutral Specification, TMF 053 Version 2.5, can beconsidered valid until November 2002.

How to obtain a copy

An electronic copy of this document can be downloaded at the TM Forum Web Site (www.tmforum.org),Publications or through a link to Publications from a specific team’s public project area.

If the document version has only been released to members for review and comment, the document can bedownloaded from the Members Only area of the TM Forum Web Site.

Paper versions can be made available for a small fee to cover copying, mailing and handling. If you would like apaper version of this document, please order via the TM Forum Web Site or contact the TM Forum office. If youare not a member, please contact the TM Forum office on +1 973-425-1900.

How to comment on the document

Comments must be in written form and addressed to the team editor for review with the project team. Please sendyour comments to the editor using the editor’s e-mail shown below.

John Strassner, Intelliden [email protected] (editor)

Dave Raymer, Motorola [email protected] (team lead)

http://www.tmforum.org/

mailto:[email protected]

mailto:[email protected]


vi �TeleManagement Forum 2002 TMF 053 v2.5

TABLE OF CONTENTS

Notice.......................................................................................................................................................................... ii

Acknowledgments...................................................................................................................................................... iii

About this Document ................................................................................................................................................. iv

TM Forum Documents ........................................................................................................................................... iv

Revision History ..................................................................................................................................................... iv

Time Stamp.............................................................................................................................................................v

How to obtain a copy...............................................................................................................................................v

How to comment on the document .........................................................................................................................v

Table of Contents ...................................................................................................................................................... vi

TABLE OF FIGURES ................................................................................................ Error! Bookmark not defined.

Preface .......................................................................................................................................................................x

About TeleManagement Forum ..............................................................................................................................x

1 Introduction..........................................................................................................................................................1

1.1 Background ..................................................................................................................................................1

1.2 Goals and Objectives ...................................................................................................................................1

1.3 The Road to NGOSS....................................................................................................................................2

1.4 Program Implementation..............................................................................................................................3

1.5 Phases of Delivery and Roadmap................................................................................................................3

1.6 Stakeholders in this Document ....................................................................................................................3

1.6.1 Document Use by a Service Provider ...................................................................................................3

1.6.2 Document Use by a Systems Integrator ...............................................................................................4

1.6.3 Document Use by an Independent Software Vendor............................................................................4

1.6.4 Document Use by a Network Equipment Provider................................................................................4

1.7 Organization of This Document....................................................................................................................5

2 Principles of the NGOSS Architecture.................................................................................................................6

2.1 Separation of Business Process from Component Implementation.............................................................6


TMF 053 v2.5 �TeleManagement Forum 2002 vii

2.1.1 Contract Defined Interfaces ..................................................................................................................6

2.1.2 Policy Enabled.......................................................................................................................................7

2.1.3 User Roles and Security .......................................................................................................................7

2.2 A Common Communications Vehicle...........................................................................................................7

2.3 A Shared Information and Data Environment ..............................................................................................7

2.3.1 Data Stewardship..................................................................................................................................8

2.3.2 Information Adaptation..........................................................................................................................8

2.3.3 Information Mediation............................................................................................................................8

2.3.4 A Registry of Run-Time Information......................................................................................................8

2.4 Supporting Architectural Principles ..............................................................................................................9

2.4.1 Loosely Coupled, Scalable Distributed System.....................................................................................9

2.4.2 Framework Services ...........................................................................................................................10

2.5 Separation of “Technology Neutral” and “Technology Specific” Architectures...........................................10

2.6 Compliance and Certification .....................................................................................................................10

3 Roles, Responsibilities and the Use of this Document......................................................................................12

3.1 Use of this Architecture by Architects, Designers and Implementers ........................................................12

3.2 Usage and Methodology.............................................................................................................................13

4 Architecture and Realization of the Principles ...................................................................................................18

4.1 Architectural Views.....................................................................................................................................19

4.1.1 Structural View ....................................................................................................................................19

4.1.1.1 Artifact Aspect .................................................................................................................................21

4.1.1.2 Registry Aspect ...............................................................................................................................22

4.1.1.3 Runtime Aspect ...............................................................................................................................23

4.1.2 Control View........................................................................................................................................24

4.1.3 Summary of View Concept..................................................................................................................25

4.2 Models........................................................................................................................................................25

4.3 NGOSS Contract Specifications.................................................................................................................26

4.3.1 Contract Example ...............................................................................................................................27


viii �TeleManagement Forum 2002 TMF 053 v2.5

4.3.2 Contract Lifecycle................................................................................................................................28

4.4 Distribution Transparency ..........................................................................................................................28

4.4.1 The Naming Service ...........................................................................................................................28

4.4.2 The Directory Service..........................................................................................................................29

4.4.3 The Trading Service............................................................................................................................31

4.4.4 The Invocation Service........................................................................................................................32

4.5 Components ...............................................................................................................................................33

4.6 NGOSS Process Management ..................................................................................................................35

4.6.1 Process Definition ...............................................................................................................................36

4.6.2 Process Definition Lifecycle ................................................................................................................37

4.6.3 Process Execution Environment and Context.....................................................................................37

4.7 NGOSS Shared Information and Data Management .................................................................................38

4.7.1 Concepts .............................................................................................................................................39

4.7.1.1 Example of Using Shared Information.............................................................................................41

4.8 NGOSS Policy............................................................................................................................................41

4.8.1 Towards NGOSS Policy-Based Management Systems .....................................................................42

4.9 NGOSS Adaptation ....................................................................................................................................44

4.9.1 Adaptation between Information Models.............................................................................................44

4.9.2 Adaptation between Data Encodings ..................................................................................................44

4.10 NGOSS Mediation......................................................................................................................................44

5 References ........................................................................................................................................................48

6 Open Issues and Assumptions..........................................................................................................................49

6.1 Issues .........................................................................................................................................................49

6.2 Assumptions...............................................................................................................................................49


TMF 053 v2.5 �TeleManagement Forum 2002 ix

LIST OF FIGURES

Figure 1. Relationships between Actors .................................................................................................. 13

Figure 2. Creation of a Technology Neutral Contract Specification......................................................... 15

Figure 3. Decomposition of the creation of a contract defined interface ................................................. 16

Figure 4. Static structure of relationships between Models, Contracts, and Contract Sets ..................... 17

Figure 5. Structure of NGOSS Architecture............................................................................................. 19

Figure 6. Decomposition of Framework Services.................................................................................... 20

Figure 7. Tangible Artifacts with the NGOSS Technology Neutral Architecture ...................................... 21

Figure 8. Architectural entities to support location transparency ............................................................. 23

Figure 9. Key runtime abstractions in the NGOSS TNA .......................................................................... 24

Figure 10. Control diagram illustrating invocation .................................................................................. 24

Figure 11. Contract Specification and Component Definition ................................................................ 26

Figure 12. Types of Names.................................................................................................................... 29

Figure 13. Binding of a Name to a NamedObject .................................................................................. 30

Figure 14. Using the Registry Service.................................................................................................... 31

Figure 15. Using the Registry and Naming Services.............................................................................. 31

Figure 16. Trading Service Extensions to the Registry Service ............................................................. 32

Figure 17. Process Management ........................................................................................................... 36

Figure 18. Business Process Execution Environment ........................................................................... 38

Figure 19. Shared Information Management ......................................................................................... 39

Figure 20. Information Layers ................................................................................................................ 40

Figure 21. Convergence of Management Models .................................................................................. 43

Figure 22. Contract-Based Interaction ................................................................................................... 43

Figure 23. NGOSS Legacy System Component conceptual view ......................................................... 47


x �TeleManagement Forum 2002 TMF 053 v2.5

PREFACE

About TeleManagement Forum

TeleManagement Forum is an international consortium of communications service providers and their suppliers.Its mission is to help service providers and network operators automate their business processes in a cost- andtime-effective way. Specifically, the work of the TM Forum includes:

� Establishing operational guidance on the shape of business processes

� Agreeing on information that needs to flow from one process activity to another

� Identifying a realistic systems environment to support the interconnection of operational support systems

� Enabling the development of a market and real products for integrating and automating telecom operationsprocesses

The members of TM Forum include service providers, network operators and suppliers of equipment and softwareto the communications industry. With that combination of buyers and suppliers of operational support systems,TM Forum is able to achieve results in a pragmatic way that leads to product offerings (from member companies)as well as paper specifications.

TeleManagement Forum supports several kinds of projects, including Process Automation and TechnologyIntegration projects, as well as Catalyst Projects that support both Process Automation and Technology Integrationprojects through real-product integration.

Use and Extension of a TM Forum Specification

This document defines the business problem and requirement model for creating an NGOSS Architecture. TheSpecification represents a consensus view on how to solve a specific business problem. It is expected that thisdocument will be used:

� As input for vendors developing COTS products

TMF 053 v2.5 �TeleManagement Forum 2002 1

1 Introduction

1.1 Background

With the gap between the worlds of data communications and telecommunications rapidly disappearing, thecomplexity and size of the networks supporting the emerging information and communications industry isincreasing at a corresponding rate. The ability of existing OSS solutions to manage information andcommunication networks is being rapidly outpaced by the growth of the networks. A new generation of operationsupport system is needed to manage the new generation of networks.

The Operational and Administration Management system of today has become a roadblock to innovation, insteadof a business tool for competitive success. The pace of change in the industry is such that incrementalimprovements will not work effectively. Service providers must increase their operational efficiency by an order ofmagnitude to compete, while software developers and systems integrators need to find completely new ways ofquickly producing profitable solutions.

This calls for a re-thinking on the part of information and communications service providers on how they managetheir business. It also calls for software developers to embrace a new way of developing management software.This is the impetus for the TM Forum's New Generation Operations Systems and Software (NGOSS) initiative.The NGOSS initiative aims to deliver a framework for rapid and flexible integration of Operation and BusinessSupport Systems in telecommunications and throughout the wider communications industry. Key areas of theNGOSS initiative are:

- Definition of the Next Generation Business Process Framework

- Definition of a standard set of Processes for the Information and Communications Services Industry

- Definition of the Systems Framework upon which these business solutions may be built

- Practical implementations and live demonstrations of these solutions

- Creation of a resource base of documentation, models, code and training materials to support theTM Forum members in their own development of NGOSS components

- Development of an industry compliance program to certify solutions and products for compliance tothe NGOSS Specifications.

1.2 Goals and Objectives

This document will describe the major concepts and architectural details of the NGOSS architecture in atechnologically neutral manner. This does not prescribe a single new technology – rather, it allows for a federationof different technologies, each of which offers particular advantages at the business and system levels. Inparticular, it enables business concepts and principles to drive system design and architectures. This may beimplemented using currently available distributed systems information technologies. Critical to this process is thesharing and reusing of common data and information.

The goal is to define a component based, distributed systems architecture and an associated critical set of systemservices that this architecture requires.

Stakeholders will make different implementation decisions about the use of specific information technologies in themanagement products they build or procure. Therefore, this document describes the principles and systemservices that should be adopted in these new systems in a technology neutral form.


2 �TeleManagement Forum 2002 TMF 053 v2.5

This document enables the mapping of specific information technologies onto the NGOSS technology neutralarchitecture. The specification of a technology neutral architecture enables different technologies to be used tobuild coordinated management systems that control one or more OSS components. It also enables the fastadoption of new information technologies as they emerge.

This initiative will provide an industry roadmap of common implementation principles to be adopted by allstakeholders in the value chain. The end objective is for the management systems integration of ‘off the shelf’software to be accelerated, leading to reduced time to market. It is equally important to provide the ability tochange and update installed NGOSS systems in accelerated timescales.

1.3 The Road to NGOSS

NGOSS is a set of guidelines and specifications for the industry to build software in a more structured andcomplementary way, based on industry experience and previous and ongoing TM Forum activities. The TMForum projects, described below, have established a good basis for the NGOSS architecture. This enables it to bewell defined and yet sufficiently flexible to cope with emerging and as yet undetermined technologies:

� The Application Component Team [ACT] project developed the concept of OSS building blocks thatcommunicate via well-defined contracts1. It identified separate tiers for Human Interaction, ProcessAutomation, and Enterprise Information Building Blocks. The ACT project has completed its work, havingdelivered TM Forum document GB909 Part 1, which defines a set of generic requirements for informationbuilding blocks. Its findings are being incorporated into the NGOSS architecture framework as appropriate. Inparticular, the architectural requirements for building blocks (which correspond to NGOSS components) andcontracts as well as requirements specific to Process Automation and Enterprise Information building blocksare being incorporated.

� The enhanced Telecom Operations Map™ [eTOM] presents a high-level overview of TelecommunicationsOSS business processes. This is described in TM Forum document GB921, and provides the analytical basisfor business process integration across the OSS space. The eTOM builds on, and supercedes, the popularTM Forum Telecom Operations Map (TOM) document (GB910).

� The Systems Integration Map [SIM] project is concerned with partitioning OSS functionality into standardmanagement domains and business objects, in order to facilitate interchange of information between separatecomponents within an OSS. The SIM deliverable, GB914, is a reference map for specifying OSScomponents.

� The Application, Specialization and Integration of System Technologies (ASIST) team has been identifyingcandidate distributed systems technologies to support the architectural concepts presented by the ACT teamin GB909. The ASIST work is now being incorporated into the technology-specific work of NGOSS.

� The Catalyst programs produce working demonstrations of technology integration using the NGOSSspecification according to TM Forum principles. These projects, based on leading OSS products, validate anddemonstrate existing TM Forum work, as well as identify areas of particular difficulty for ongoing integrationwork. Previous Catalyst projects have developed practical solutions to common OSS integration problems,most notably in the areas of business process abstraction, the use of some common information models, andthe use of common communications and directory services. The Catalyst program is complementary to, andmigrating towards, NGOSS style development, with the findings of one activity incorporated into the other onan ongoing basis.

Each of these projects is described in detail elsewhere (see references).

1 Contract as defined in [SZY99]: Specification attached to an interface that mutually binds the clients and providers(implementers) of that interface. Contracts can cover functional and non-functional aspects. Functional aspects include thesyntax and semantics of the interface. Non-functional aspects include quality –of-service guarantees.



1.4 Program Implementation

The NGOSS program is a significantly complex set of activities. It has consequently been planned as a set ofphased deliveries. The outputs of each phase are planned to be implemented in Catalyst projects and fed intosubsequent phases, to ensure lessons learned from implementation are incorporated into future guidelines andspecifications.

As the program progresses, it is expected that an increasingly comprehensive library of documentation, models,contracts and reference implementations will be built within the TM Forum and made available to the industry forimplementation and incorporation into products. This will enable the faster delivery of NGOSS-compliant products,thus enabling the stakeholders to gain the benefits of a more homogeneous, yet flexible, OSS environment.

1.5 Phases of Delivery and Roadmap

NGOSS will be delivered to Industry through a number of Phased Releases. An overview of what is to becontained in each Phase of Release will be maintained in the NGOSS Roadmap. This is kept up to date as a livingdocument on www.tmforum.org.

1.6 Stakeholders in this Document

This document is intended for use by a number of stakeholders, within which there are likely to be a number ofdifferent roles, or users of, the document. The stakeholders presented below are not intended to be all inclusive,and it is accepted that other uses for this document will be found.

These usage scenarios are based on the individual stakeholders who may use various parts of the NGOSSspecification(s) for their own goals. These stakeholders are as follows:

� Service Providers (SP)� System Integrators (SI)� Independent Software Vendors (ISV)� Network Equipment Providers (NEP)

Note: a detailed analysis of the business case benefits for and the requirements of each of the individualstakeholders shown above is contained in the following TM Forum documents

� TMF 051 (Business Case) [BIZ]� TMF 052 (Requirements) [REQ]

A further discussion of the roles that workers within each of the NGOSS Stakeholders may perform can be foundin section 3.0 of this document. Workers within these roles will find a number of different uses for this document,depending on the internal organization and processes of a stakeholder.

1.6.1 Document Use by a Service Provider

The NGOSS architecture will provide service providers with the basis for a flexible OSS solution that will be able torapidly evolve to meet the future requirements and be able to manage multi-vendor, multi-technology networks.The NGOSS architecture will enable service providers to choose the 'best fit' management components for theirbusiness and enable management capability to grow along with the business, while protecting its OSS investment.

With the emphasis moving towards managing the timeliness and quality of the services which the networks deliverrather than blindly managing the networks components, the need to be able to aggregate information from acrossall of the management functions will become paramount. The NGOSS architecture will enable easiercommunication across multiple management components, thus enabling the easier sharing of data from themultiple sources. This document will provide the Service Provider with a fundamental understanding of the



architecture upon which their OSS needs to be built. By understanding that architecture, the Service Provider cantake full advantage of all the features and services that NGOSS based systems can offer.

1.6.2 Document Use by a Systems Integrator

This architecture document is of key interest to system integrators anticipating the new generation of operationaland business systems. Integrating applications from the existing and previous generations of support systemstypically characterized by closed, frequently monolithic architectures with multiple private copies of data anddiffering (often proprietary) technologies, meant forcing an inter-application communication. The NGOSSarchitecture with its support of a Shared Information and Data (SID) model, open interfaces and a commonsystems framework will enable system integrators to concentrate on the delivery of a completely integratedbusiness solution rather than the narrower focus of trying to get a few applications to communicate.

Additionally, the basic concepts of the NGOSS architecture will mean a change in the methodology used forintegration. Being able to assume that the management components will share common data formats andframework services as defined in this architecture, the system integrator will concentrate much more on the flow ofthe business process and the policies affecting the flow.

This document will provide system integrators with information needed to plan for the skills and knowledge neededto work with both ISVs and NEPs delivering NGOSS based solutions.

1.6.3 Document Use by an Independent Software Vendor

The NGOSS Architecture document will be of critical importance to ISVs that are interested in competing in theOSS marketplace of the new generation networks. Regardless of whether the ISV is interested in providing animplementation of basic platform or middleware services, operational management applications, or both; thisdocument will provide the blueprint for success. As the service providers move towards the deployment of thenew generation networks, their demand for component oriented management systems software, based on theprinciples and architecture of the NGOSS, will be the rule not the exception.

In the case of an ISV focused on the basic platform or middleware services (termed Framework Services in thisdocument) the NGOSS Architecture document and the NGOSS Requirements document will provide theinformation that is typically developed over months, if not years. In the case of an ISV working in the managementapplications market, this document will provide the key to understanding and leveraging the systems servicesavailable to support them.

1.6.4 Document Use by a Network Equipment Provider

For the network equipment provider this document will provide insight and understanding of the managementenvironment into which their equipment will be deployed. Having that insight will enable them to structure and buildtheir own equipment management systems in a way that more easily integrates with the other stakeholders in thevalue chain. As ease of integration of operations management systems is increasingly a significant networkequipment procurement factor, meeting the industry need in this area will become critical to equipment salessuccess.



1.7 Organization of This Document

This document is organized into multiple sections. Each section is briefly described below

� Section 1.0, Introduction

This section provides an executive overview of NGOSS, the work leading up to this document and theroadmap for progressing NGOSS. It also summarizes the utility of the document to each of the fourmajor stakeholders: service providers, system integrators, independent software vendors and networkequipment providers.

� Section 2.0, Principles of the NGOSS Architecture

This section provides a general overview of the general architectural and design principles thatcharacterize the NGOSS. It is these principles that are supported and realized by the architecturaldefinitions described in later in sections.

� Section 3.0, Roles, Responsibilities and the Use of this Document

This section provides an overview of the roles that are expected to use the NGOSS architecture. Itlists their needs in relation to this document, and others in the NGOSS document family.

� Section 4.0, Architecture and Realization of the Principles

This section describes the fundamental concepts behind the NGOSS architecture and highlights thecharacteristics, which distinguishes this architecture from others built using distributed components.This section also presents the overall NGOSS Architecture. The NGOSS Architecture includes anumber of features drawn from other industry standard architectures and the computer science fieldof distributed system theory.

� Section 5.0, References

This section contains a list of references used in the formulation of this document.

� Section 6.0, Open Issues and Assumptions

This section contains a list of Issues and Assumptions that are seen as critical to the understanding ofthe contents of this document.

Additional information will be covered, relative to this document through the creation and issuance ofamendments. The first two amendments are

� TMF053a: Glossary� TMF053b: Contracts

Future amendments covering such issues as security, policy, directory enabled networking, and others areexpected to be released in the future.



2 Principles of the NGOSS ArchitectureThere are a number of principles that have been adopted for the NGOSS architecture that represent industry bestpractice. The NGOSS integrates these principles into a coherent architecture for the development of managementsystems. This section of this document serves to introduce these fundamental concepts; discussion that is moredetailed follows in section 4 of this document.

2.1 Separation of Business Process from Component Implementation

An NGOSS System is characterized by the separation of the hard coded behavior of components from thesoftware that automates business processes across these components. An NGOSS system is furthercharacterized by externalized descriptions of behavior expressed in a technology-neutral manner. While there areseveral ways to implement this separation, the NGOSS uses the concept of different types of information and datamodels.

Examples of this are:

� The external description of a service is separated from one or more specific implementations through amechanism called a “Contract”. Contracts enable different aspects of the business and system views ofan application to be integrated through the use of business and system models. For instance, mostbusiness process models are in fact sequenced calls to business service contracts.

� A business process is represented by an executable meta-language description, which describes the flowof execution between service-providing contracts.

� System behavior is controlled through the use of different types of management policies

A business process model may invoke lower level business process models. This means that a business processstep that a service provider desires to automate (e.g., verifying that the network exists to pre-provision a desiredservice) may be made up of one or more lower level interactions with different system components that providethat service.

NGOSS specifies that the business process models are distinct from the systems and processes that they control.This means that the business process steps can be rearranged or altered independently of any change to thecomponent systems. Ideally, the underlying systems interactions are then automatically rearranged by theprocess model execution system. However, an NGOSS system can have one or more translation steps from theprocess model into an implementation technology if necessary.

2.1.1 Contract Defined Interfaces

An NGOSS system is characterized by the fact that all software entities that provide services to other entities doso through a Contract defined interface. This Interface is a precise specification of the service (e.g., a prescriptivemodel) with the following characteristics:

� A description of the service to be provided

� The metadata used to describe the contract and its interfaces

� The pre-conditions under which the service is provided (i.e., the set of conditions that must be satisfied inorder to invoke the service with reasonable assurance of its successful completion)

� The post-conditions, which define the state that the system is left in if the pre-conditions are met and noexceptions are encountered

� The exceptions that can be encountered; an exception occurs if the pre-conditions are satisfied, but thepost-conditions cannot be met



� The behavior of the service

Contract defined interfaces are generally divided into two types. The first is a business service contract, which areused to specify activities in support of the automation of the service provider’s business process(es). The secondis a framework service contract, which are used to perform ancillary (e.g., non-business-activity-specific) servicesthat are used by the software entities to carry out their operations and integration with the rest of the NGOSSsystem.

2.1.2 Policy Enabled

The NGOSS system architecture is policy-enabled. A policy-enabled system is defined as a system that isarchitected to provide support for policy based management, without requiring the presence of a policymechanism in the implementation of said system. Policies provide statements that define objectives as well asmethods that govern behavior within the system. These policies may link one or more of the business, system(operational), and implementation views of the NGOSS system.

Policy is a mechanism to control system behavior. This is implemented in such a way that the underlying systemhas no direct knowledge that policy is being enforced. Policy is implemented through the definition of a set ofpolicy rules that represent controlling behavior. For example, “All Users requesting Service X must have role Y”, or“All Users within Geographic Region G can only request orders of type T”. Behavioral control over entitiesmanaged by policy may be refined, producing nested policies. For example, the policy: “All Users withinGeographic Region G1 can only request orders of type T1” restricts users in area G1, which is a part of G, to onlyrequest orders of type T1, which is a subtype of T.

A policy service has three main uses. First, it may be called upon to validate something using a specified policy(such as a user’s access privileges, as specified by a security policy). Second, it may be used to determine whatpolicy applies to a given condition. Finally, it may be called upon to determine if there is a conflict betweenapplicable policies.

2.1.3 User Roles and Security

An NGOSS system is characterized by the existence of a single logon for any individual user. This grants theNGOSS user access and privileges to use NGOSS services defined in their user profile.

2.2 A Common Communications Vehicle

An NGOSS system is characterized by the existence of a communications service (e.g., a “communications bus”)or some other form of common communication, which is used by all software entities to communicate with eachother. Each communications service offers one or more different transport mechanisms. There may be more thanone such communications service within a given system implementation, and these services may representdifferent technology-specific mappings.

2.3 A Shared Information and Data Environment

An NGOSS system is characterized by the usage of a single information model, called the Shared Information andData (SID) model. The information model is designed to be more than just a standard representation of data – italso defines semantics and behavior of, and interaction between, managed entities. This set of information, allprovided in a standard representation using standard data types, is used to describe domain information (e.g.,orders, network service and configuration definitions, and so forth) in an NGOSS system. The representation ofthe information is described in GB922 and its addenda, and consists of business and system views of information.This takes two forms: UML class diagrams and a data dictionary that defines the syntax, semantics and use ofclasses, attributes and other elements of the SID. This information is shared and reused by NGOSS systems



through contracts. The business view grounds the contracts in fundamental requirements, and the system viewprovides contract details (e.g., parameter values, pre- and post-conditions, and exceptions.

Contracts are not strictly part of the SID. However, it is expected that contract specifications use information in theSID. It is important to note that in the case of contracts which require an information format that is inconsistent withthe common data representation, mediation is used to enable the contract interface to be mapped to a standardinterface using information defined in the SID.

2.3.1 Data Stewardship

An NGOSS system is characterized by the stewardship of distributed enterprise data. Stewarded data has twofundamental characteristics that differentiate it from non-stewarded data.

� There is a clearly identified “steward”, that is an official repository of record, which is responsible formaintaining the data. This is not meant to imply that NGOSS uses a single and/or centralized repository.NGOSS systems are likely to have multiple repositories, some of which may be distributed, in order tobetter effect communications.

� There is a clearly identified “owner”, which controls who can make changes to the data when and how.This does not preclude the existence of shared data that are stewarded by multiple “owners” (e.g., a multi-master directory) – in the case of such systems, there is still a clearly identified “owner” process thatdecides which process (of possibly many that are trying to write the same object with different values) willultimately succeed in writing its value to the exclusion of all others.

A data steward also supports a control mechanism, so that a service can be informed of changes to critical,shared data.

The architectural term for providing stewarded data is information provider.

2.3.2 Information Adaptation

While the NGOSS architecture describes a neutral and uniform framework of services, components, and a sharedinformation model, real-world deployments may not represent or be able to implement this ideal. For this reason,the NGOSS architecture includes the concepts of “adaptation” and “mediation”. Adaptation is a mechanism toconvert one entity that has a particular syntactic representation to another entity that has a different syntacticrepresentation, in order to enable interoperation of the two. Effective interoperation may still require the applicationof a mediation layer.

2.3.3 Information Mediation

Mediation is the process of translating from one level of representation and/or abstraction to another level ofrepresentation and/or abstraction. Often, mediation of two entities is achieved by translating the two entities to acommon third form (e.g., the SID defined in GB922). Mediation enables entities to interoperate in a looselycoupled way. For example, this allows contracts that do not talk natively to the SID to be mediated to it.

2.3.4 A Registry of Run-Time Information

An NGOSS system is characterized by the existence of a registry that records information used during systemexecution, such as the following:

� Naming services enable logical names and/or aliases to be assigned to a manageable entity that rendersa service



� The naming service then enables the subsequent access of that manageable entity by its names and/oraliases

� The naming service provides the ability to bind attributes to a named object

� The Registry also supports a Trading Service, which enables objects to be accessed, selected andlocated without knowing the precise name of the object (i.e., the attributes are used as tradingparameters)

� The location and state of all managed nodes in the managed environment.

� The location and state of all management nodes in the environment (e.g., how services and devices aremanaged)

� The location and state of all management entities in the environment (e.g., people and/or processes thatcan manage certain devices and services)

� The location and state of “models”, which are externalized descriptions of content and/or behavior, asdescribed below. Two important types of models are Contracts and Policies, each of which are definedfurther in sections 4.3 (Contracts) and 4.8 (Policies).

� Information that supports the use of the Contracts and Policies, such as the location and state of allContracts that are implemented by software entities in the system, or the set of user and role informationthat is used by different Policies. The NGOSS SID defines this information.

The existence of a single logical registry is assumed, regardless of whether it is physically implemented as asingle or a distributed system.

2.4 Supporting Architectural Principles

This sub-section briefly discusses the main architectural principles that support the following three core principlesof an NGOSS system:

� Separation of business process from software component,

� A common communications vehicle, and

� A shared information and data environment.

2.4.1 Loosely Coupled, Scalable Distributed System

In general, a contemporary OSS can be described as tightly coupled, loosely integrated systems comprising anumber of monolithic applications, each offering a set of services in a particular application domain. Thesesystems are loosely integrated via mediation gateways. An NGOSS system is characterized by the fact that thesoftware entities (also called “components”) within it are “loosely coupled” and distributed. This means thefollowing:

� The software entities run independently of each other and any operation of one does not necessarilyinterrupt or affect any other.

� The software entities are capable of executing in a computing node in any configuration of computers thatare connected together by a common communications vehicle.

� Software entities may be added or removed without affecting the behavior the other software entities

� The combined behavior of the system is a function of the individual software entities that comprise thesystem.

� Information used by multiple software entities belongs to the consolidated enterprise information model.

This approach enables componentized and/or distributed applications to be built to perform various OSS functions.



2.4.2 Framework Services

An NGOSS system is characterized by the existence of a number of ancillary framework services that are used tofacilitate the operation of the components. Not all framework services have to be present for the system to beconsidered to be an NGOSS system. Two of these framework services have been introduced already: a commoncommunications vehicle (section 2.2) and the registry (section 2.3.4). Some of the others include:

� InvocationThe service that allows one software entity to invoke a service provided by another software entity,according to the rules of the Contract for that service and other relevant Policies.

� Shared Information and Data ManagementThe services that steward, or manage read and write behavior against information that is needed oroperated on by more than one component.

� TradingThe services that finds specified registry contents (typically Contract implementer lists) according toattributes rather than specific names.

� PolicyThe services that define, manage and execute policy definitions and ensure their application. These maybe implicitly or explicitly called upon to validate something against a policy (such as a user’s accessaccording to a security policy), or may operate on an autonomous basis, monitoring and alerting (such asassuring that a given level of service invocation capability exists within the system) other entities in theNGOSS system.

� SecurityA set of mechanisms that enforce authentication, authorization, accounting and auditing.

All framework services are available through their Contract specifications.

2.5 Separation of “Technology Neutral” and “Technology Specific” Architectures

An NGOSS system is characterized by the fact that all contracts, whether they concern business services orframework services, are documented in a specification that is neutral with respect to any specific implementationtechnology. There will be a separate set of documents produced, in the Technology Specific part of the NGOSSprogram, which will describe the mechanism for mapping the technology neutral architecture and contractspecifications to specific technologies for the purposes of implementing and deploying an NGOSS system.

These technology specific mappings are expected to leverage industry standard frameworks (e.g., frameworksthat support distributed computing, component-based architectures, etc.). Hence NGOSS deployments willbenefit from the efforts to develop said frameworks.

2.6 Compliance and Certification

While not strictly core principles of the NGOSS architecture, compliance and certification ensure that anapplication claiming compliance to NGOSS implements and complies with the fundamental principles of NGOSS.For the NGOSS architecture to achieve ubiquitous deployability, it must be possible to measure the degree ofcompliance that any given implementation of the NGOSS architecture exhibits. The particular services that aredeployed within an NGOSS based system are not the measure of its compliance. Instead, compliance ismeasured using the contracts that are made available by the deployed components within a system as well as theconformity of the infrastructure sustaining that system to the NGOSS core principles. That is to say, compliance isa metric of the contracts used in and by the system and its infrastructure, not of the system functionality as awhole.



A deployment of an NGOSS system need have only those components that contain implementations of theservices that are required to meet the needs of the system operator. Such a deployment represents a completedeployment of an NGOSS system. However, it is important to note that what appears to be a completedeployment for one system operator may in fact be a partial deployment (relative to needed services) for a secondsystem operator.

Certification requirements will be established by the TeleManagement Forum “NGOSS-Powered™” industry-widecompliance program steering team. These requirements are considered to be out of scope for this document;instead, they will be specified in the TMF 050 document series.



3 Roles, Responsibilities and the Use of this Document

3.1 Use of this Architecture by Architects, Designers and Implementers

This section identifies technical roles that users of this document have, and their associated responsibilities. Thiscan be used in defining the lifecycle of architectural concepts as seen by these roles. Such a role/lifecycle modelprovides the reader with further insight into the underlying rationale of these TNA concepts, why these conceptsare really needed and how they all fit together.

The NGOSS architecture represents a facility for constructing distributed systems that support business processesassociated with managing information and communications services domains. It provides a technology-neutralway of describing the structure of these systems, composed from a series of components making use oftechnology-specific implementations of basic services. This is similar to the organization of other distributedcomponent implementation models (such as CORBA or Enterprise Java Beans), and thus the responsibilitiesinvolved in the design and development of NGOSS systems is similar to the responsibilities described for othersimilar types of systems.

There are distinct roles associated with the design of the infrastructure, design of the components, and design ofthe system, each with their own set of responsibilities. These are described in more detail below:

� A Business Process Planner: This responsibility focuses on the definition of a business process flow.

� A Business Process Analyst: This responsibility acts as an intermediary between the Business ProcessPlanner and the Domain Analyst. 2

� A Domain Analyst: This responsibility focuses on defining an Analysis Model for a scoped area ofmanagement related problems for which NGOSS business components are sought.

� A Contract Designer: This responsibility focuses on the design and publishing of Contracts that may be sharedand reused by others

� A Component Builder: This responsibility focuses on the analysis, design, implementation, testing and releaseof component-based software. The output of this role is a set of components that can be used by any NGOSSsystem.

� A Systems Builder: This responsibility focuses on analyzing the business needs of a system and designing,implementing and testing a solution that meets those needs.3

� An Infrastructure Builder: This responsibility focuses on delivering platform systems that provide theFramework Services needed by Business Components.

� A System Administrator: This responsibility focuses on monitoring and managing a system containingcomponent software in order to ensure it operates within required operational parameters.

2 The Business Process Analyst has an in-depth knowledge of the existing NGOSS deployment as well as understanding of theoverall business operation into which the new process will fit.3 This role will aim to make maximum use of existing contract specification and component software. The system builderselects from the available set of components, not necessarily aware of the internal structure and implementation of saidcomponents. To the extent possible, the relevant characteristics of the component are described through the contractspecifications associated with the component.



� A System User: This responsibility focuses on a set of business tasks that involve using services offered by asystem containing component-based software. A system user is primarily concerned with the operation of thesystem, rather than how the system is constructed. 4

� An NGOSS Component: This responsibility focuses on providing services via its contracts, for which it mayneed to interact with other components.

The following figure graphically illustrates the static relationships between roles (depicted as UML actors) in theNGOSS Methodology:

D omain Analyst

Contract Designer

C ompo nent Bui lder

NGOSS S takeholder

Network Equipme nt Provider

Independant Software Vendor

Se rvice P rovider

Systems Integrator

O rganization

Actor

1..n1..n

Subscriber

1.. n1.. n

Service End User

Business Process P lanner

Business Process A nalyst

System Builder

System User

Infrastructure Builder

NGOSS Worker

System Ad ministrator NGOSS C omponent

Figure 1. Relationships between Actors

3.2 Usage and Methodology

A business process planner defines a business process that is given to a business process analyst to developrequirements. These requirements are then given to a domain analyst, who with help from the business processanalyst, develops a domain analysis model. The domain analysis model is used to create the specifications forcontracts, contract sets, and shared information and data objects. The activity of creating contract specifications,contract set specifications, and shared information and data specifications, is depicted in the following figure.

4 There are two types of system users: end users and management users. The end users are concerned with getting thebusiness results from the system, and the management users are concerned with maintaining the reliability and availability ofthe system to the end users.





Define Business Process

process: ProcessModel

[baselined]

D efine Requirements

requirements: RequirementsModel

[baselined]

Develop Domain Model

model: DomainModel

[baselined]

Create Specifications

tncs: ContractSpecifcation

[bas elined]

: Contra ct Desig ner : Domain Analyst : Busines s P roc ess Ana lyst : Busines s Proc ess Planner

Figure 2. Creation of a Technology Neutral Contract Specification

The deliverable output of the Create Specifications activity is a technology neutral contract specification (otheroutputs, such as refinement of the information and data model specifications, are not shown in the above figure inorder to keep it as conceptually simple as possible). The creation of the technology neutral contract specificationis further decomposed in the following figure.



Define Exceptions

Define Behavior

Assign Name

Define Parameters

Define Conditions

Figure 3. Decomposition of the creation of a contract defined interface

In Figure 3, the “Define Conditions” subtask is used to define pre- and post-conditions that are necessary toensure that the environmental constraints and behavior of the interface are correctly defined. All of these subtasksinvolve the definition of shared information and data.

Instances of shared information are termed information objects. Information objects are used to representdifferent aspects of a managed entity. These include definition of the basic characteristics of the managed entity(in the form of attributes), basic operations on that entity (in the form of methods), and how the entity interacts withother managed entities (in the form of relationships). In addition, the behavior of a managed entity can bemodeled. In NGOSS, we abstract this behavior to a contract. Thus, the parameters (both request and response)as well as any exceptions that may be generated during the execution of the contract implementation are all keyelements that are modeled. This is done in the system analysis views of the SID.

The definition of the shared information needed by a specific contract may (and is in fact encouraged to) reuseexisting shared information definitions. Shared information definitions are contained within the SID. It is assumedthat the reuse of shared information definitions will be accomplished by one of two mechanisms. Thesemechanisms are by-reference and by-copy-and-extend. In the former case, the definition of information containedwithin a specific shared information model is referenced by name. In the latter case, the definition of sharedinformation is copied from an external shared information model, into a local shared information model, and thenreferenced by name.

The third of the parallel subtasks, define conditions, provides for the determination of the pre-conditions (if any)that must exist prior to the invocation of the contract, and the post-conditions that an implementation of thecontract must leave the system in once the behavior defined by the contract specification has been performed. Itis further asserted that the specification of both the pre-conditions and post-conditions should be restricted toinformation that the contract specification would have direct knowledge of and authorization to access.



The actual definition of the Contract and the Shared Information associated with it is ultimately dependent on theexistence of a number of models. The following figure depicts the static structure of the relationships betweenthese models. Furthermore, it is inevitable that an NGOSS Worker will determine that a number of contracts arerelated in some logical fashion. A logical relationship between contracts is represented using the concept of acontract set. This concept is also graphically illustrated in the following figure.

DomainModel

Model

RequirementsModelProcessModel

ContractSet C ontract2..n2..n

InformationObject

Figure 4. Static structure of relationships between Models, Contracts, and Contract Sets

Contract sets are logical groupings of contracts that are viewed by a system user as being related in somefashion. The architecture places no constraints on the relationship that is used to determine which contracts areincluded in a specific contract set. For example, a single specific contract may be referenced by multiple contractsets. A valid contract set is assumed to reference a minimum of two contracts.

The contract specification will be used in various manners, once the specification has been baselined. However,from an architectural perspective, discussion of such uses is considered to be out of scope, and therefore is notpursued within this document. Please see TMF053b for more information.



4 Architecture and Realization of the PrinciplesThe NGOSS system is built from a collection of loosely coupled components, each of which performs one or moreBusiness Services. The Business Services are supported by a collection of well-defined loosely coupledcomponents, each of which performs one or more Framework Services. The Business Services available will varyfrom one NGOSS deployment to another, while the framework services are (relatively) consistent betweenNGOSS deployments.

Information and data models (in the form of the NGOSS SID) are used to represent:

� attributes and operations of a managed entity

� relationships that a managed entity has with other managed entities in the NGOSS

� behavior, in the form of semantics that govern how a managed entity is meant to work

� meta-information within NGOSS components as well as across NGOSS components.

Section 4.1 discusses the concept of NGOSS Structure using a concept called architectural views. It introducesthe control flow diagrams that provide relationships between NGOSS components, with respect to time. It alsodiscusses meta-information representation and modeling. Modeling is discussed in Section 4.2.

In order to describe the behavior of a component in an abstract and technology-neutral fashion, the interface foreach Service implemented by an NGOSS Component must be represented by Contract Specifications. TheseContract Specifications form the “declarative glue” for integration with other NGOSS components. The ContractSpecifications do not change with technology specific implementations. Section 4.3 discusses the NGOSSContract Specifications.

In order to register and locate the Contracts and their component implementations, Distribution TransparencyFramework Services play a significant role in NGOSS architecture. Section 4.4 discusses the DistributionTransparency Framework Services, such as Registry and Trading. These provide the services of naming, locatingand trading components in the distributed NGOSS environment.

Section 4.5 provides details on NGOSS components as well as legacy components.

NGOSS defines the role of a conductor/coordinator. This role is fulfilled by the Process Management FrameworkService, which coordinates activities spanning across the Business Services. Process Management FrameworkService is discussed in Section 4.6. This acts as a conductor/coordinator of activities.

NGOSS architecture is based on the powerful concept of Shared Information. This enables interaction betweenNGOSS components within and across jurisdictions. Shared Information Management Framework Service isdiscussed in Section 4.7.

NGOSS architecture is policy-enabled. The Policy Management Framework Service acts as a supervisor ofoperations being carried out by other NGOSS components. Policy Management Framework Service is discussedin Section 4.8.

The technology-neutral architecture provides a technology-neutral or homogeneous model of the system,represented via the Contract Specifications and Registry contents. However, implementations of the NGOSSsystems may be heterogeneous, presenting information in different ways “on the wire” (meaning transport on thecommunications service). Disparate NGOSS system implementations are bridged using the AdaptationFramework Service discussed in 4.9.



4.1 Architectural Views

NGOSS structure consists of the elements of the architecture, their dependencies and relationships. The controldiagrams describe the interaction between the NGOSS components with respect to time. The NGOSSarchitecture is model-based. That is, information in the NGOSS is represented via well-defined models that caninteract and be shared with each other.

4.1.1 Structural View

Figure 5 shows the structure of NGOSS architecture and the relationship between Basic Framework Services,Policy Framework Services and Business Services. The Basic Framework Services provide functionality at thelowest level. These are used by Business Services to satisfy NGOSS Contract Specifications.

Business ServicesPolicyFramework

Services

Basic Framework Services

Communications Invocation Others...RegistrySecurity Service

Systems Management Service

SecurityPolicy Doc

ManagementPolicy Doc

ProcessDef Doc

ProcessMgr

Figure 5. Structure of NGOSS Architecture

Note the use of the Process Manager Framework Service to integrate the Business Services. Also note thatanother pair of Business Services communicates without using the Process Manager. The actual ProcessDefinition is located in a “model document” which is being used by the Process Management Service, just as theSecurity Policy and the Management Policy documents are being used by their particular Framework Services.

The Basic Framework Services may also be used by the other Services. For example, the Process Definitiondocument would actually be found by fetching it from the Registry Framework Service. Likewise, each use of theInvocation Service (by a different user) would call upon the Security Service to determine if the requestedinvocation should be permitted.

The NGOSS architecture specifies two fundamental classes of Services:

� Business Services – these provide elements of business functionality which are presented throughContract Specifications



� Framework Services – these provide the capabilities needed to support the patterns of interactionbetween components implementing Business Services. Examples include Process Management,Transaction Support, Security, etc. These framework services are also provided through appropriatecontract specifications.

The Framework Services include communications, registration, lookup and trading, invocation, shared datamanagement and policy management, among others. These services have been drawn from the analysis of thesupport requirements of typical Business Services, and from the services typically provided in distributed systemframeworks.

Framework Services may be further sub-divided into those that are mostly concerned with supporting the needs ofa distributed system and those that are more directly associated with supporting business services. Thischaracterization is shown in Figure 6. In general, the business support services are more important in an NGOSSenvironment.

Transaction

Processing

Naming Directory Trading Invocation

Business Service Support

Distribution Support

ProcessManagement

Shared Information

Figure 6. Decomposition of Framework Services



4.1.1.1 Artifact Aspect

From the architectural perspective, there are four tangible artifacts of interest. These are

� The Contract Specification,

� The Contract Implementation Specification,

� The Contract Implementation, and

� The NGOSS Component

The contract specification is the technology neutral definition of functionality, while the contract implementationspecification is the API reference that is used by developers to either code the contract implementation, or makeuse of a contract implementation. Finally, an NGOSS Component is the unit of packaging for contractimplementations.

ContractSpecification<<document>>

Contract Implementation Specification<<document>>

<<refine>>

ContractImplementation<<code>>

<<implements>>

NGOSSComponent<<executable>>

2..n2..n

Figure 7. Tangible Artifacts with the NGOSS Technology Neutral Architecture



4.1.1.2 Registry Aspect

The NGOSS Registry provides for services and functionality needed to support location transparency in thesystem. The entities within the Registry that are considered to be interest from an architectural viewpoint are

� The NGOSS System Registry,

� Entries that identify important Shared Information, which includes Contracts and Policies,

� Contract Registrations,

� Component Registrations, and

� Contract Implementation Registrations

The NGOSS System Registry provides a repository (assumed to be a single logical repository, possibly comprisedof a federation of separate physical repositories) that provides instructions on where the entities specified aboveare located and how they can be accessed and/or invoked. The access and invocation of these entities is donethrough the naming, directory, and trading framework services. The NGOSS TNA assumes that the registryenables different clients to find and invoke various shared NGOSS components.

An important means of accessing shared NGOSS information uses the following principles:

� technology neutral information is found by referencing the appropriate contracts

� technology specific information is found by referencing the appropriate contract implementations

� contracts are a generic mechanism to find and/or invoke specific components

Furthermore, it is assumed that the Registry will also provide access to managed entities in the shared informationand data models that need to be shared. For example, common policy information that is shared across systemsmay be found and accessed using the Registry.

It is further assumed that NGOSS components will re-use the basic functionality of the Registry in an ad-hocfashion. This ad-hoc reuse includes such operations as making extensions to the SID available to other NGOSScomponents. Another example is to store proprietary information via the NGOSS framework naming and directoryservices.

The Registry is assumed to be of importance only during discovery operations. That is to say, once the definitionof a piece of shared data has been found, and its provider or binding to a contract implementation has occurred,the Registry is no longer needed. This holds until such a time that the binding and/or information definition isdiscarded by the Registry client and must be re-established.



ContractImplementationRegistation<<metadata>>

NGOSSComponentRegistration<<metadata>>

PolicyEntities

ContractRegistration0..n0..n

+dependsOn

NGOSSSystemsRegistry<<control>>

0..n

0..n0..n 0..n0..n

0..n

SharedDataEntities

0..n 0..n0..n 0..n 0..n

0..n

Figure 8. Architectural entities to support location transparency

4.1.1.3 Runtime Aspect

Finally, a basic understanding of the key entities from a runtime point of view must be established in order tounderstand the context in which services will be delivered. The following entities have been identified as beingcritical to the creation of a complete runtime view of the architecture.

� Component Execution Environment

� Contract Implementation Instance

� Interface Implementation Instance Descriptor

� Client

The Component Execution Environment is that portion of the system that provides the capability to create ContractImplementation Instances from the contract implementations contained within NGOSS Components. A ContractImplementation Instance can be thought of as being a process or task that is executing on a computing platform.The Interface Implementation Instance Descriptor (hereafter I3D) represents a remote invocation handle that isused by a Client to request that a service be performed. By way of example, in a CORBA based NGOSSdeployment, the I3D is an IOR; in a Java Jini environment, it would be the client proxy reference.



InterfaceImplementationInstanceDescriptor<<runtime metaclass>>

ContractImplementationInstance<<runtim e software arti fact>>

Cl ient<<runtime softw are arti f act>>

ComponentExecutionEnvironment<<runtime software arti fact>>

Figure 9. Key runtime abstractions in the NGOSS TNA

4.1.2 Control View

Figure 10 shows a Control Diagram, indicating the typical sequence of interactions that occur betweencomponents in an NGOSS system. The labeled arrows indicate the sequence of messages that flow as theProcess Manager invokes a Business Service that in turn depends upon a Framework Service.

RegistryService

Frame-work

Service

Frame-work

Service

Frame-work

Service

ProcessManager

Componentimplementing

Business Service

Information Exchange

requestreply1

2

3

4

Figure 10. Control diagram illustrating invocation

This diagram makes it clear that the services (and the components that implement them) are decoupled via thecommunications service. In order to invoke an operation, a component creates a request and sends it via thecommunications service. The response comes back in a similar way. It is important to note that the exact natureof the NGOSS communication services is a technology specific dependency. That is to say, in some technologyspecific implementations, the NGOSS communication services may be supplied by a specific identifiablecomponent, whereas in others, it may be an endemic functionality provided transparently by the technology.

This control diagram simplifies a number of steps, which are shown in more detail in later diagrams, such aslocating and requesting the target service, providing the proper transport semantics of the request/replyinteraction, error handling, and the role of the contract specification when the target service is invoked.



4.1.3 Summary of View Concept

There is more to NGOSS than an abstract architecture, however. A high degree of technology-independence isessential if NGOSS is to withstand the rapid pace of technical innovation in distributed systems technology. Aswell as placing constraints on the core architecture, this requires ongoing NGOSS activities to identify and mapexisting and emerging technologies to the technology neutral architecture, so that NGOSS can continuallyleverage the best technologies over time.

The following sections describe the core architectural elements of the technology neutral architecture. Theseinclude NGOSS Contract Specifications, NGOSS Components, NGOSS Distribution Transparency, NGOSSProcess Management Services, NGOSS Shared Information and Data Management Services, NGOSS PolicyManagement Service, and the NGOSS Adaptation and Mediation Services.

4.2 Models

The term “model” here refers to the external specification of the characteristics and behavior of managed entities.There are two types of models in the NGOSS. An information model is an abstraction and representation of theentities in a managed environment. This includes definition of their attributes, operations and relationships. It isindependent of any specific type of repository, software usage, or access protocol. A data model is a concreteimplementation of an information model in terms appropriate to a specific type of repository that uses a specificaccess protocol or protocols. It includes data structures, operations, and rules that define how the data is stored,accessed and manipulated.

Models can take many forms, including the specification of class diagrams, metadata, business objects, contracts,processes, deployment information, and policy information. It is important to note that models are used to providean extensible system, rather than hard-coding information explicitly into a set of software modules. The NGOSSarchitecture is built around the principle of externalizing this information, and expressing it in a technology-neutralfashion ([6] provides a reference to Model Driven Architectures). Managed information defined in these modelscan be located and accessed by using the Registry Service.

This section does not prescribe a specific technology to be used for expressing models, but for the purposes ofproviding a set of examples for discussing the representation of Contracts, Processes and other importantartifacts, examples of Models are given. The representation of information within an NGOSS deployment will beaccomplished using the TMF Common Information Structure [TMF045], expressed using UML and encoded usingXML.

Metadata, literally, is defined as data that describes other data. For example, let’s consider a business object,such as an “Order”. An Order typically has a set of invariant characteristics, such as order ID, date placed, id ofthe customer placing order, and a collection of line items, each of which describe a product ID, a quantity, and aprice. These are implemented as attributes of a class that defines what an order is. The class can further defineoperations that make information about the order available to other managed entities. Metadata, then, is used toprovide information about the Order object and how it is to be used in a managed environment.

The SID team has mandated that UML is used to define shared information and data. Similarly, there are manydifferent ways to express behavior. However, since the SID is based on UML, OCL (the Object ConstraintLanguage) is mandated for expressing computable expressions that affect managed entities. Implementing theOCL expressions is outside the scope of this document.

Please see section 11 (Model Development Tools) for a brief discussion of issues related to model developmenttools.



4.3 NGOSS Contract Specifications

A contract is a binding agreement to provide information and/or perform an operation. An NGOSS ContractSpecification defines the invocation semantics and behavior of a service that is offered within an NGOSSdeployment. An NGOSS Contract Specification provides a well-defined interface to access the service(s) providedby NGOSS Component(s).

The relationship between Contract Specification and Component Definition is shown in Figure 11 below:

FSCs neededManagement

BusinessServicesoffered

Binding

contract component

ComponentDesign=>binding specified foreach contract

BusinessDesign=> contract specified

BusinessDesign=> contracts grouped in components

Legend

Figure 11. Contract Specification and Component Definition

The Contract Specification associated with the Business Service offered has a number of contributing parts.These include:

1) A description of the operation provided, and its inputs and outputs.

2) A reference to the Framework Services needed by the Business Service in order for it to co-operate withother Business Services according to the desired Interaction Pattern (e.g., to share in TransactionSemantics with other Business Services).

3) A description of the possible exceptions and errors than occur during the execution of the Service.

4) Metadata that describes how managed entities affected by the execution of this Service react and interactwith other managed entities.

5) A list of pre-conditions that are to be met before the execution of the Service.

6) A list of post-conditions that are to be met after the execution of the Service.

7) A list of exceptions and notifications that can be generated by executing this Service.



8) A description of the Shared Information Objects that are altered by the execution of the Service. Thisinformation is used to determine that the Contract can proceed (i.e., that no other Service has ownershipof the needed objects).

A Contract Specification calls upon a number of the concepts described above under the “Modeling” section. Forinstance, the input and output specifications use the metadata facilities to describe the types used for input andoutput arguments. For example, one of these might be the “Order” data type previously described.

The pre-condition and post-condition specifications use business logic facilities to describe the conditions to betested for at the start and the end of the execution of the Service(s) specified by this Contract. It is expected thatthe pre-condition and post-condition specifications will be expressed as predicate-logic statements. In order toensure the correct operation of contract conditions, it is assumed that the host execution environment (i.e., thethread of control that invokes the contract) is responsible for validating pre-conditions prior to invocations. Thecontract implementation must then verify that the inputs are indeed correct. Once this is done, the contractimplementation must verify that the post-conditions can be satisfied after execution is completed. If the post-conditions cannot be satisfied, the implementation is expected to terminate execution via an exception.

4.3.1 Contract Example

The following is a simple example showing the relationship between Services, Contracts and Components.Component A supplies order-taking Business Services. Component B supplies order-validating BusinessServices. Component C supplies order-escalation Business Services.

Each Component also makes full use of the Registry Framework Service. Hence, each registers itself with theRegistry Service at initialization time. Furthermore, Component A can locate Component B at run time. Thislocation can be accomplished using either the component name or the name of the contract.

Component A offers services by implementing contracts:

� Display order

� Display order agreement

Component B offers services by implementing contracts:

� Validate order

� Record order

� Check for duplicate order

Component C offers services by implementing contracts:

� Escalate order

� Auto correct order

The following convention is suggested for the naming of contracts. A contract name should be created from acombination of a verb with a descriptive predicate clause consisting of one or more nouns augmented byadjectives as appropriate. The descriptive predicate clause should indicate the business object that is the target ofthe operation, which is specified by the verb. In this way, a contract name describes the service (or services)offered by the contract.



4.3.2 Contract Lifecycle

Since Components are expected to be made available and made unavailable to the system during run time, andsince new contracts may be placed or changed in the Registry Service during run-time, there is a specifiedlifecycle for creating a new contract, then registering and un-registering the Components that implement theContract as appropriate.

For example, a Contract can be made “inactive”, which will cause all Components that implement the Contract tono longer offer the Contract. This must be reflected in the Registry, or else Components will erroneously keeptrying to invoke a Contract that is no longer available. Additionally, a specific Component can mark itsimplementation of the Contract to be “inactive”, in which requests to execute the Contract will no longer be sent toit, nor will the Registry Service return references to it.

4.4 Distribution Transparency

As discussed earlier, NGOSS architecture is composed of loosely coupled distributed components communicatingwith each other, providing value-added services. NGOSS clients as well as Components need to locate otherNGOSS Contracts and the Components that implement them without knowledge of their physical location in thenetwork.

The essential framework entity that supports Distribution Transparency is the Registry. The Registry enables theNaming Service, Directory Service, and the Trading Service to interoperate to provide distributed storage,management, and retrieval of NGOSS information, such as contracts, shared information and data objects, and soforth. The naming service enables names to be defined and manipulated for objects; the directory service bindsnames to objects; the trading service enables fuzzy searching and matching based on attributes that have beenbound to a name.

The Trading Service provides for contracts to be traded based on client specifications. The Invocation Service isused to manage invocation of contracts from one NGOSS component to another.

4.4.1 The Naming Service

The NGOSS Naming Service manages the various named objects in the system. These include the ContractSpecifications, the identity of the Component implementing the Contracts, and the metadata and contents used forshared data. It is organized around a multi-level namespace, which allows groups of names to be partitioned intodifferent namespaces. This is done to avoid name collisions as well as to perform “named object acquisition” byhaving name-based searches continue into parent namespaces when a match is not found. This enables thedeployment of a system to have standard named objects located in higher namespaces, while deployment-specificoverrides are stored in lower namespaces and acquire the standard environment when not overridden.

This namespace partitioning is further discussed in Section 6. The namespace tree is also designed to holdstandard groups of names, much as how an operating system’s file system has standard directories for importantfile. For instance, example namespaces could include the “Component ID” group, the “Shared Information Object”group, and the “Contract” group. These are simply examples and should not be construed to represent or suggestthe layout of the NGOSS namespace in an actual deployment. The standardization of high-level components ofthe namespace tree is essential in order to provide interoperability. Without these standardized components,different applications will be unable to find common information. This prevents multiple applications from sharingcommon NGOSS information.

The NGOSS architecture assumes the existence of four (4) different types of classes to represent names. Themost important of these classes is Name. Class Name defines the basic behaviors common to all types ofNames. The syntax of a given Name is governed by a naming system. A naming system contains a schematicconvention and a naming convention. The schematic convention of a naming system governs the relationships



that can be established between Names within that naming system. The naming convention of the naming systemgoverns the construction of a Name from the set of symbols that are valid within the naming system. A namespace is the set of all names within a naming system.

Three classes implement the interface defined by Name. These classes are

� AtomicName -- used to represent a single Name that cannot be further decomposed.

example: “www”, “tmforum”, and “org” are all atomic names within the DNS naming system

� CompoundName – used to represent a Name that is an ordered collection of Names from the samenaming system

example: “www.tmforum.org” is an instance of a CompoundName within the DNS naming system

� CompositeName – used to represent a Name that is an ordered collection of Names from two or morenaming systems.

example: “http://www.tmforum.org" is an instance of a CompositeName from the URI NamingSystem, and is a valid name in the Internet Namespace.

The following figure (Figure 12) graphically illustrates the relationships between class Name and its three (3)subclasses.

AtomicName

CompositeName

Name+components

CompoundName

0..n

+components

0..n

Figure 12. Types of Names

4.4.2 The Directory Service

The Directory Framework Service uses a specific Naming Service in order to allow the binding of names toobjects.



NamingConvention

NamedObject Name

BindingNameSpace

<<constrained>>

0.. n0.. n1.. n1.. n

Figure 13. Binding of a Name to a NamedObject

The Directory Service is used to maintain information about the run-time state of the system, such as the deployedComponents and their Contract Specifications, where they are located, and how to invoke them. The DirectoryService manages the global namespace for contracts, information objects, components, processes and theirspecifications in the system. At design-time, it provides a catalog of required and implemented ContractSpecifications, and at run-time it provides name-based lookup of shared Components and Services. This is usedby the Trading Framework Service to perform attribute-based matching. There may be one or more DirectoryServices.

The NGOSS Registry Service provides a unified interface to a Naming Service, a Directory Service, and a TradingService. The NGOSS Registry Service manages a multi-level namespace through these three services. Thisallows groups of names to be partitioned. Example namespaces include the “Component ID” group, the “SharedInformation Object” group, and the “Contract” group. A unique aspect of the NGOSS Registry Service is thatnamespaces can be contained within other namespaces, so that entry in the Component ID namespace for acomponent can contain subordinate namespaces for other components.

Figure 14 provides a control diagram that shows registration of a component as it is installed into the system, andhow later NGOSS software elements discover it by querying the Registry.



RegistryService

ComponementImplementing

Businss ServiceProcess Manager

Information Exchange

init-time registrationdiscovery response 12 3

Figure 14. Using the Registry Service

For larger implementations, the NGOSS Registry Service will support federating registries for the purposes ofpartitioning and scalability of its location services. Federation is the ability to group physically separated entities (inthis case registries) into a single logical whole. Partitioning enables the different physical components of thelogical Registry to be treated differently (e.g., managed as well as accessed). The scalability of the Registry isincreased by decoupling the various components that make up the Registry. This enables them to be developedand managed in parallel. Through these mechanisms, the NGOSS Registry can grow and support NGOSSinstallations as they grow over time. Note that the Directory, Naming, and Trading Services can also be federated.

Figure 15 shows how the Registry and Naming Services interact with each other.

RegistryService

ComponentImplementing

Business ServiceProcess Manager

Communications Service

init-time registrationdiscovery response 12 5

NamingService

3

4

Figure 15. Using the Registry and Naming Services

4.4.3 The Trading Service

The Trading Service extends the functionality of the registry service by supporting the capability to bind attributesto objects as well as the facility to search for the best match against a set of objects using the attributes that havebeen bound to the objects as part of the search criteria. This service is intended to be used to support trading forNGOSS contracts specifications, given the contract properties, rather than the contract identifiers.



The use of the Trading Service is similar to that shown in the control diagram for the Naming Service, except thatthe Trading Service is invoked to perform discovery. The Trading Service uses the same information that isregistered in the Registry Service.

NamingConvention

Name

Attribute

NamedObject

Binding

AttributeBinding

NameSpace

<<constrained>>

0..n0..n1..n1..n

0..n0..n

Figure 16. Trading Service Extensions to the Registry Service

The trading service maintains a set of AttributeBindings. Each AttributeBinding allows the attachment of anattribute to a NamedObject that can then be used by the Trading Service to resolve trading requests.

4.4.4 The Invocation Service

There are several steps associated with requesting invocation of a Service on a remote Component, with the mostcritical step being to ensure that the Contract's pre-conditions and post-conditions are tested and supported. Inaddition, the Service implementer must be properly located, the Communications Service must be properly used,results must be logged. Security must be applied at each step in the process. For this reason, the InvocationService is supplied as a convenient way to perform all of these steps and ensure the integrity of the operation inthe context of the overall system and the client invoking the service. The Invocation Service calls upon theCommunication Service and others as necessary.

The Invocation Service will be the primary way that remote, authorized, and contract-validated invocation of one ormore Business Services supplied by another Component is performed. The specific steps associated withinvocation include the following:

(1) Locates an implementation of a Business Contract.



(2) Queries the Security Service to determine if the operation is authorized.

(3) If authorization fails, reports an exception condition; otherwise, continues.

(4) Tests the pre-conditions of the Business Contract; if these cannot be met, then an exception isreported (otherwise, continues).

(5) Marshalls all parameters of the request into the implementation requirements. Sends the requestand waits for the reply.

(6) Marshalls the response from service implementation and handling exception conditions. Tests thepost-conditions of the Business Contract. If the post-conditions cannot be met, then an exceptionis reported (otherwise, continues).

(7) Logs the invocation and its status (e.g., whether it was successfully invoked).

(8) Returns the response to the requestor of the invocation.

The Invocation Service performs all of the above steps to ensure the integrity of the invocation.

4.5 Components

The NGOSS architecture is a component-based architecture. From the minimalist point of view, components aredeployable containers that implement Contract Specifications. However, to fully understand the implications ofcomponent-based systems, the minimalist point of view is insufficient.

The Carnegie-Melon Software Engineering Institute (CM SEI) defines a component as

� A binary implementation of functionality,� Contractually specified,� A unit of independent deployment,� Subject to 3rd party composition,� Conformant to a component model

As a binary implementation of functionality, a component is an artifact. While not as tangible as a SpanishDoubloon from a 16th century treasure ship, it is nonetheless an artifact. To be more specific, it is one of theartifacts of the software development process. In order to be useful, the services provided by a component mustbe clearly specified. From the NGOSS point-of-view, this means that they must be contractually specified. To be aunit of independent deployment, a component must be specified and constructed in such a way as to enable it tobe deployed and installed into a system without the need for the use of a trial-and-error process. This implies thata component must have all of its external (contextual) dependencies explicitly defined. Given the contractuallydefined services, and the explicitly defined external (contextual) dependencies, a component can be combined ina system with other components to deliver a service that is then available to all other components (and clientapplications) within the system. Finally, a component must be implemented in compliance to a technology specificcomponent model, such that a technology specific component execution environment is capable of making thecomponent contractually specified services available at runtime to the remainder of the system5.

Components are therefore, from the minimalist point of view, containers of contract implementations. Contractimplementations are used by the component execution environment, to create contract implementation instances.

5 The issue of conformance to a component model is seen as being a technology specific issue and will not be discussedfurther within this document.



Contract implementation instances are runtime software artifacts that deliver services to other runtime entitieswithin a component based system.

For instance, in a Java™ based system, the component is embodied by the .JAR6 file. The .JAR file containsother files (e.g., .class files) that are the compiled (i.e., Java™ virtual machine byte-code) binary implementation ofthe contractually specified functionality. The .JAR file may be installed into a system and used, provided that anyexternal contextual dependencies are met. The Java™ 2 Standard Edition platform does not, in and of itself,provide support for the specification of these external contextual dependencies, other than as textualdocumentation. Installation-time support for the specification of external context dependencies is providedthrough the Java™ 2 Component Model. One implementation of this is Enterprise Java™ Beans (EJB),specifically via the EJB deployment descriptor.

One additional characteristic must be assigned to components in a high availability environment. Thischaracteristic is as follows:

� A component instance may not have persistent state [SZY]

Note that the above applies to a component, not a contract. Contracts, and the implementations thereof, will ofcourse create, manipulate, and rely upon information that is stored in a persistent fashion within the system. Thereason for this requirement is that in a high availability environment, the possibility of redundant componentinstallations must be accounted for. A component instance is the installation of a component foo within thesystem in such a manner that a foo component can be instantiated by the component execution environment. If acomponent instance has persistent state associated with it that is required by contract implementation instances,and that state information becomes unreachable, for whatever reason, the ability to use a redundant componentinstance is compromised. A component instance may have local configuration information, and informationrelated to the management of the component instance (license key, local directory server name, etc), but may notmaintain information at the component instance level to be used by contract implementation instances.

The NGOSS Architecture makes the following presumptions in regards to NGOSS Components:

� The NGOSS architecture does not define which contract interfaces and services are contained in aparticular component.

� The NGOSS architecture, however, defines how components operate in general, as well as how acomponent installs and makes its services available.

Component-based development provides a number of advantages over the existing, traditional approach ofmonolithic system development. These benefits include, but are not limited to:

1. Supply of components from multiple sources.

This supports best value for money in procurement of components and enables financial considerations to betaken into account for make / buy decisions. It also helps prevent vendor lockout.

2. Re-use of components.

Business components may be re-used across multiple business scenarios. In addition, new businessscenarios may be viewed as ‘delta’ changes to existing solutions. The financial implications for this arecentered upon the need for only marginal additional costs when components have to be extended or replacedto support the new business scenarios.

3. Legacy / heritage systems.

6 Java™ Archive File



It may be necessary to bring legacy non-NGOSS systems to an NGOSS environment for business /financialreasons. This can be achieved by creating mediation interfaces between legacy systems and the NGOSScomponents.

4. Flexibility of the systems environment and associated speed to market for new service products.

Since new service products will be delivered through linking together of components, this more flexibleenvironment will allow a much more diverse range of service products to be provided to customers. Inaddition, the NGOSS approach shall enable them to be provided in a much faster time.

The NGOSS focuses on the Contract Specification as the fundamental unit of functionality providing interfaces toNGOSS Components. The NGOSS Component is a deployment container for at least two types of contracts:

� Contracts used to manage the component itself;

� Contracts that represent the value-added functionality of the component

This distinction avoids dictating which contracts the developer of an individual component is required toimplement. The individual component developer may implement those contracts that represent the functionality oftheir product, be it a self-contained service quality management component (which may be represented by singlecontract), or an end-to-end customer care system (which may be represented by multiple contracts). However,they are required to implement the management contracts needed to manage a NGOSS component.

An NGOSS Component can be further categorized, as discussed earlier, into an NGOSS Framework ServiceComponent and/or an NGOSS Business Service Component.

� An NGOSS Framework Service Components (FSC) implements one or more fundamental infrastructureservices within the NGOSS that enable the features of the NGOSS architecture (such as plug and playand contract-trading) to be realized.

� An NGOSS Business Service Component (BSC) provides services that support the business-relatedfunctionality of the NGOSS architecture, such as billing, rating and discounting, network datamanagement, and others.

4.6 NGOSS Process Management

The basic premise of the NGOSS is that through the identification of well-defined, contract-specified interfaces,implemented by commercial off-the-shelf components and supported by a distributed processing framework, it ispossible to build a highly scalable, extremely flexible OSS that enables and facilitates the rapid deployment of newservice products. The reality of the situation is that, without the ability to rapidly tailor OSS supplied services intothe business processes of the service provider, such a premise cannot become a reality.

The Process Management Service acts as a conductor or coordinator of activities spanning across the NGOSSComponents implementing the Business Services. This Service provides the externalized process control thathas been mandated by the NGOSS Service Provider stakeholder. The Process Management Framework Serviceideally executes logic expressed using a means that is different from the implementation language used for thecomponent. This makes it easier to rearrange and/or alter the business process steps, and then have the ProcessManagement Framework Service rearrange the interaction between the Components (if necessary). There may bemultiple such Process Management Framework Services within an NGOSS environment, each one used atmultiple levels of abstraction in implementing the control structure of a system.

For each NGOSS business process, Process Management can decide or can execute decisions on behalf ofexternal systems that control which business contracts need to be invoked in what order and in what relation toeach other. Each decision is based on a number of factors: the process plan, which includes policies, productdefinitions, and service level agreements; the outcome of the previous contract invocations; the states of the



pertinent business and functional service components; the availability of business contract instances of the nextbusiness contract type required for invocation.

Taking each of these decision factors in turn:

� The outcome of business contract invocations is communicated to Process Management depending onthe invocation services used by the Process Management to invoke the business contract instance inquestion.

� Process Management is responsible for registration and maintenance of available process definitions.The process definitions can be managed directly by Process Management, or can be made available toProcess Management by external systems through contracts offered by Process Managementcomponents.

� Process Management gathers knowledge about the state of business and functional service componentsthrough the usage of standard NGOSS contracts, including management contracts, where applicable.

� Process Management may use trading capabilities as appropriate to determine the availability of businesscontract instances.

The following figure shows Process Management with a process plan that can include suggested variable pathsof contract sequencing. In addition, it shows contracts from particular components being invoked and returningindication of contract completion.

Process Management

Figure 17. Process Management

4.6.1 Process Definition

A process is a set of one or more linked activities that collectively realize a business or system goal [7] . In currentUML terminology, this is most closely represented by an activity graph. An activity graph is a special case of astate machine that defines a computational process in terms of the control-flow and object-flow among itsconstituent actions. The primary purpose of an activity graph is to describe the states of an activity or process thatinvolves one or more managed entities. Activity graphs include the concept of Partitions to organize statesaccording to various criteria, such as the individual or organization that is responsible for their performance.

The definition of the behavior of a business process can be expressed in terms of named, UML activity diagrams.Additionally, each activity state within the diagram will be named, and corresponds to the invocation of a contract.



4.6.2 Process Definition Lifecycle

Process Definitions can be offered, implemented, activated, and administered like Contract Specifications. AProcess Definition can also be made “inactive”, which will cause all Process Managers to be unable to start moreprocesses that are based on that definition.

4.6.3 Process Execution Environment and Context

A Business Process is executed by the Business Process Engine. The business process engine maintains anoverall execution context, termed the business process engine context, which maintains the global state of the setof business processes currently executing within the system. A business process is defined by a processdefinition script, which contains the sequenced description of the business processes (in terms of contracts) to beexecuted. Here, a process definition script is not meant to imply any particular scripting language – rather, itsimply means a sequenced collection of business processes.

The execution of a contract is called a contract invocation, which corresponds to a defined task within thebusiness process itself. This may be the invocation of an information provider contract, or of a (business) servicecontract7. The business process engine executes a process definition script, maintaining a context for each scriptexecution instance.

From a security standpoint, the NGOSS technology neutral architecture makes the following assumptions:

� A business process, as defined by a process definition script, executes under one or more specified roles� During the execution of a process, the business process engine assumes the role(s) specified by the

process definition script� The access privileges of the business process engine are restricted as appropriate to the specified role(s)� An executing script does not have access to the globally maintained business process engine context

unless one or more of its roles have access to the business process engine context

In general, an executing business process has access to the following items:

� Any information passed to the process definition script execution context by the business process engine� Any request parameters passed to previous contract invocations within the same process definition script

execution context� Any response parameters generated by previous contract invocations within the same process definition

script execution context

The static structure of the analysis classes related to the execution of business processes is depicted below inFigure 18.

7 At this time, it is assumed that service providing contracts are providing services of a business aware/supporting nature. It ispossible that at some time in the future it may be determined that the execution of a business process may require the ability todirectly invoke a framework service.



ContractSpecification<<document >>

BusinessProcessEngineContext

BusinessProces sEngineContext

ProcessDefinitionScriptExecutionContext

Context

0.. n+child0.. n

+parent

RequestData

ResponseData

Task

BusinessProcessEngine<<control>>

ProcessDefinitionScriptExecutionContext

ProcessDefinitionScript<<document>>

0..n0..n

0..n0..n

BusinessProcess

0..n0..n

1

1

1

1

11 11

Figure 18. Business Process Execution Environment

4.7 NGOSS Shared Information and Data Management

A basic tenet of NGOSS is that all enterprise-wide data is stewarded. That is, one or more processes control allaccess to that data based on the defined access policies.

The SID is a federated set of models, each of which covers one or more management domains. It is notconsidered feasible to have a single information model that can be used to represent the full diversity ofinformation that would need to be shared within a typical NGOSS compliant system. The NGOSS SID, as definedin GB922, is two things – a federated information model as well as a set of mappings to a set of data models. Aninformation model is independent of the type of repository, access protocol, software implementation, and platformused – its purpose is to define common information structure, characteristics, behavior, and inter-entityrelationships. The SID is federated for two reasons. First, this enables the SID to function as a framework, wherelower-level details may be provided by the SID or by other existing models from other standards communities.Second, it enables applications to view the SID as a set of extensible building blocks. They don’t need to use theentire SID (which will be quite large) – rather, they use only those portions that are applicable to their application.



This single information model is then translated to a set of data models. Each data model is optimized for aspecific combination of repository and access protocol that is being used to steward particular types of data. Thisis necessary because management data is diverse in nature, and no one repository and access protocol havesufficiently diverse characteristics to steward all of the data concurrently. This illustrates the necessity of having asingle common information model – if there were multiple information models, then data coherency of a givenentity could not be maintained across different implementations in different repositories.

Business Service 1 Business Service 2

Shared InformationService

Communication Service

Local DataLocal Data

Shared Data

Figure 19. Shared Information Management

Figure 19 depicts two business services, each managing a local data store, that also have a dependency on someshared information, which is managed by a system-wide shared information service. In other words, the SID isenterprise-wide, and allows heterogeneous systems that have their own private data to communicate with eachother using public shared data that is owned not by any one system, but the entire enterprise. The SID enables thetwo business services to agree on common definitions of the shared data and reuse it for their own applicationspecific purposes. They are each free to refine the shared data to suit their own needs, but can interoperate basedon the common understanding and representation of the shared data.

4.7.1 Concepts

The concept of the SID is fundamental to the principles of NGOSS-based systems. It is the means by whichuseful information, relevant to a given set of business processes, may be factored out, shared, and operated on bymultiple business processes on a system-wide basis. Examples of such information include SLAs (Service LevelAgreements), Customer Details, Network Topology, and Performance information.

GB922 defines the NGOSS Shared Information and Data (SID) model. Please note that this is a work in progress.See the SID charter for the current and future scope of this work.

Instances of elements defined within the SID are accessed by the entities within an NGOSS deployment via well-defined contract interfaces, termed information providers. Information providers support information servicecontracts. Collectively, the set of information services provided through these Interfaces provide access to theentirety of the shared information in an NGOSS deployment. The entities that present information providercontracts are termed data stewards.



In order that the logical concept of the SID may be implemented, a number of supporting Framework Services willneed to be physically deployed. These are shown in Figure 20 below as layered services, where each builds uponthe services offered at other layers below it:

� At the top-most level are the Contract Specifications, which support the SID as outlined above.

� The Information Services layer adds business value, transforming raw data into useful businessinformation (this may include data mining and filtering). This layer is also responsible for adapting and/ormediating data from the enterprise-wide common format into the particular format that any contract orcomponent implementation needs. See section 4.9 for details on adaptation and mediation.

� Supporting the Information Services layer is the Data Distribution and Stewardship layer, which supportsaccess and sharing of data across a number of physically distributed repositories. Such items includesupport for data synchronization and maintaining transactional and referential integrity.

� At the bottom-most level are the separate raw repositories that hold and maintain the data. This levelperforms raw data distribution, but may also include ancillary functions, such as acting as a data proxy.

Figure 20. Information Layers

The NGOSS SID is a shared information model that is built by refining the UML metamodel. The SID consists of aset of entities that are organized into a set of management domains. These domains provide a mapping to thebusiness and system views of the NGOSS system, as defined using eTOM and SIM terms. This is achieved bystarting with the UML metamodel and refining its generic concepts to suit the application-specific needs of anNGOSS system. The instantiation of the SID provides one or more SID-compliant data models, which are presentfor all NGOSS components to share and use. An NOGSS repository is used to define which data stores havewhich data. The details are as follows:

� Components offering contract services do so in terms of common data types. These are defined in theSID, and use standard UML extension mechanisms (e.g., stereotypes, tagged data, and OCL) to extendthe UML metamodel.

� Components can internally deal with non-standard models, but require adaptation and/or mediation to theSID. In such a case, components offer contract services along with adaptation and/or mediationfunctionality.

Raw DataStorage

Data Distribution and Stewardship

Information Services

Contract Specifications Expose Information Servicesto Components

Transform Data into Businessand System Information

Support Referential and DataIntegrity, Access Control, etc.

One or More PhysicalRepositories



The benefit of these principles, as embodied in the SID, is that it decouples the consumers of data from theproducers of the data. Instead of every OSS component being tightly coupled to every other, they are coupled toonly to the specification of common SID data within an NGOSS deployment. Therefore, whenever an OSScomponent needs to be removed, upgraded or replaced, all other components are unaffected - the only thing thatneeds to change is the definition of the contract interface.

It is expected that an NGOSS deployment will contain a (perhaps large) number of shared information providers.This number will be dependant on the partitioning of the SID data based on the requirements of the deployment.

4.7.1.1 Example of Using Shared Information

Consider three different applications: inventory, service activation, and topology. Without a shared informationmodel, these applications have to implement common sub-services, such as discovery, to perform identical tasksthat they all need. Unfortunately, this usually results in the three applications implementing the same function threedifferent ways. This in turn leads to either loss and/or misrepresentation of information.

Now consider the same system that uses the SID. A single discovery application can be used to place commondata in a shared repository that can be used by each of the three applications. For example, suppose a new IProuter is discovered. The discovery service can obtain characteristics such as its IP address, number of activeports, current configuration, and routing policies. Some or all of these data can be used by each application.

Even better, the discovered data can be modified by a second application and used by a third. Continuing theexample, the inventory service updates its repository with the IP address of the newly discovered device. This isthen used by the topology service to find out what that device connects to, and adds the resulting information intothe shared repository. The service activation application takes this information, modifies the configuration of thenewly discovered IP router and another existing router, and constructs a VPN. The service activation applicationthen places these modified data back into the shared repository. This modified information is then extracted by theinventory service to update its record of which ports on which devices are now in use, and what services aresupported by what devices.

4.8 NGOSS Policy

Users of an NGOSS system may be categorized by their role in terms of what services they have access to; thisaccess may be qualified by policies defining access control.

The NGOSS policy subsystem acts as a supervisor of operations being carried out by all other services that itmanages. Hence, the Policy Management Framework Service can apply constraints and/or conditions on whatoperations are executed, and how they are executed, within a system. These constraints can be used to imposelocal rules on processing sequences and conditions that are required to be met before (i.e., pre-conditions) andafter (i.e., post-conditions and exceptions) any action.

Policies exist at various levels of abstraction within a given system. Broadly, policies may be invoked by any, andall, of the TMF Business and System Processes, as defined in the eTOM and SIM, respectively. Each discretesystem capability is constrained by any and all applicable policy rules. It is important to note, that from anarchitectural perspective, the NGOSS policy subsystem is an integral element of the overall NGOSS systemarchitecture. This enables a policy to be mapped onto one or more technologies, as defined in the TNA PolicyReference Model [TMF053p8]. This approach will enable a policy to be constructed using the most advantageoustechnology available, thereby “future-proofing” abstract policy definitions by separating specification fromimplementation.

8 This document is not available at the time of this writing.



4.8.1 Towards NGOSS Policy-Based Management Systems

The need for policy is determined by the system builder (re: Section 3.1) based on the operational requirements ofthe system user (re: Section 3.1). Current OSSs are typified by the following characteristics:

� Large distributed systems are shared by many owners and thus, multiple management systems will berequired to cooperatively manage the system(s) as a functional whole.

� The correlation of management activities requires one or more special correlation systems � A single management system cannot handle the set of unique problems that each component in the

distributed system has� User behavior may differ from one subsystem to another, making it difficult for one single

management system to manage user behavior across systems and subsystems.

Systems that exhibit one or more of the above characteristics are prone to failure because, if the managementsystem fails, there is no backup management mechanism. Policy-Based Management Systems (PBMSs) havebeen proposed to solve the preceding list of problems. This has two attendant benefits. First, it improves thereusability of the management system. Second, it increases the availability of the overall system.

Current operational support systems (OSSs) are built in a “one-off” fashion according to the needs of a specificService Provider/Network Operator. In contrast, an OSS that contains a PBMS will be built to a more generic set ofrequirements. The functionality of a policy-managed OSS will be constrained to the requirements of any givensystem user through the application of policy. Policy-based OSSs are differentiated from non-policy-based OSSsby the existence and use of policy-based management modules (PBMMs). A PBMM is responsible for managingpolicy within one or more specific subsystems of the OSS. From the point-of-view of a particular PBMM, there aretwo types of policies: native policies, which exist within the given PBMM, and external policies, which are importedvia policy access points (PAPs). A PAP is a mediation point, supported by a PBMM, which enables cooperationbetween the native policies as defined in the PBMM and non-native policies as defined in external PBMSs.

The foundation for PBMSs is the PBMM. The building blocks for a PBMS are PBMMs and any required PAPs.PBMMs are capable of translating between the various views (e.g., business system, etc.) that are represented bynative management policies.

From the view of a particular PBMM, an external PBMS acts as a policy repository and/or a special correlationsystem. It is assumed that each PBMS manages potential conflicts of its own policies. Inter-PBMS conflictresolution is a function of a dedicated policy conflict resolution system.

A PAP can be enabled or disabled by the controlling PBMM. A PAP could be enabled by default. In this case, thisPAP is considered to be associated with a neutral view on the system. The choice of whether a PAP is enabled ordisabled by default is determined by the Service Provider/Network Operator.

The behavior of a given PBMM is embodied by the native policies that are managed by that particular PBMM. In apolicy-based NGOSS deployment, there must be at least one PBMM. Figure 21 shows the convergence of the twomanagement paradigms.



Operat ion al sy stem

Po licy-b asedmanag e m ent sy stem

Po licy-basedmgm t mo du le

a b c

OSS in tegra ted with aPolicy -based manag e ment syste m

Po licy acc ess p oin ts

Policy-co r rel ation po in ts

Pol ic y-ba sed ma na gemen t mo dule :- n ative p olicies- v ital serv ic es- v alidate ex te rn al p olicy systems

d

Figure 21. Convergence of Management Models

A PBMM controls how external policy-based systems interface into, and interact with, the policy-managed (sub)system. Each policy server defines its own means of communicating with other policy-enabled entities andresolving conflicts. This is based on shared information (as defined in the SID), along with defined behavioralexceptions (as defined through contracts). It may be described by a set of post-conditions and system state due toa preceding state transition of the system or of a part of the system, that cannot be recognized as a pre conditionby the PBMM. Those post-conditions become pre-conditions for a contract that the PBMM will trade with anexternal PBMS. A set of pre-conditions belongs to a given view. Figure 22 depicts this contract-based interaction.

n a t iv ep o lic ie s

m a n a g e m e n t o fp o l ic y -a c c e s s p o in t s

h a n d l in g e x te rn a l in te ra c t io n

a

b

c

d e

< p re - c o n d it io n s > : := < sy s te m _ sta te > < v ie w >

< e x te rn a l_ sy s t e m > : := < e x te rn a l_ p o l ic ie s > < n e w _ s y s te m _ s ta te >

le g e n d :a , c : s m a rt f i lt e rs fo r p re - c o n d it io n sd : e x te rn a l p o l ic y e n g in ee : v ie w -o rie n t e d d a t a k n o w le d g eb : p o lic y e x p o rt

P o lic yP o lic y -- b a s e d m g m t m o d u leb a s e d m g m t m o du le e x te rn a l p o li c y s y s te me x te r n a l p o li c y s y s tem

c o n t r a c tc o n t r a c t -- d e fin e d in t e r f a c ed e fin e d in t e r f ac e

Figure 22. Contract-Based Interaction



Native policies allow the PBMM to perform the following services:

� Maintain an inventory of all PAPs� Maintain an inventory of all applicable views Under policy control� Control access for external PBMSs via one or more PAPs� Request specific PBMSs to handle exceptions� Request for policy correlation systems to handle conflict detection and resolution� Manage PAPs (creation and deletion, inventory, status, association with external PBMSs, validation,

enable/disable, and other functions)� Control the configuration of components and their interactions, including system enhancements (services,

components, users, etc.), through one or more PBMSs� Capture behavioral exceptions and assign appropriate external PBMSs to them� Trade the most suitable external PBMS based on the type of view and behavioral exception.

All exceptions are covered via external (i.e. non-native) policies. The PBMM decides what kind of policy or policysystem will be used at a given PAP. The mechanism is covered in TMF053p.

4.9 NGOSS Adaptation

Within the NGOSS architecture, adaptation needs to be carried out to enable different NGOSS components usingdisparate technology specific implementations to be able to communicate with each other. Adaptation may beused to address differences in messaging technology, data representation and differences in implementing entitiesfrom disparate data models.

4.9.1 Adaptation between Information Models

A Business Service may be built to one information model but deployed in an enterprise that uses a differentinformation model. It will then be necessary to add either adaptation or mediation services to enable the BusinessService to interoperate with the remainder of the system. This enables the business process control entity to usethe Business Service without compromising either information model.

An adapter is a component implementing an Adaptation Service. An NGOSS adaptation service is one thatconverts one entity that has a particular syntactic representation to another entity that has a different syntacticrepresentation in order to enable the two to interoperate.. The specification of this mapping may be hard-codedwithin the adapter, or may be more dynamic.

4.9.2 Adaptation between Data Encodings

This is seen as a technology specific issue, and is therefore out of scope for this document.

4.10 NGOSS Mediation

Mediation is defined as a mechanism to enable semantically different entities to interoperate. Often, the means toachieve mediation is to translate each of the entities to be mediated to a common third form (e.g., a commoninformation model, such as the NGOSS SID). Mediation enables entities to interoperate in a loosely coupled way.Note that adaptation is concerned with the translation of syntactically different entities and may therefore losesome of the semantic meaning in the process. Mediation seeks to preserve the semantic meaning of each entity.

Mediation is important because, in order for the concept of plug-and-play to become a reality, software systemsmust be able to communicate between one and another, regardless of the implementation technology of thesystems. Mediation is therefore useful to enable the semantics of different systems to be preserved whileenabling them to interoperate.



Contract interfaces for legacy systems (e.g. non-NGOSS) may be supported in an NGOSS environment bycreating virtual components through mediation interfaces placed between legacy systems and the NGOSS. Thisapproach may also be used to supply a migration strategy for legacy systems into a pure NGOSS environment(e.g., Customer Details information migrated out of a legacy system into an information server – based upon acommon data warehouse that uses common shared data).

This approach enables business processes and information, which are already available but ‘locked-up’ withinlegacy systems, to be accessed by other systems in the NGOSS deployment. Without mediation, these items ofbusiness process and information would have to be reproduced in the NGOSS deployment. Not only does thisrepresent a significant cost, the likelihood of introducing errors is considerable. An NGOSS Legacy SystemComponent is a specialized NGOSS Component in which mediation has been used to enable the legacycomponent to appear to be an NGOSS component. An NGOSS Legacy System Component is bound by samerequirements that an NGOSS Component is bound by, at the contract-defined interface.





Legacy SystemComponent

Existing System


A BB

Existing System

Client Client

BAC

A BB

Contract Defined Interface

Integration pathMigration path


Existing System


AA BBBB

Existing System

Client Client

BAC

AA BBBB

Contract Defined InterfaceContract Defined Interface

Integration pathMigration path

Figure 23. NGOSS Legacy System Component conceptual view

Figure 23 graphically depicts the NGOSS Legacy System Component concept. The upper integration pathsconnecting to the NGOSS Legacy System Component enable clients to interact with a legacy system as if it werea native NGOSS Component. The NGOSS Legacy System Component can be an integral piece-part of thelegacy system, or an entity that exists externally to, and independently of, the legacy system. The lower migrationpath shows the eventual replacement of the legacy system with a native NGOSS component implementing therequired contracts.



5 ReferencesThe follow list of documents were referenced within this document, or are considered be relative to and supportiveof this document.

[1] [BIZ] TMF 051: New Generation Operational Support System (NGOSS™) PART I (Business Case).TeleManagement Forum, 2001.

[2] [REQ] TMF 052: New Generation Operational Support System (NGOSS™) PART 2 (Requirements).TeleManagement Forum, 2001.

[3] [CIS] TMF045: The Common Information Structure. TeleManagement Forum, 1999.

[4] [SIM] GB914, TeleManagement Forum, 2000.

[5] [TOM] GB910: The Telecom Operations Map, version 2.1. The TeleManagement Forum, 2000.

[6] [MDA] Model Driven Architecture, OMG White Paper, November 2000.

[7] [WFMC] WfMC Glossary - The Workflow Management Coalition Terminology and Glossary, May 1996.Document Reference WFMC-TC-1011.

[8] [ACT] The TMF Application Component Team.

[9] [GAM95] Erich Gamma, et al. Design Patterns: Elements of Reusable Object Oriented Software.Addison-Wesley, 1995.

[10] [GRAY93] Jim Gray and Andreas Reuter. Transaction Processing: Concepts and Techniques

[11] MIL David Milham, British Telecom

[12] HER00 Peter Herzum and Oliver Sims. Business Component Factory. OMG Press, 2000.

[13] SZY99 Clemens Szyperski. Component Software: Beyond Object Oriented Programming.Addison-Wesley, 1999.

[14] UMLREF James Rumbaugh, Ivar Jacobson, Grady Booch. The Unified Modeling Language ReferenceManual. Addison-Wesley, 1999.



6 Open Issues and Assumptions

6.1 Issues1 Contracts and Policies need more explanation and work. In particular, supporting documentation

needs to be updated and written, respectively. 2 Contract sets need further definition.3 Process definition needs further definition

6.2 Assumptions

None