Prosspero Portal - Step-by-step Implementation

Qualified implementation guidance is available from a growing number of companies providing valuable information as OSS/J affiliated services. Please refer to: http://www.tmforum.org/browse.aspx?catid=2911

The OSS/J INV API delivers a major part and the base for this integration scenario. But there are several prerequisites needed to implement and to use it in a real Service Provider environment. The following list gives an overview about the steps required to adopt OSS/J technology into a real world application. The example is an existing (legacy) Service Inventory server which is OSS/J enabled in an SP environment to become the base for migrating from point to point interface connections to OSS/J based communications. In general the steps can be divided into an organizational/analysis part and into a technology part; if the existing Business Entities are sufficient and the application matches the OSS/J definitions, some steps may be left out.

List of Steps/Prerequisites:

- Understand OSS/J in general
o It is vital to know the OSS/J concepts up to a certain level to basically understand the possibilities of the solution.

- Analyze the existing service inventory system and its technical design

OSS/J is heavily based on the component based architecture whereas existing legacy applications often have totally different approaches. This is a major point when defining the extent of a possible solution.

- Define OSS/J Inventory extensions if required

In many cases existing service inventory systems have functionality which is required to support existing processes but which is not currently modeled into the OSS/J API. For such purposes it sometimes is necessary (and required) to extend the existing API
Please refer to http://java.sun.com/developer/technicalArticles/J2EE/OSS-J/ for further information about extensibility.

- Describe the interface (specification document)

Usually existing OSS systems have different information models than those defined in OSS/J and SID. In a central specification document the possible extensions and meaning of each field and value need to be defined based on terminology used in the SP’s environment. This document also defines things like access rights, authentication and other environment specific issues.
Later this document needs to be published to any party developing clients and servers as a base for any application when adapting to the specific OSS/J implementation.

- Design the connection components

Data Model
Map the existing information model onto the meanings defined in the specification document. If values do not match, define the transformation to assure that the internal attribute and the OSS/J field have the same meaning.
Behavior
Very often the existing service inventory system does not behave like a J2EE component and sometimes there are even no equivalents to “Events” etc. and sometimes the workflow or status diagram does not fit the OSS/J specifications.
Define the mapping of behavior, i.e. what happens inside the application when a specific OSS/J activity takes place
Software structure
Define a software structure that allows implementing the OSS/J API under consideration of technical possibilities/APIs available from the legacy application. Also define, which possibilities for access need to be supported (JVT, XML, Web Services)

- Implementation

Implementation usually contains the following components:

OSS/J Inventory API:

                - The development of the Inventory API implementation can be started based on the OSS/J Reference Implementation (RI) which represents the OSS/J server side.
                - Port the RI onto the target J2EE compliant application serve
                - If required, implement the ValueType objects for extensions
                - Implement the back side which functionally connects to the legacy application. Assure that at least all mandatory operations are implemented.
                  This mechanism normally uses the API provided by the legacy application.
                - Implement any mapping mechanisms required; this may be a challenge if it needs to be highly configurableImplement validity checks and field access rights to match the specification.

Modifications in the legacy service inventory application:The Service inventory application needs to communicate to the clients by publishing the appropriate events when an entity is created or modified. If the application does not support this, a component needs to be developed to mimic this behavior.
Clients:Implement the required clients that use the service inventory server via OSS/J. This is possible by either using a similar approach and implementation or by using existing products that provide OSS/J client support.

- Production environment

Set up and configure the J2EE server and assure it can be reached from the clients.
Assure that appropriate queues are created if JMS is to be supported
Install and configure the possibly required modifications in the legacy service inventory system.