Bridging the Gap between MTOSI and OSS/J

Bridging the Gapbetween MTOSI and OSS/J Nigel Davis (nigeld@nortel.com) John Reilly (jreilly@metasolv.com) Suresh Bhandarkar (sureshb@mahindrabt.com) Thanks to all those who have prepared papers on this topic and have been engaged in the debate over the past couple of years. Material has been used from documents produced by members of the MTNM/MTOSI teams and other teams within TMFand OSS/J Primary exploratory work that has provided the detail for this presentation has been carried out by MBT in conjunction with MetaSolv and Nortel. This position has not yet been ratified by the MTOSI community This position has not yet been ratified by the OSS/J community

Focus of the presentation Where we were: • Confusion: OSS/J and MTOSI, surely they do the same thing?? Where we are now: • Conclusion: NO, OSS/J and MTOSI are actually complementary Work underway: • Collaborative study between MBT, MetaSolv and Nortel • Examined the model – white paper being published • Examined the operations – covered here and to be formed into a subsequent paper

OSS/J Value Positioning • OSS/J – from the Java community • Provides a formalised native Java interface • Provides design principles/guideline for development of interfaces • Intentionally does not specify or constrain the model • Can work with derivatives from SID such as MTNM or any other industry proprietary model • Provides specification for fundamental primitive operations (create, delete etc) • Provides generic interaction patterns (e.g create order by value and start order by key) • Provides code via reference implementations using an open source approach and focussing on portable code • Enables integration with the OSS systems to be achieved with minimal customisation of the reference implementations • Rapidly enables innovative interface interaction in new environments • RMI over IIOP ― traditional RPC style for performant systems (Synchronous Interaction) • XML over JMS ― messaging style for loosely-coupled systems (Asynchronous Interaction) • Web Services ― messaging style for loosely-coupled systems (Asynchronous Interaction) • Enables partner vendors to rapidly develop and agree an interface for any specific purpose • Focuses on portability and interoperability in a partner/open-source environment • Contact • Dave Raymer (David.Raymer@motorola.com) for further information on OSS/J OSS/J: Primarily Java interfaces facilitating OSS integration leveraging J2EE platform and reference implementations

MTOSI Value Positioning • MTOSI - from TeleManagement Forum • Provides standard interface definition with clear separation of model from interaction from comms binding from transport/middleware • Specifies the model of information (TMF 608), defined interaction patterns and encoding in XML via XSDs • Specifies principles for migration • Allows extension to enable differentiation • Interface capabilities growing rapidly via standardisation • Specifies SOAP binding and a limited number of transport/middleware technologies for data transfer • Currently JMS bus (HTTPS in progress) • Embodies the Service Oriented Architecture • Does not constrain implementation of back-end technology (agnostic) • Removes unnecessary variety to provide efficient integration whilst enabling differentiation around a core model • Separates management business logic and underlying transport • Remove unnecessary variety in interfacing – Single model and interface definition for all network technologies • Ensure interoperability – A complete definition • Focus is interoperability in a commercial environment • Contact: • Stephen Fratini (sfratini@telcordia.com) for further information on MTOSI MTOSI: Complete XML interface specification (operations, model, comms) facilitating out of the box OSS integration.

The ModelsTMF608 (MTNM/MTOSI), SID and CBE • SID • An umbrella information model defining business and system aspects of NGOSS solutions. • Represents knowledge in a standard format using concepts and terminology for multiple stakeholders and models the entire lifecycle of objects • SID and MTNM/MTOSI models in harmony • The TMF 608 model is oriented towards efficient transfer of specific information across an interface using a set of fully defined interactions • One generalised model covers operation of multiple technologies (WDM, SDH, SONET, PDH, Async, ATM, DSL, Ethernet etc) • A presentation earlier in the week covered this area (contact Nigel Davis (nigeld@nortel.com) or John Strassner (john.strassner@motorola.com) • SID and CBEs are converged models • CBEs are the high level models that underpin OSS/J APIs • Further technology specific mappings between SID and CBEs are being constructed • Network Resources and Service entities for various network technologies are mapped to OSS/J by extending the CBE model

Complementary Positioning

Exploration work • Considering the Model • First white paper identifies how OSS/J can readily utilise the MTNM/MTOSI information model (TMF608) • This white paper will be published under TMF TR134 • Considering the Interactions • The current work is exploring the approach to bridge between the generic operations of OSS/J and the defined service oriented operations of MTOSI • The complexity comes in macro operations such as createAndActivateSNC and this was used as an example in the study • An SDH/SONET VC4/STS3c example is being used • The pictorial form of the model in the following slides represents is explained in the layers.pdf supporting document provided with the MTNM and MTOSI product suites. • During this study OSS/J XML integration with MTOSI was explored briefly • It was recognised that there may be value in exploring this further focusing on wrapping MTOSI XSDs in OSS/J XSDs or mapping between the XSDs • The initial study focused primarily on exercising the essence of the operations and as a consequence native OSS/J Java to MOTSI XML mapping provided a suitable simplification

Example MTOSI Applications • MTOSI is an OS-OS interface • OS covers all operations systems including EMS • The example chosen to illustrate the MTOSI-OSS/J interaction is one taken from the MTNM set • CreateAndActivateSNC • This is a very concrete example that shows the change in granularity of concerns in a real practical environment

E4 PTT (Physical port) CTP (logical payload) SNC (Connection) Quad 140M Trib Card VC4 STM4 Line Card STM4 Line Card STM4 STM4 VC4 VC4 Card view of NE containing 140M ports and STM4 cards (taken from supporting document layers.pdf)

What is the required operation? • The aim is to create and activate a connection between the VC4 CTP on the STM-4 port and the VC4 CTP on the 140M port • During this process the path trace values will be configured • The createAndActivateSNC operation provided by the MTNM/MTOSI interface will carry in one single message the request for: • Creation of the SNC between the two CTPS • The configuration of the path trace • This is a basic use of the operation that provides support for far greater complexity of macro operation • The simplification was chose as it illustrated the difference and allowed exploration without clutter

Before Managed Element 140M Trib Card E4 ES Phys VC4 STM4 Card VC4 MS RS OS Phys 140M Signal Path trace = <blank> STM4 Signal

After Managed Element 140M Trib Card E4 ES Phys VC4 STM4 Card VC4 MS RS OS Phys 140M Signal Path trace = “Hull” STM4 Signal

OSS/J Application SNC Application CTP PTP JVT Events JMS Topic Queue Java Value Type RMI/IIOP JVT Events Stateless JVT Session Bean (Java Value Type interface) Service Activation MTOSI Adapter MTOSI EMS NE

Abstracted Diagram createOrderByValue(orderValue) orderKey OSS/J SA API ( Java I/F) Service Provisioning App OSS/J Actor JVT Activation Session OSS/J SA API Implementation MTOSI Adapter MTOSI Interface EMS NE Create SNC Info Set TP Info Populate Service Objects for CreateSNC,Set TP and Activate SNC and set them in the OrderValue Object with the setServices() method Activate SNC Info startOrderByKey(orderKey) retrieveTheOrder Retrieve Service Values for CreateSNC,Set TP Attributes and Activate SNC And Generate The createAndActivateSNC Structure convertToMTO SIRequest ProvisionRequest ( createAndActivateSNCService ) NE native Operations createAndActivateSNC OrderStateChangeEvent Contains OrderKey With STATE=RUNNING MTOSI Response Set the response attributes for each Service ie Create SNC , Set TP Attributes and ActivateSNC and Set the Failed Service Array for the Services Failed & change the order Status to COMPLETE OrderStateChangeEvent Contains OrderKey With STATE=COMPLETED Update

Harmonizing OSS/J - MTOSI Description of components in the Interaction Diagram : • OSS/J Actor It represents here a client which might be a standalone JMS based client or a WorkFlow Management System or some other OSS entity. • JVT Activation Session  OSS/J defines a mandatory Java Interface which is know as a JVT (Java Value Type) Interface. In case of Service Activation the Java Interface is a Stateless Session • Bean JVTActivationSession • OSS/J SA Implementation  This is the implementation of the API. All the OSS/J API have Reference Implementations provided for the various interfaces along with the source code. It is a general practice followed. By integrators to tweak this reference Implementation to suit their individual requirements. • MTOSI Adapter  This would be the component which would act as a glue between the MTOSI interface. And OSS/J. It is a usual practice to separate the Plug-in part to be separated. Typically this component would act as a interpreter between OSS/J and MTOSI and since we would be having the same information model ideally it would mean removing the OSS/J shell over the MTOSI core and passing the information towards the MTOSI interface. • MTOSI Interface  The component which would coordinate the message passing to the EMS and deal with the responses/notifications as appropriate for the communications infrastructure/middleware used. • NOTE : The calls going to and emanating from the MTOSI adapter are for illustration purpose and are not actual OSS/J calls.

Abstracted Diagram createOrderByValue(orderValue) orderKey OSS/J SA API ( Java I/F) Service Provisioning App OSS/J Actor JVT Activation Session OSS/J SA API Implementation MTOSI Adapter MTOSI Interface EMS NE Create SNC Info Set TP Info Populate Service Objects for CreateSNC,Set TP and Activate SNC and set them in the OrderValue Object with the setServices() method Activate SNC Info startOrderByKey(orderKey) retrieveTheOrder Retrieve Service Values for CreateSNC,Set TP Attributes and Activate SNC And Generate The createAndActivateSNC Structure convertToMTO SIRequest ProvisionRequest ( createAndActivateSNCService ) NE native Operations createAndActivateSNC OrderStateChangeEvent Contains OrderKey With STATE=RUNNING MTOSI Response Set the response attributes for each Service ie Create SNC , Set TP Attributes and ActivateSNC and Set the Failed Service Array for the Services Failed & change the order Status to COMPLETE OrderStateChangeEvent Contains OrderKey With STATE=COMPLETED Update

Positioning Open Market Multi-Vendor OSS Close Partners working on single product with collaborative model development Partners working on single product Product Component A Product Component B Product Component C Product Component D Many potential technologies. OSS/J is a good choice here MTOSI provides efficient systems integration through mimisation of unnecessary variety whilst enabling differentiation MTOSI provides out of the box integration and reduces partner work to achieve interoperability within a standardised operations framework OSS/J is a good choice here MTOSI could be used to formalise relationship

Interworking considerations Interworking issues tackled: • Alignment of basic programming patterns • Alignment of messaging styles • Use of topics/queues and notifications • Interworking choices (mediation or specification alignment) For further study: • Transactional support • Concurrency support • Potential automation of mappings • Security • Use of JMS • Study of OSS/J XSD/XML in conjunction with MTOSI • During the initial study OSS/J XML integration with MTOSI was explored briefly. It was recognised that there may be value in exploring this further focussing on wrapping MTOSI XSDs in OSS/J XSDs or mapping between the XSD

Conclusion – Summary • MTOSI and OSS/J are complementary technologies • MTOSI focuses on reducing the cost of integration in a commercial environment by providing a full XML interface specification detailing the model, operations and communications to enable out of the box interoperability. MTOSI is agnostic to the back end implementation • OSS/J focuses on reduced cost of integration in a partner/open-source environment providing a Java interface specification that offers basic operations but does not constrain the model or interaction. OSS/J instead allows for sharing of reference implementations to enable interoperability. • MTOSI and OSS/J can interoperate • Using a mapping/mediation approach • OSS/J and MTOSI offer value in different applications: • OSS/J is best suited to a close partner engagements • MTOSI is best suited to a out-of-the-box commercial environment • Further work • MBT/MetaSolv/Nortel: Exploration of automation of the mapping • MTOSI and OSS/J teams: Continue close interaction including shared work on the Order Management model and interface

Thanks ! Questions? Comments?

Bridging the Gap between MTOSI and OSS/J