OSS through Java as an Implementation of NGOSS A White Paper

Document Issue: 1.0 Date: April 2004

Abstract:

Whilst the TeleManagement Forums’s New Generation Operations Systems and Software (NGOSS) program and the OSS through Java Initiative (OSS/J) program have different foci, both have the ultimate goal of promoting the delivery of reusable OSS solutions to service providers. The NGOSS program has focused on business aspects of OSS solutions whereas the OSS/J program has focused on implementation aspects. Closer collaboration between the TMF and OSS/J is seen as valuable for both organizations and for the industry as a whole. The purpose of this white paper is to investigate alignment between the technical programs concentrating on architectural principles, contract schemata, and information-modeling techniques. Identification of such alignment is regarded as a prerequisite for closer collaboration.

Editor: Colin Ashford, Nortel Networks

Contributors: Ala Awad, Alcatel Colin Ashford, Nortel Networks Cliff Faurer, TeleManagement Forum Jim Hardwicke, BT Alain Lemoine, Eftia Dave Raymer, Motorola John Reilly, Metasolv Francesco Silletta, Telecom Italia Stefan Vaillant, Nokia Document Status: Final

Page 2 of 38

Release Control

Date Change Author Version

20 February Outline of document Editor 0.2

24 February Agreed outline Editor 0.3

15 March Merged text Editor 0.5

22 March Review Copy Editor 0.60

29 March Editor’s Draft Editor 0.61

1 April 04 Final Draft resolving all comments

Editor 0.65

14 April 04 Final corrections; Website-ready copy

Editor 1.0

TradeMarks Sun, Sun Microsystems, the Sun logo, Java, J2EE, Java Community Process and The Network Is The Computer are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

Enhanced Telecom Operations Map is a registered trademark of the TeleManagement Forum

Page 3 of 38

Table of Contents 1 Introduction........................................................................................................... 5

2 Purpose and Scope ................................................................................................ 6

3 Architectural Principles ....................................................................................... 7 3.1 NGOSS Architectural Principles ............................................................................ 7

3.1.1 Modelling ........................................................................................................ 7 3.1.2 OSS Business Applications ............................................................................. 8 3.1.3 Framework Services ....................................................................................... 9 3.1.4 Federation..................................................................................................... 10 3.1.5 Inter-working Mechanisms ........................................................................... 10

3.2 The OSS/J Architecture ........................................................................................ 11 3.3 The J2EE Architecture.......................................................................................... 11

3.3.1 Object Serialization ...................................................................................... 12 3.3.2 JNDI (Java Naming and Directory Interface) .............................................. 12 3.3.3 JTA (Java Transaction API) ......................................................................... 13 3.3.4 JCA (J2EE Connector Architecture) ............................................................ 13 3.3.5 JMS ............................................................................................................... 13 3.3.6 RMI and RMI-IIOP....................................................................................... 13

3.4 Comparison of Architectural Principles ............................................................... 14 3.4.1 Distribution Support ..................................................................................... 14 3.4.2 Core Communications .................................................................................. 14 3.4.3 Transaction Management ............................................................................. 14 3.4.4 Scalability ..................................................................................................... 14 3.4.5 Deployability................................................................................................. 14 3.4.6 Separation of Business Process from Software Implementation .................. 15 3.4.7 Shared Information ....................................................................................... 16

3.5 Summary of Architectural Principles ................................................................... 17 4 Contracts and Interface Schemata.................................................................... 18

4.1 Introduction to Contracts ...................................................................................... 18 4.2 The Contract Metaphor and NGOSS .................................................................... 18 4.3 NGOSS Contract Schemata .................................................................................. 18

4.3.1 NGOSS System Capability Objects............................................................... 19 4.4 Java Interface Declarations Schema ..................................................................... 19 4.5 Comparison of Contracts and Interface Schemata................................................ 20

5 Lifecycle and Methodology ................................................................................ 22 5.1 The NGOSS Lifecycle and Methodology............................................................. 22 5.2 Summary ............................................................................................................... 23

6 Information Modeling ........................................................................................ 24 6.1 NGOSS Shared Information and Data (SID) Model ............................................ 24

Page 4 of 38

6.2 OSS/J Common Business Entities ........................................................................ 24 6.3 Comparison of Modeling Concepts ...................................................................... 25 6.4 Collaborative Working ......................................................................................... 27

7 Program Direction .............................................................................................. 29 7.1 NGOSS eTOM Direction...................................................................................... 29 7.2 OSS/J API Road Map ........................................................................................... 30 7.3 Comparison of Program Directions ...................................................................... 31

8 Compliance and Certification............................................................................ 33 8.1 NGOSS Compliance Program .............................................................................. 33 8.2 OSS/J Certification Process .................................................................................. 34 8.3 Comparison of the NGOSS and OSS/J Certification Processes ........................... 35

9 Conclusions.......................................................................................................... 37

10 References............................................................................................................ 38

Page 5 of 38

1 Introduction Both the TeleManagement Forum’s NGOSS (New Generation Operations Systems and Software) program [15] and the OSS through Java Initiative (OSS/J) [16] were started around the same time (the year 2000); the NGOSS program has focused on the business and systems aspects of OSS-solution delivery (essentially the problem and solution statement) whereas OSS/J program has focused on the implementation and deployment aspects (essentially the solution realization and deployment using Java technology).

Both programs have the ultimate goal of promoting the delivery of reusable OSS solutions to service providers. The NGOSS initiative has delivered business-process and system frameworks, methodologies, UML information models, and resources to help members in the development of NGOSS-compliant components. The OSS/J initiative has delivered freely-available, testable API specifications, reference implementations, and test kits; commercial products implementing the specifications are now available

As the two programs evolved, it became clear, at a high level, that the programs were complementary: NGOSS concentrating on the technology-neutral aspects and OSS/J concentrating on the technology-specific aspects of network management. It was also recognized that, if the programs were indeed complementary, that collaborative working between the two organizations would be mutually beneficial and beneficial to the industry as a whole. Collaboration has been demonstrated with the development of OSS/J Core Business Entities that are based on TM Forum Shared Information and Data Model entities.

Further collaboration could include: joint marketing and promotions, joint training, joint press releases, and alignment of technical approaches. However, a prerequisite to going forward, is a need to demonstrate a fundamental alignment between the technical approaches of NGOSS and OSS/J.

Page 6 of 38

2 Purpose and Scope The primary purpose of this white paper is to show technical alignment, at a core level, between the technology-neutral aspects of the NGOSS program and the technology-specific realization approach of the OSS/J initiative. This will provide a solid technical basis for collaborative work between the two organizations.

The white paper will explore alignment of architectural principles, contracts, lifecycle, and information modeling techniques, and the overall direction of the two programs. The exploration will be based on analysis of stable, approved documents from both organizations.

Page 7 of 38

3 Architectural Principles Both NGOSS and OSS/J can show consistency with the principles of the Reference Model for Open Distributed Processing (RM-ODP) [1] and accepted mainstream software engineering techniques. Much of the text and analysis has been taken from existing TMF documents [2] and [3].

3.1 NGOSS Architectural Principles The following section provides an overview of the structure of the NGOSS architecture. Further details can be found in [4].

3.1.1 Modelling

Shared Information Model

An NGOSS system must be characterized by the usage of a common information model for enabling integration and interoperability. The information model should be more than just a standard representation of data—it must also define semantics and behavior of, and interaction between, managed entities. This set of information, all provided in a standard representation using standard data-types, is used to describe domain information (e.g., orders, network service and configuration definitions) in an NGOSS system. Security Policy Model

An NGOSS system should be designed according to an overarching security model. An implementation of an NGOSS system will require the setup and operation of one or more security mechanisms and policies in order to operate the NGOSS system in a secure manner. To this end, the security provisions have been structured around the ISO 17799 Information Security Management standards; it provides a framework to manage and operate an NGOSS system to meet the security objectives of an operating company. Policy Management Model

The NGOSS system architecture is defined as a policy-enabled management architecture. The term policy-enabled is defined as a system that operates using policies to make present and future decisions. In other words, if a system is policy-enabled, then the operation and management of that system is dependent on the execution of policies. Stated more generally, policies provide rules that govern behavior within a system. Policy rules are defined to meet business, system, or other objectives; consequently, policies may link one or more of the business, system (operational), and implementation views of the NGOSS system to each other.

Business Process Model

An NGOSS system must be characterized by the separation of the hard-coded behavior of components from the software that automates business processes across the components—i.e. an NGOSS system should be composed of defined services that

Page 8 of 38

can be orchestrated using scripting/process management technologies. An NGOSS system is further characterized by externalized descriptions of behavior expressed in a technology-neutral manner. Examples of this are:

The external description of a service is separated from one or more specific implementations through a representation called a contract. Contracts enable different aspects of the business, system, implementation and deployment views of an application to be integrated through the use of information models1;

A business process is represented by an executable meta-language description, which describes the flow of execution between contract instances; and

System behavior is controlled through the use of different types of management paradigms.

A business-process model may invoke lower-level business-process models. This means that a business-process step that a service provider desires to automate (e.g., verifying that the network can support the provisioning of a desired service) may be made up of one or more lower-level interactions with different system runtime entities that provide the necessary services; lower-level business-process models used in this way must be able to provide one or more contract instances to which the higher-level business process model can bind. That means that multi-level process management can be supported.

Process management is the realization of modern business management techniques in business process automation solutions. This includes techniques for defining, measuring, analyzing, testing, and deploying business processes as well as executing them. All of these activities form a part of business process automation, and so must contribute to the goal of improving business results for telecommunications service providers.

3.1.2 OSS Business Applications

An OSS business application provides services that realize the business-related functionality specified using NGOSS such as billing, rating and discounting, network data management, and others. OSS business applications deployed as an NGOSS solution are characterized as follows:

NGOSS Integrated Applications: NGOSS integrated applications are software components designed from the start for deployment in an NGOSS environment. Such applications are constructed with the following attributes:

Functionality accessible through NGOSS contractual interfaces;

Externally visible data conforms to a standard data model that can be mapped onto the NGOSS Shared Information and Data Model (SID); and

1 Contracts are dealt with in § 4

Page 9 of 38

Business process and policy management functionality that is separated from the implementation of the application and specified using a set of business process procedures (see Business Process Model above). In this manner, business process and policy management techniques are applied to the separate business process and policy definitions which in turn orchestrate the flow between components of solutions and applications.

Integrated Legacy Applications Integrated legacy applications are software components that were developed outside the scope of an NGOSS architecture and that have subsequently been made available as NGOSS components either by:

Fully encapsulating them with an NGOSS conformant wrapper (i.e., a software wrapper that provides access to the functionality of the legacy application through NGOSS contractual interfaces and maps data made visible by those contracts onto the common information model used by the NGOSS deployment into which the legacy applications is integrated); or

Selectively encapsulating specific functionality of the legacy application by developing adjunct software which provides a contractual interface and data mapping for that specific functional interface.

3.1.3 Framework Services

Framework services provide the distributed computing functionality needed to implement the architecture for correct operation. Interfaces to these services are provided through appropriate contract specifications.

OSS Framework Services: OSS framework services provide standard OSS/BSS capabilities whose functionality is common to many OSS/BSS services and which can be orchestrated by those OSS/BSS services. OSS Framework Services are an optional (but most likely will be included in some manner in all but the most trivial OSS/BSS deployment) part of the NGOSS architecture. Examples of OSS framework services include: Logging Services and Tracing Services.

Basic Framework Services: Basic Framework Services provide the basic service-distribution capabilities needed to support the patterns of interaction between components implementing business services. The Basic Framework Services may also be used by the other services. For example, the process definition for billing would actually be found by fetching it from the repository. The Basic Framework Services are not optional. Each NGOSS deployment must include at least one instance of each of the Distribution and Transparency Services that comprise the Basic Framework Services (e.g. naming, registration, or service location).

Distribution and Transparency Services: The TNA Distribution and Transparency Services are NGOSS Technology Neutral Architecture framework-level services that are fundamental to the construction,

Page 10 of 38

deployment and use of solutions in an NGOSS environment. An instance of each service must be included in each NGOSS deployment. Services include:

Naming: to shield prospective users from the complexities (and inherent incomprehensibility) of network addresses;

Repositories (or registry services): store and provide information about available distributed services;

Registration Services: provide for the administration of services including the addition, modification, and removal of services from the repository, and the ability to browse services previously added to the repository;

Service Location Services: facilitate matchmaking between potential producers and consumers. These services accept requests for a particular service from potential consumers and match that request against registered producers for that service stored in the repository.

3.1.4 Federation

There are generally two methods for federating systems services and data, either: by providing a communications protocol between services providing similar functions (service-level federation); or by providing mechanisms by which the underlying data (both system and user) can be shared (repository-level federation). Although both types of federation are recognized by the NGOSS architecture, due to scalability and performance issues introduced with the proliferation of pair-wise service-level federations, repository-level federation is the strongly recommended approach. Repository-level federation requires an agreement on a common data model between the federating entities. In addition, since federation is at the repository level (through a specialized repository service-interface implementing export and import repository interfaces), federation is achieved transparently to all other distribution and transparency services. For example, a client can request location of a service deployed and advertised in a completely different domain and enterprise using the identical interface (and without knowing where the service actually is) that would be used to locate a local service.

3.1.5 Inter-working Mechanisms

Inter-working mechanisms provide the baseline functionality which must be implemented in any NGOSS deployment to provide for the inter-working between independently deployed components and to support the plug-and-work paradigm at the most fundamental level.

Common Communication Mechanism: An NGOSS system must be characterized by the existence of a communication mechanism (e.g., a messaging bus or some other form of common communication). All software entities will use one or more communication mechanisms to communicate with each other. Each communication mechanism offers one or more different transport mechanisms. There may be more than one such communication mechanism within a given system implementation, and these mechanisms may

Page 11 of 38

represent different technology-specific mappings. The common communication mechanism must provide transport mechanisms consistent with the basic interaction styles defined in the architecture and any security policies that a service provider has defined for his/her network. More importantly, the use of a common communications mechanism enables the standardization of system-wide operations, messages, or events that can be distributed to interested components. This is an important point, as a transport just carries information, and by itself does not provide interoperability.

Invocation Mechanisms: These mechanisms provide a common means of performing the steps associated with invoking an operation on a service instance. There are several steps associated with invoking an operation on a service instance: location of the instance providing the service, proper usage of the communication mechanism, results handling, etc. Security and other policies must be applied at each step in the process. For this reason, invocation mechanisms must be defined as a convenient way to perform all of these steps and ensure the integrity of the operation in the context of the overall system and the consumer invoking the service.

3.2 The OSS/J Architecture One of the initial decisions made by the OSS/J initiative was to adopt J2EE as the fundamental implementation technology: this lead to the initial specification of strongly-typed tightly-coupled APIs using RMI over IIOP. When message-driven beans were added to the J2EE specification, the OSS/J initiative took the advantage and developed equivalent strongly-typed, but loosely-coupled, APIs using XML over JMS. With the publication of the J2EE 1.4 specification, the initiative is now actively looking at developing equivalent Web-services interfaces.

A second, and just as important, decision was to use the Java Community Process (JCP) [19] as the vehicle for standardizing APIs. In order to ensure consistency and interoperability between APIs developed using the JCP, a set of design guidelines, supported by a common API were developed; these guidelines help developers effectively use J2EE technology in the demanding network-management domain.

3.3 The J2EE Architecture In this section we introduce the basic elements of the J2EE architecture as used by OSS/J.

Figure 1 shows the 4-tiers within the J2EE architecture:

The Client Tier

The Web Tier

The Enterprise Java Beans Tier

The Enterprise Information Systems Tier (shown as a database in Figure 1)

Page 12 of 38

Figure 1—The J2EE v1.3 Architecture [5]

The first three tiers contain the four primary application components of the J2EE platform, as identified in the previous list.

The Applet Container

The Application Client Container

The Web Container

The EJB Container

The Applet and Application Client Containers are resident within the Client Tier. The Web Container is resident within the Web Tier, and the EJB Container is resident in the Enterprise Java Bean Tier. The J2EE architectural components are termed containers as they contain the actual client, integration, and server components developed to support the business problem at hand.

3.3.1 Object Serialization

Object serialization is a feature of the base J2SE platform that allows for marshalling of objects to and from a secondary storage medium or communications channel. Object serialization is supported entirely by the Java runtime and only requires programmer intervention in extreme cases or when derived, transient attributes or relationships between one object and another need to be reconstructed.

3.3.2 JNDI (Java Naming and Directory Interface)

The J2EE platform relies on the JNDI (Java Naming and Directory) services specification to provide run-time information-location services. The JNDI consists of two interface specifications: the JNDI and the JNDI SPI (Service Provider Interface) specifications. The JNDI is an abstraction of the general concepts of naming, directory, and trading. The JNDI SPI is used by the JNDI implementation to

Page 13 of 38

communicate with an underlying naming, directory and trading service implementation in a neutral fashion.

3.3.3 JTA (Java Transaction API)

In the area of transaction management, J2EE is compliant with the Java mapping of the OMG Transaction Service Specification, version 1.1. Transaction services are implemented at the EJB container level, and augmented by the JTS and JTA specifications (Java Transaction Service and JavaTransaction API respectively). The EJB specification allows for beans to be created and deployed using either a container-managed persistance model wherein transactional integrity is provided for transparently by the EJB application server; or in a bean-managed persistance mode, wherein the bean implementation is responsible for managing its persistance and transactional integrity requirements.

3.3.4 JCA (J2EE Connector Architecture)

The JCA is the formalization of the interface to resource managers and external enterprise information systems. Through the JCA, EJBs have a standard interface for communicating with external sources of information such as back-end systems or network elements. The JCA is an extension of the basic concept embodied in the pre-existing JDBC mechanism. Using the JCA it will be possible to integrate non-JMS-compliant messaging mechanisms, along with other back office systems cleanly into the EJB environment. The JCA defines the interface between the Enterprise JavaBean Tier and the Enterprise Information Systems Tier.

3.3.5 JMS

JMS, or the Java Messaging Service, is an API for communications between applications and/or application components using an enterprise messaging system2. JMS provides for both directed and publish/subscribe messaging capabilities.

The EJB specification contains provisions for communication using JMS via message-driven beans (MDB). The MDB can receive messages at a single specified interface. The MDB specification qualifies the behavior of the basic JMS by stipulating that the order of message delivery is not guaranteed.

3.3.6 RMI and RMI-IIOP

In the J2EE realm, synchronous communications between an EJB client and an EJB server (an EJB server is an EJB implementation running within a container hosted by a J2EE application server) is accomplished via RMI. No other form of communication is allowed from the client-server perspective. All J2EE platform EJB implementations are required to support RMI via IIOP (RMI-IIOP), but are free to provide support for other protocols as well.

2 Such as TIBCO Rendezvous or the IBM MQ series of products

Page 14 of 38

3.4 Comparison of Architectural Principles In this section we discuss the alignment between the architectural principal of NGOSS and J2EE in the context of OSS/J.

3.4.1 Distribution Support

Through the basic features of J2EE, such as RMI-IIOP, JNDI, JMS, and JCA it is no longer necessary to architect the client and the server simultaneously. Server architecture is allowed to focus on the functionality being delivered, without regard for the manner in which clients access the functionality.

3.4.2 Core Communications

Outside of the RMI-IIOP, message-driven, and connector-based communication mechanisms, the EJB specification clearly prohibits the establishment of communication mechanisms by an EJB. This architectural constraint empowers the container to manage the communication details while isolating the bean from making any decisions or assumption on the actual communication mechanism.

3.4.3 Transaction Management

The J2EE platform implicitly handles many of the complicated aspects of transaction management such as transaction-information propagation and coordination between multiple transaction managers. At this time the exact requirements of the NGOSS in this area have not been well defined in terms of the specification of the infrastructure services for transaction management. Subsequent releases of this application will provide more information in this area.

One important note to make at this time is that the J2EE specifications related to transaction management do not support nested transaction blocks.

3.4.4 Scalability

J2EE containers are a mechanism for supporting simplified scalability of distributed applications, without requiring the application developer to expend additional effort. The J2EE container provides the component developers with transparent support for transactions management, database connections, lifecycle management, and other mechanisms that impact performance, scalability, and reliability. Because scalability mechanisms are intentionally hidden below the J2EE API standard, J2EE container vendors offer a range horizontal and vertical scalability solutions. Additionally, the flexibility of the underlying 4-tier architecture, based on techniques proven time and again by the internet, guarantee the scalability of applications built on the J2EE platform.

3.4.5 Deployability

J2EE applications are composed of one or more J2EE components and one J2EE application deployment descriptor. The deployment descriptor lists the application's components as modules. A J2EE module represents the basic unit of composition of a J2EE application. J2EE modules consist of one or more J2EE components and one

Page 15 of 38

module-level deployment descriptor. The flexibility and extensibility of the J2EE component model facilitates the packaging and deployment of J2EE components as individual components, component libraries, or J2EE applications.

From an NGOSS architectural perspective, the J2EE module represents the most basic form an NGOSS component. In the Java world, a J2EE module is deployed within a .JAR (Java Archive) file. The .JAR file is the unit of binary deployability, the modules it contains are binary implementations of functionalities that are subject to third party composition.

Figure 2—J2EE Deployment View [5]

Deployment descriptors are XML files, whose schema is specified by J2EE.

3.4.6 Separation of Business Process from Software Implementation

As an implementation of component-based distributed systems architecture, J2EE supports the separation of business process details from software implementation details. This section of the document discusses this support.

3.4.6.1 Contract-Defined Interfaces The run-time aspects of NGOSS technology-neutral contracts will be implemented via either entity beans or session beans. In accordance with the established EJB programming model, the NGOSS contract should first be translated into a Java language construct called an interface. The Java interface declares invocation syntax, without defining implementation semantics. Once a Java interface representing the contract(s) has been created, a second Java language construct, a

Page 16 of 38

Java class must be created that implements the interface (i.e., defines the implementation semantics). Contracts are dealt with in further detail in Section 4.

3.4.6.2 Run-time Service Discovery J2EE provides for run-time service discovery via the use of the Factory Object pattern. Entities wishing to make use of a service provide by an EJB, do so via the use of a Java interface, realizing an implementation of the interface using a factory object obtained through a JNDI lookup.

3.4.6.3 Policy Enabled At this time, Java technology provides no direct support for policy as described by NGOSS [4].

3.4.6.4 User Roles and Security In addition to the basic security model of J2SE, J2EE provides for the EJB security model, as well as the JAAS (Java Authentication and Authorization Specification) API.

In the area of authentication, J2EE accounts for authentication at the web tier and the EJB tier, as well as allowing for authentication at the enterprise information tier, if integration into an enterprise information system is required. In the area of authorization, J2EE supports a declarative model, as well as a programmatic model. In either model, J2EE relies on access control lists to determine what resources and services an authenticated entity is allowed to access.

The J2SE platform includes a utility called Policy Tool that is used to create and modify the policy files used by the J2SE security subsystems.

At this time the portion of the NGOSS architecture relating to security services is undefined. Subsequent releases of this application note will clarify the relationship between the J2EE security capabilities and the NGOSS architecture and requirements.

3.4.7 Shared Information

While the J2EE architecture does not have any explicit support for the concept of shared information or federated information services as defined in NGOSS TNA (see § 3.1.4), the architecture supports the development of shared information service in a number of ways. OSS/J supports the concept of shared information through the Common Business Entity model, see § 6.

3.4.7.1 Definition J2EE is, as previously noted, built on top of the J2SE, and therefore is dependent on the Java programming language for the definition of data structures from a programmatic standpoint.

3.4.7.2 Data Stewardship The J2EE component-model (defined by the EJB specification) provides for session beans to deliver service-oriented functionality, and entity beans that deliver information oriented functionality. Furthermore, both entity and session beans are created by the use of factory classes (objects). Creation of data stewards with simple

Page 17 of 38

transactional and relational integrity constraints can be handled via the entity bean and entity bean factory approach. For more complicated transactional or relational needs session beans that implement data stewardship services can be created.

3.4.7.3 Information Adaptation The J2EE platform is built upon the J2SE platform. Through reflection and introspection (both features of the J2SE platform), it is possible to create generic mechanisms for data driven (e.g. via scripts, property files, etc) adapters. Reflection is a base feature of the Java language that allows runtime level access to the structure (meta-information) of objects and classes.

3.4.7.4 Data Mediation J2EE relies on the use of RMI-IIOP and the JCA for the exchange of information between a J2EE environment and external, non-J2EE entities. The J2EE specification does not preclude the creation of RMI implementations that rely on technologies other than RMI. In fact, the RMI specification and the J2EE use of the RMI specification are designed to specifically support a variety of underlying transport technologies.

The IIOP aspect of RMI-IIOP provides for the exchange of information between two entities in a fashion that is independent of computing platform architecture. JCA provides a structured API with support for the addition of proprietary interfaces to enable the integration of non-Java resources into the J2EE environment in a manner that enables the J2EE EJB container to manage the integration and ensure the stability of the EJB environment.

3.4.7.5 Run-time Location of Information The J2EE supports the runtime location of information through the JNDI. JNDI provides the ability for client applications to bind arbitrary information to a logical name. Part of the arbitrary information that will be associated with meta-information in the NGOSS registry will be the identity of the information provider for instances of information described by said meta-information.

3.5 Summary of Architectural Principles The above analysis clearly shows that there are many areas, for example communication services, the separation of business process from implementation, Basic Framework Services, and invocation mechanisms where J2EE directly implements the principles of NGOSS. There are other areas, for example contracts, shared information, and security where the particular style of implementing J2EE can support the principles of NGOSS. OSS/J supports NGOSS Framework Services such as inventory, discovery, service activation, and billing. Issues of policy-based management, transactions, implementation patterns, and coupling styles are areas that need further investigation.

Page 18 of 38

4 Contracts and Interface Schemata Contracts form an important part of NGOSS; whilst contracts form part of some software development methodologies, the scope of NGOSS contracts goes well beyond the scope traditional software contracts. For the purpose of this section, we shall restrict the discussion to the aspects of System Capability Objects specified in NGOSS and Java interface declarations

4.1 Introduction to Contracts In this section we give some background into the use of the contract metaphor in programming practice.

Modular software construction based on a model of procedures with a focus on behaviour across interfaces is a fundamental aspect of programming practice. The metaphor of a contract with its concepts of invoker, performer, rights, and obligations has been a popular one as a basis for interface specification [8], [1], and [9].

The separation of interface specification (pure design) from interface implementation has been a key concept in programming languages such as C++ and Java. The unambiguous specification of the syntax of interfaces is commonplace either using language-specific declarations such as Java interface declarations or language-neutral declarations such as CORBA IDL. By contrast the unambiguous specification of the behaviours of interfaces is almost ignored in programming languages with the exception of Eiffel [8]; most rely on informal commentary or evocative naming to define behaviour. Although there have been a number of attempts to formalize the specification of interface behaviour by mean of formal description languages such as SDL, Lotos, Z, and Estelle, none has found universal acceptance. Axiomatic specification of interfaces in terms of preconditions, postconditions, and invariants has found some favour in attempts to formalize the specification of interface behaviour [10].

4.2 The Contract Metaphor and NGOSS Contracts are becoming an increasingly important concept within the evolving NGOSS architecture; they are recognized as the “…fundamental unit of interoperability…” [11]. The concept of a contract exists in all four NGOSS viewpoints; it includes aspects of the solution in addition to the software interface specification.

The basic architecture underlying NGOSS defined is that of a distributed, interface-oriented architecture: a provider entity offers functionality across its interface—both the consumer and the entity have behaviour discernable across their mutual interface; it is this behaviour that carries the functionality.

4.3 NGOSS Contract Schemata The most recent document describing NGOSS contract schemata is [11]. The schema for the Systems Contract is divided into five main parts:

Page 19 of 38

• General Contract Part: this part identifies the contract and goals in an unambiguous way, and hosts a placeholder for a textual description of the contract;

• Functional Part: this part defines the capabilities provided by the contract, constraints placed upon the use of those capabilities, and the context in which it can be used.

• Management Part: this part defines the management capabilities needed to operate capabilities, assess resource cost, assess service cost, assign QoS, describe geographic constraints, describe resource constraints, describe operational constraints and describe legal constraints of a contract.

• Non Functional Part: this part defines aspects needed for proper operation of the capabilities specified by the contract (e.g., security and management operations), as well as other considerations (e.g., cost).

• System-specific Model Part: this part contains various types of UML models to support the specification and description of the functional and non-functional parts. This part supports the lifecycle management of the service, and any resources required to configure and maintain that service, in an OSS architecture.

4.3.1 NGOSS System Capability Objects

From [11] and [4], the functionality of a System Service (e.g. the inventory service) is defined by a number of System Capability Objects. The schema for a System Capability Object is reproduced in Table 1. From the table, we conclude that the granularity of a System Capability Object is equivalent to that of an EJB method.

4.4 Java Interface Declarations Schema EJB interface specifications are defined using a schema defined in the Java programming language. The schema supports the declaration of:

• Superinterfaces

• Method signatures including parameter types

• Method return type

• Method exceptions thrown

• Inherited methods

• Specially marked textual comments for processing by documentation tools such a Javadoc. (An example is show in the JVTActivationSession of the OSS/J Service Activation API [18])

Page 20 of 38

Field Definition Description

Input Entities String array This is a list of Entities that must be sent to the contract provider to use a specific capability (similar to commonly known input parameters in an interface signature).

Output Entities String array This is a list of entities that are returned by the Capability object to the Contract container, when a specific capability is used. This is similar to commonly known output parameters in an interface signature. Operates similar to above.

Pre-Conditions Array of SID pre-condition objects This field describes any pre-conditions necessary to invoke the Capability (not the overall Contract). The Contract is thus viewed as a container of Capability objects. Since each Capability is itself an object, each Capability has associated with it its own set of pre-conditions that are defined using the same approach as the pre-condition for the Contract is defined.

Termination Textual attribute This field contains the response to invoking this Capability.

Post-Conditions Array of SID post-condition objects This string describes the final state that the environment is in after this Capability was either used successfully or an exception occurred. There can only be one state that the environment is in. If multiple Capabilities were invoked, then each Capability object has its own Termination and Post-Conditions that describe its state. Thus, the state of the Contract is the collective state of the execution of each of its Capabilities.

Post-Condition System Exceptions

Array of SID Exception objects If an error or other abnormal condition results in executing a System Capability, a System Exception will be raised. This is an object that defines a new state which the environment will be transitioned to as a result of this error.

Vendor Extensions Array of SID VendorExtension objects

This field is a placeholder for vendor extensions of the contract, to express additional characteristics and/or behavior of a standard System Capability defined by a vendor as specified by CDO.

Table 1—System Capability Object Schema from [11]

4.5 Comparison of Contracts and Interface Schemata Any mapping of an NGOSS System Contract specification to an NGOSS Java Implementation Contract would have to be to a Java interface declaration. Hence for the purposes of this comparison we compare the NGOSS Capability Object Schema to the EJB interface declaration schema, see Table 2.

Page 21 of 38

Element Identifier

Capability Object Schema Elements

Java Method Declaration Schema Elements

Comments

1 Input Entities Method signature

2 Output Entities Return type Java methods only return one value3

3 Pre-Conditions (condition objects)

Input-parameter type information

Java programming language does not natively support predicate calculus; OSS/J uses Javadoc

4 Post-condition system exception

Exception

5 Post-Conditions (condition objects)

Return type Java programming language does not natively support predicate calculus; OSS/J uses Javadoc

Table 2—Comparison of System Capability Object and Java Method Specification Elements

Reviewing Table 2, there appears to be good alignment for items 1, 2, and 4 in the two schemata. EJB does not natively support pre- and post-conditions (items 3 and 5). Some limited pre- and post-condition support is offered by the typing of EJB input and return values. We assume that SID condition objects support predicate calculus as per the Hoare model [10]. More general pre- and post-conditions have been informally introduced into the EJB model using Javadoc constructs.

3 The “value” can, of course, be an array of values or an iterator

Page 22 of 38

5 Lifecycle and Methodology An important new document in the NGOSS suite of documents, is the NGOSS life cycle and methodology specification document, GB927 [6]. As this document has only just been published, its impact on OSS/J lifecycle and methodology is still being assessed.

5.1 The NGOSS Lifecycle and Methodology The NGOSS lifecycle guidelines, documented in GB927, are used to organize problem-solving activity into manageable and controllable subordinate efforts. The lifecycle guidelines specify four primary phases along with the recommended entry criteria, inputs, outputs and exit criteria for each phase.

The methodology guidelines are also contained in GB927 and describe the recommended methods to be used to conduct problem-solving efforts within each phase of the lifecycle as well as across the full lifecycle. The document describes the SANNR (Scope Analyze Normalize Rationalize and Rectify) method and how it is applied iteratively throughout each phase of the lifecycle to generate the requisite outputs from the received inputs. The methodology also specifies the usage of the NGOSS Use Cases and NGOSS Contracts to capture the understanding of the problem and the understanding of the solution, respectively. The SANNR method is a five-step process for problem-solving: scope, analyze, normalize, rationalize and rectify and is used to create both the use cases and the contracts in addition to other artifacts.

The lifecycle is made up of four phases with each phase focused on satisfying the interests of its primary stakeholder:

• Business – understand the business need (problem statement)

• System – understand the system solution (problem solution)

• Implementation – understand the solution realization

• Deployment – understand running the solution

Each stage of the lifecycle uses the methodology to specify the work process used to satisfy the interests and concerns of its primary stakeholder. The use cases and contracts are the artifacts evaluated to determine if the stakeholder interests have been satisfied. The use cases communicate the problem understanding and the contract communicates the solution understanding. This process is repeated on all the lifecycle stages until all the interests of all the primary stakeholders have been satisfied.

The net results of using the lifecycle and methodology to organize problem-solving activities are solution realization artifacts, organized as collections of interacting and connected components cooperating to accomplish a purpose: a system.

Page 23 of 38

NGOSS is focused on helping stakeholders to better understand the problem and the problem solution. OSS/J is focused on helping stakeholders to better realize problem solutions. The lifecycle and methodology provide a useful framework for aligning these complementary problem-solving approaches around the goal of providing stakeholders improved operational and business support system solutions.

5.2 Summary GB927 is a new document and was not available during the development of the current suite of OSS/J APIs; however eTOM [7] was available and was used. The lifecycle and methodology guidelines could form the basis of a more disciplined approach to selecting and defining new OSS/J APIs.

Page 24 of 38

6 Information Modeling The OSS/J initiative has tried, as far as possible, to make its specifications information-model agnostic; this has been accomplished by specifying abstract information models which can be specialized to accommodate various telecommunications domains. The NGOSS Shared Information and Data (SID) [12], set out to federate information models from various telecommunications domains. These approaches have lead to an opportunity for collaborative working between the TMF and OSS/J.

6.1 NGOSS Shared Information and Data (SID) Model The SID addresses service providers’ need for a shared understanding of information and data concepts, definitions, and models. The definitions focus on business-entities and attributes. A business entity is a thing of interest to the business, while attributes are facts that further describe the entity. Together they provide a business-oriented perspective of the information and data. Combined with business-oriented UML class models, the definitions provide the business view of the information and data. Design-oriented UML class models and sequence diagrams provide a system view of the information and data.

The SID content is organized using the SID Model Framework [12]. The SID framework was developed by the application of data-affinity concepts to an enterprise’s processes and data, resulting in a set of domains. The framework provides a non-redundant view of the shared information and data. It is envisioned that the use of business-entity definitions within the eTOM [7] model will provide a business view of the shared data. The SID Model Framework is shown in Figure 3.

All domains are not yet covered by the SID model. Domains covered include: Customer, Product (Product and Product Instance), Service, Resource (Physical and Logical), and Common Business Entities, such as Party, Location, Business Interaction, and Agreement that cross more than one domain. The sources for the SID model include a variety of industry models, as well as models contributed by Telemanagement Forum member organizations.

6.2 OSS/J Common Business Entities OSS/J API developers face the task of defining and modeling telecommunication-management core concepts. These core concepts include: individuals (such as employees) and organizations (such as customers); products, services, and resources; locations and addresses, together with interactions between them. These core concepts represent the who, what, when, where, and why that make up the set of fundamental concepts present in today’s world.

Perceptive developers, once they have implemented these concepts, will try to reuse the implementations in subsequent projects. As well as being time-consuming, this effort also encourages inconsistency—a major threat to interoperability.

Page 25 of 38

Product

Market / SalesMarket Strategy & Plan

Market Segment

Marketing Campaign

Competitor

Contact/Lead/Prospect

Sales Statistic Sales Channel

Product

Product Specification Product Offering

Strategic Product Portfolio Plan Product Performance

Product Usage Statistic

CustomerCustomer

Customer Interaction

Customer Order

Customer Statistic

Customer Problem

Customer SLA

ServiceService

Service Specification

Service Applications

Service Configuration

Service Performance

Service Usage

Resource

Supplier / PartnerSupplier/Partner

S/P Plan

S/P Interaction

S/P Product

S/P Order

S/P SLA

Enterprise Common BusinessParty

Location

Business Interaction

Policy Agreement

Applied Customer Billing Rate

Customer Bill

Customer Bill Collection

Customer Bill Inquiry

Service Strategy & Plan

Service Trouble Service Test

Resource

Resource Specification

Resource Topology

Resource Configuration

Resource Performance

Resource Usage

Resource Strategy & Plan

Resource Trouble Resource Test

S/P Problem

S/P Statistic

S/P Bill Inquiry

S/P Payment

S/P Performance S/P Bill

(Under Construction)

Product

Market / SalesMarket Strategy & Plan

Market Segment

Marketing Campaign

Competitor

Contact/Lead/Prospect

Sales Statistic Sales Channel

Product

Product Specification Product Offering

Strategic Product Portfolio Plan Product Performance

Product Usage Statistic

CustomerCustomer

Customer Interaction

Customer Order

Customer Statistic

Customer Problem

Customer SLA

ServiceService

Service Specification

Service Applications

Service Configuration

Service Performance

Service Usage

Resource

Supplier / PartnerSupplier/Partner

S/P Plan

S/P Interaction

S/P Product

S/P Order

S/P SLA

Enterprise Common BusinessParty

Location

Business Interaction

Policy Agreement

Applied Customer Billing Rate

Customer Bill

Customer Bill Collection

Customer Bill Inquiry

Service Strategy & Plan

Service Trouble Service Test

Resource

Resource Specification

Resource Topology

Resource Configuration

Resource Performance

Resource Usage

Resource Strategy & Plan

Resource Trouble Resource Test

S/P Problem

S/P Statistic

S/P Bill Inquiry

S/P Payment

S/P Performance S/P Bill

(Under Construction)

Figure 3—SID Model Framework

The OSS/J initiative has taken the opportunity to improve the efficiency of API developers and maintain consistency, by defining, modeling and implementing these core concepts.

The OSS/J Core Business Entity (CBE) model embodies these core concepts, their associated information models, and the specification of the interfaces, which involve these core concepts. This model is used as the cornerstone for all OSS/J API development.

Being a core model, it is natural that there should be a strong relationship between the CBE model and the OSS/J Common API. For example, as new APIs are developed, the CBE model will be extended to include any related business entities; these entities may be included in future releases of the Common API as both Java and XML specifications.

6.3 Comparison of Modeling Concepts The CBE model (a subset of the SID model) is based on the needs of the OSS/J APIs in already defined. The subset may represent complete portions of the SID model or partial portions that contain only higher-level SID entities. As new APIs are added or existing APIs are enhanced, the CBE model will expand based on the scope of the new or enhanced API. For example, consider the SID Product Offering Aggregate

Page 26 of 38

Business Entity (ABE) shown in Figure 4. An ABE is a cohesive group of related entities.

Figure 4—SID Product Offering ABE

The SID model provides a business view and a system view. The CBE model uses these views as input to construct an implementation view. The business entities represented as entity classes in the SID views are transformed into interface classes in the CBE implementation view.

The CBE model could adopt only the Product Offering business entity, its association to Product Specification, and the association between Product Offering and itself (via Bundled Product Offering). The CBE model would be consistent with the SID model; it would just not contain the same level of detail. This level of adoption would represent the current level of detail contained in the OSS/J Inventory API. Or, the CBE model adoption could also include the two subclasses of Product Offering. This adoption would necessitate a change to the Inventory API.

The CBE model adoption strategy may also exclude SID-modelled ABEs. For example, there is no current need for product-pricing rules in any OSS/J APIs. Therefore, the SID Product Pricing Rule ABE would not be adopted.

Page 27 of 38

6.4 Collaborative Working The CBE may be extended to include extensions of the SID if the SID does not contain the necessary business entities. These extensions will be reported back to the SID team for consideration for inclusion in the SID model. Existing business entities within the SID model may also be further detailed to support an OSS/J API. These details will also be reported back to the SID team. Figure 5 shows a sample of OSS/J API Trouble Ticket business-entity attributes that could be included as SID Trouble Ticket business-entity attributes. The SID Trouble Ticket business entity does not currently have any attributes that characterize it.

Methods added during the development of an API will also be passed on to the SID team for inclusion in the system view of the SID model. Figure 6 shows a sample of OSS/J API Trouble Ticket methods that could be contributed to the SID model.

Figure 5—Sample OSS/J API Trouble Ticket Attributes

Page 28 of 38

Figure 6—Sample OSS/J Trouble Ticket Methods

Page 29 of 38

7 Program Direction 7.1 NGOSS eTOM Direction

The Telemanagement Forum’s Enhanced Telecom Operations Map (eTOM) [7] aims at describing all the enterprise processes required by a telecom service provider to deliver services. The eTOM version 4.0, illustrated in Figure 7, is now a Telemanagement Forum approved document. The framework has evolved from the Telecom Operations Map, which focused on operations (especially fulfillment, assurance and billing aspects), to provide a business-process blueprint for telecom service providers to understand and optimize internal-process reengineering, partnerships, alliances, and general working agreements with other enterprises.

Figure 7—TM Forum eTOM Framework Version 4.0

The eTOM framework provides a decomposition of business processes starting from a coarser-grain view addressing business aspects, to a fine-grained view addressing activity aspects; the level of decomposition depends on the significance of the process and priority to the business. In the static decomposition, all processes are fully described as well as their inter-relationships. These relationships are further described through the provision of example scenarios illustrating the dynamic interaction of these processes.

Page 30 of 38

The eTOM framework has been developed as a tool for analyzing and evaluating the cost and performance of service providers’ existing processes and to help them develop new processes.

7.2 OSS/J API Road Map The mission of the OSS/J initiative is to define a critical mass of Java APIs with the intention of fostering a market for OSS components. The OSS/J API roadmap identifies the set of APIs that make up a full OSS solution—that is, the set of APIs that supports flow-through service fulfillment, assurance, and billing. The APIs currently identified in the roadmap are shown in Figure 8. The core set of APIs constitutes the set of APIs that have been identified as the enabler to automate operations in the majority of the business scenarios.

Figure 8—OSS/J Road MapVersion2.0

The colouring scheme enables the reader to distinguish between different stages of the API lifecycle. Some APIs are currently available—that is, the specification has been approved by the Java Community Process after a public review and that the reference implementation and test compatibility kit are freely available. Some APIs are under public review—that is, the specification is publicly available for comments; some APIs are identified as the next priority for development. The identification of

Page 31 of 38

priorities is lead by the OSS/J Advisory Council that is composed of telecom service providers.

Work on a future API specification can take two forms: active lobbying to find a champion to lead the Expert Group that defines the specification and develops the reference implementation and test kit; or a small group of experts working to defining a high-level specification of the API.

7.3 Comparison of Program Directions eTOM provides a global business-process framework taking into account processes whether they are manual or automated. The OSS/J API roadmap focuses exclusively on the significant OSS business processes that can be automated: OSS/J’s scope is more focused as we can see from Figure 9.

Figure 9—OSS/J API Roadmap Mapped to eTOM Framework.

Figure 9 shows a mapping of the OSS/J core APIs in Figure 8 to a sub-section of the eTOM framework described in Figure 7. This mapping highlights the focus of the OSS/J initiative on automation of operations for telecom service providers; it also highlights the coverage automation with regard to the elements identified in the eTOM framework.

Page 32 of 38

The OSS/J API Roadmap has been derived from many of the OSS scenarios, application notes, and examples published by the Telemanagement Forum with respect to TOM and eTOM. Furthermore, like the eTOM specifications, the OSS/J API specifications are deriving from the application of relevant telecom standards such as those from the ITU-T.

In conclusion, OSS/J API program is focused on automating operations while the eTOM framework covers all business process aspects for telecom service provider enterprises. But within its focus domain the OSS/J API program covers adequately the business processes identified by eTOM that are candidate for OSS automation.

Page 33 of 38

8 Compliance and Certification 8.1 NGOSS Compliance Program

The NGOSS compliance program is currently on trial and has not yet been offered for public use. It focuses on assessing interoperability potential of a solution or a product. This assessment is based on the guidelines and specifications developed through NGOSS programs such as eTOM, SID and NGOSS architecture. The testing is performed according to a matrix approach defined in the NGOSS Compliance Testing Strategy Technical Specification [14]. NGOSS certification favours as much as possible automated self-testing in order to contain the cost. Figure 10 describes the current process that is on trial to certify a solution or a product for NGOSS compliance.

Figure 10—NGOSS Certification Process

The certification process requires a solution submitter to implement component testing within the solution; the component testing takes the form of data captured whilst the solution is running. A tool interprets the generated data and base data, describing the layout of the solution, against a set of business rules. The output of the tool is a compliance report detailing compliant and non-compliant events with an associated level of severity. The data capture will be supported by third parties licensed by the TM Forum.

Subsequently, an Issuer of Certification, currently a subgroup within TM Forum, will analyze the compliance report and, depending on certification criteria, may issue a

Page 34 of 38

certification. Certification criteria may include the reporting of non-compliant events and the significance of the data set.

8.2 OSS/J Certification Process The OSS/J certification process that has been in place since 2002 was designed to be a lightweight process while being technically strict. Figure 11 provides a visual description of that process.

Figure 11—OSS/J API Certification Process

First product developers have free access to OSS/J API specifications as well as reference implementations. They can use the specification and the code to develop any OSS/J API within their products. To certify that API, they can freely download the test suite, called a Technology Compatibility Kit within the Java Community Process. Running the test suite against the API they developed in their product will generate a test report. If a successful test run is reported, this can be transmitted to the OSS/J certification committee through a registration form. The OSS/J certification committee will validate the report and the process used to create it and will acknowledge the certification of the product with regard to the specific API.

The certification can then be published through a reference on the OSS/J certified product webpage that points back to the test report stored on a publicly accessible page of the website of the company that developed the product and filed it for OSS/J API certification.

While this process relies on free access and self-testing it also ensures a rigorous testing as the technology compatibility kit associated to each API includes extensive

Page 35 of 38

compliance test suites and generates comprehensive test reports. Finally the publication of the test report eases the procurement of certified products for higher flexibility and easier integration.

8.3 Comparison of the NGOSS and OSS/J Certification Processes The NGOSS and OSS/J certification processes rely as much as possible on automated self-testing. Whilst the OSS/J certification process applies exclusively to products, the NGOSS process is aimed at both solutions and products. In its current state (NGOSS release 4.0) it is to be noted that NGOSS compliance criteria for solution certification are more crisply defined than the one for component certification.

Figure 12—NGOSS Process to Capture Third-party Certification Delta

Therefore we can consider that NGOSS certification applies to a wider footprint in the OSS domain than the OSS/J certification that has been exclusively designed to test the API aspect. This is reinforced by the process described in Figure 12 that enables the NGOSS certification to accept other industry certifications in order to fast track the complete NGOSS certification. Therefore a product that has been OSS/J certified for a specific API can claim that, while going through the NGOSS

Page 36 of 38

certification process, it will only have to be submitted to the NGOSS compliance tests that are not covered by the OSS/J certification in order to become NGOSS certified.

We can now conclude that the OSS/J certification applies to a particular case and that the NGOSS certification has a wider application domain, including the OSS/J certification domain, and both certification processes have been designed leveraging similar principles and goals.

Page 37 of 38

9 Conclusions We have demonstrated the overwhelming synergy between the NGOSS and OSS/J programs:

the programs are deeply aligned architecturally;

the programs are complementary in modeling aspects with the adoption of SID-based CBEs;

OSS/J testing and branding, although well-established, is a sub-set of the proposed NGOSS testing and branding;

System Capability Object definitions are directly mappable in Java interface declarations; and

the OSS/J road map is firmly rooted in eTOM.

The alignment of the programs is quite striking (but not surprising); where there are differences they are ones related to the different scopes of the respective programs.

Further Study and Collaboration This paper has covered the broad sweep of the two programs; during its preparation a number of issues were noted as worthy of further study. One of the most important facets of the NGOSS programs is that of lifecycle—largely absent from the OSS/J program; lifecycle, and the related issue of traceability of contracts, could form the basis of some interesting further study. The OSS/J program has gone to great lengths to develop a duality between loosely-coupled JMS/XML interfaces and tightly-coupled RMI/IIOP interfaces; OSS/J is currently actively pursuing parity with Web-services interfaces. Again this could form the basis of valuable further study.

The fundamental alignment of the programs makes a compelling case for a closer working relationship between the two organizations. Although it is not within the scope of this paper to propose the form of such a relationship, a number of activities spring to mind, including: ad hoc and formal liaisons to ensure alignment of future work; mutual recognition of certification programs; joint marketing; and collaborative working to leverage the expertise of the respective organizations.

A closer working relationship would not only benefit the two organizations but also benefit the industry as a whole.

Page 38 of 38

10 References

[1] Information technology – Open distributed processing – Reference Model: Overview. ISO/IEC 10746-1:1998. http://www.iso.org/

[2] Fleck, J.J., “Overview of the Structure of the NGOSS Architecture”. Hewlett-Packard Company, May 2003.

[3] NGOSS Phase 1 Technonogy Note—J2EE, TMF 056. TeleManagement Forum, June 2001.

[4] The NGOSS Technology-Neutral Architecture, NGOSS Release 4.0. TMF053. TeleManagement Forum, January 2004.

[5] Java 2 Platform, Enterprise Edition 1.4 (J2EE 1.4) Specification. Java Community Process. http://www.jcp.org/en/home/index

[6] The NGOSS Lifecycle Methodology. GB 927. TeleManagement Forum, January 2004.

[7] Enhanced Telecom Operation Map. GB921. TeleManagement Forum, January 2004.

[8] Meyer, B., Object-oriented Software Construction. Prentice Hall, 1988.

[9] Mitchel, R. and McKim, J., Design by Contract, by Example. Addison-Wesley, 1997.

[10] Hoare, C.A.R., “An Axiomatic Basis for Computer Programming”, CACM, Vol 12, No.10, October 1969.

[11] NGOSS Architecture Technology Neutral Specification, Contract Descriptions: System and Business View, NGOSS Release 4. TMF 053B. TeleManagement Forum, February 2004.

[12] Shared Information/Data (SID) Model, System View Concepts and Principles. NGOSS Release 4.0. GB926. TeleManagement Forum, February 2004.

[13] OSS/J API Roadmap, V1.5. OSS/J Initiative, March 2004.

[14] NGOSS Compliance Testing Strategy, Technical Specification. TMF 050. TeleManagement Forum, February 2004.

[15] The TeleManagment Forum. http://www.tmforum.org/

[16] The OSS through Java Initiative. http://java.sun.com/products/oss/

[17] Core Business Entities Model White Paper. OSS/J Initiative. 2003. http://java.sun.com/products/oss/pdf/COM-ARCH-CBE_Model_vdot33.pdf

[18] OSS/J Service Activation API Specification. http://java.sun.com/products/oss/start_download.html

[19] Java Community Process. http://www.jcp.org/