Below is a step-by-step explanation of how a Service Provider, in this case BT Group plc, has implemented this Solution Pack in their OSS/BSS environment. A detailed example of the BT implementation, along with implementation specific requirements and conditions, can be found in Section 1.8 of the Solution Package.
TITLE: List of Steps/Prerequisites
1. Understand mTOP in general
- 1.1. It is vital to know the TMF608 concepts up to a certain level to basically understand the extensibility of the layers (layers.pdf) solution.
2. Determine the transport used, e.g. JMS, MQ, HTTPS, this will often depend upon the implanting systems and location within OSS.
3. While it is true there is no standard JMS/MQ SOAP binding, it is likely that the Service Provider’s middleware vendors will have their own solutions that will work within the confines of a Service Providers OSS.
4. Define MTOSI vendor extensions if required
- 4.1. In many cases it is necessary for systems to support functionality which is required to support business products and services, e.g. VOIP, but which is not currently modeled into the MTOSI model. For such purposes it sometimes is necessary (and required) to extend the existing API. This is achievable using the rules and guidelines of layers.pdf and other supporting documents.
- 4.2. Please refer to MTOSI SD2-13
http://www.tmforum.org/cws/view_folder.aspx?SelectedIndex=1&ID=1852&team_ID=81&Node=1849&sNode=1852&Exp=Y
for further information about extensibility.
5. Describe the interface (specification document)
- 5.1. MTOSI has a concrete data model associated with its design (TMF608). In order to achieve greatest benefit from MTOSI development it is recommended that the OSS component data models are aligned with TMF608. This does not preclude the use of the SID information model since often a service provider will have developed a protocol and technology specific implementation of the SID in their own Enterprise data model. This can be harmonized internally in the OSS with TMF608 (within the technology resource domain).
- 5.2. It is not necessary to implement the same UML model at database and XML level so long as it is possible to map between the two data representations, e.g. via façade pattern.
6. Design the connection components
- 6.1. Data Model
The data model is based upon TMF608 v3.1 onwards. This may by necessity be extended to cater for resources not yet supported by mTOP, example being Voice Access Gateways on an IP DSLAM or MSAN (Multi-Service Access Node) - 6.2. Software structure
MTOSI developments have been deployed on a number of middleware platforms by vendors such as IBM, BEA and Iona. Additionally R&D only implementations have been built on opensource platforms such as Glassfish using JEE5.
7. Implementation
Implementation usually contains the following components.
- 7.1. MTOSI wsdl and xsd’s. It is quite possible to deploy MTOSI API’s independently of the programmatic language eg, Java or C++ since many industry toolkits support the necessary tools to generate code artifacts of either language from wsdl.
When deploying on a green-field system it is usually best to involve all integration partners in discussion over the API development, eg NMS to multi EMS vendors. - 7.1.1. All the necessary data binding objects and service end points are derivable from the wsdl file by using the wsdl2java/c++ tool included with the application server provider. These will need to be tied back to the business tier objects via use of designed facades which match the application implementation.
- 7.1.2. Both server and client side implementations are directly derivable from the wsdl.
8. Production environment
- 8.1. Set up and configure the J2EE server and assure it can be reached from the clients.
- 8.2. Assure that appropriate queues are created if JMS/MQ is to be supported
- Install and configure the possibly required modifications in the OS system.