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=2898.

The OSS/J TT 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) TT 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 fields in the TTValueType 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
  • 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 TT 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 TT extensions if required
• In many cases existing TT 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 (file attachments, requirements for assigning etc.)
• Please refer to http://java.sun.com/developer/technicalArticles/J2EE/OSS-J/ for further information about extensibility.
• Describe the interface (specification document)
  • Usually existing TT systems have different status models, priorities and fields than those defined in OSS/J. 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 TT fields 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. (Example: TT system knows 6 priority values. Which values map to which values possible in OSS/J-TT)
  • Behavior
    Very often the existing TT 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 TT API
    The development of the TT 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 server
    • 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 configurable
    • Implement validity checks and field access rights to match the specification. This is very important, if the legacy application has internal constraints regarding field write access that do not match the very open OSS/J TT definitions (e.g. if some fields may only be modified by a client when he has a specific role and the ticket has a specific status etc.). Exceptions need to be handled.
  • Modifications in the legacy TT application
    The TT application needs to communicate to the clients by publishing the appropriate events when a ticket 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 TT 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. This can be very easy if the amount of OSS/J functions used is very small and can be very complex for situations where another TT system might also be a client (for communications between TT systems). The approach for enabling other application to use a TT system via OSS/J strongly depends on the system to be connected.
• 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 TT system.