Introduction

An “end-to-end” service based approach to FAB is important as it focuses on the services which service providers sell to their customers. A service based approach is not easy to achieve as services are complex and traverse many different domains or “silos” within the service provider environment. Service topology is typically not part of existing (Resource) inventories; existing tools do not have appropriate functionality and Service related problem analysis and resolution takes to much time, because typically no central service documentation exists

Service Inventory Management documents the service topology, stores products, services and resources and the relations between these objects. It stores the relationships between the objects in the service tree as well as the horizontal relationships, the sequence steps needed to deliver the service. Further it addresses the need for better structure and various key relationships across services (external/internal services, direct/indirect dependencies) and closer integration with processes and tools is required, such as those for incident and problem management.

Further, it is becoming more and more difficult to maintain an overview of all the Services available, and this organic growth is threatening to become unmanageable. The reasons for this include the fact that Services consist of a network of components, the intricacy of which varies. Knowledge of the contexts as well as the relevant details is necessary for creating new Services and also for maintenance and operational purposes, in particular, when faults arise. This places major requirements on navigation from the overview to the detailed level.

The OSS/J INV API as an essential deliverable of this Prosspero solution pack has been used successfully in an integration scenario at Vodafone D2 in Germany. Therefore, the following use cases are based on real operational experiences from Vodafone.

Use Cases

High level description of the use cases (subset of the OSS/J Service Inventory API, which have been used in the local integration scenario at Vodafone D2):

Use Case Overview

High Level Scenario Examples

1. In a distributed OSS/J Client Server environment, OSS/J client applications usually would like to be informed if service inventory data changes. Such changes are posted by the API, so that interested clients can subscribe to this information.

2. The service monitoring system needs information about the service hierarchy to be able to perform a real time impact analysis. The system receives resource status/alarm information and uses the hierarchy bottom-up analysis to identify the impact of the resource – outage on the services, as they are seen by the customer. Therefore the service monitoring gets the hierarchy from the service inventory as soon as the hierarchy is created or updated.

3. External systems ask (query) service inventory data from the Service Inventory system. (E.g. a change management systems asks for a list of services which might be impacted by maintenance work on a resource (e.g. network element).)

4. External systems ask service inventory for a list of services (service catalogue). (E.g. an SLA management system can use this as a selection list to assign services to SLA´s.)

The OSS/J Inventory API is structured into three logic inventories:

• product inventory (product offerings from marketing perspective)
• service inventory (service offerings from operating perspective )
• resource inventory (network equipment)

Beside the Use Cases listed in section 1.4.2 of this Solution Package, which have been used in a real implementation scenario, the OSS/J INV API delivers the following Use Cases (see OSS/J Inventory API specification http://www.tmforum.org/browse.aspx?catID=4132 ):

• Create, remove, update and query inventory entities, entity specifications and associations
• Invoke named queries and update procedures
• Perform metadata queries
• Receive notifications of inventory events
• Import and export inventory data
• Validate inventory data

The JSR 142 interface was extended to provide:

• Definable Hierarchy Filters
• Capability for Named Queries.