OSS/J

OSS/J defines a common interface structure and SID based data model for the messages that are delivered between different OSS components (FM, PM, TT etc.). It aims to deliver interoperability between those components with minimum effort.

OSS/J initiative (previously by JCP, now TMF) is composed of specifications. Specifications are issued for OSS domains such as trouble ticket (TT), fault management (FM) etc. and they depict the attributes, naming conventions (templates) and mandatory/optional operations for that domain.

These specifications are fully implemented by the OSS vendors who claim that they are OSS/J compatible. The clients (other OSS components in the infrastructure) connect to the server by using these specifications.

OSS/J also provides 3 integration profiles: EJB (Java), JMS (XML) and web services. Profiles are the possible ways that you may connect to the OSS/J servers. A server may implement one of these, or all of these. Some vendors even add other non-standard profiles that enable the legacy clients to connect. The important part here is the nature of the message flow. For example, fault management is asynchronous in nature. So, for me, the best protocol to use would be JMS. For trouble ticket operations, which are synchronous in nature, we may use EJB or web service profiles.

How should we migrate our interfaces to OSS/J? Well, it is better to explain the process with an example.

Suppose, we have a fault management platform and a trouble ticket platform. We have an expert rule deployed in the fault manager that creates a trouble ticket when it receives a specific string in the alarm’s AdditionalText attribute. FM reaches TT via its “legacy” CORBA interface.

Our TT vendor says that their latest product version supports OSS/J TT Specification. (which means they wrote a server which expose OSS/J interface)

Since we want to migrate to that interface, we ask the vendor which version of the specification they have implemented on the server. They replied with the specification number: v1.2. We also learned that we can use EJB (Java) profile to reach their server.

A quick note: most probably, the vendor did not write the whole NBI stack, but they wrote an intermediary OSS/J server which, at the backend, communicates with the old NBI stack over CORBA. (There will be data mapping and conversions between the specifications) This way, they will able to support both CORBA clients and OSS/J clients and reduce time to market.

On the FM side, we need to write an OSS/J TT client that follows the v1.2 specification. (Generally we ask the FM vendor to write it for us). Within the client’s configuration, we will have to specify the connection details to the remote server. After the client is successfully connected to the server, it can issue calls to operations that are implemented on the server.

The important part in here is; if the vendor is saying, “I am OSS/J TT spec v1.2 compliant”; it should define all the mandatory operations that appear in the specification. For the clients, however, this is not mandatory. For example, if I only need to create a trouble ticket within my Fault Management application, and I do not care about closing it, I can implement only the create TT operation from the spec.

OSS/J brings portability. The client would work, in theory, with any TT OSS/J server (vendor) that conforms the same specification. I say, in theory, because most of the time you are required to do minor modifications on your client.

For those, who are interested in OSS/J, you may have a look at the TMF OSS/J site at:
http://tmforum.org/BestPracticesStandards/OSSJAPIs/2923/Home.html