Bridging the gap between mtosi and oss j
This presentation is the property of its rightful owner.
Sponsored Links
1 / 22

Bridging the Gap between MTOSI and OSS/J PowerPoint PPT Presentation


  • 50 Views
  • Uploaded on
  • Presentation posted in: General

Bridging the Gap between MTOSI and OSS/J. Nigel Davis ([email protected]) John Reilly ([email protected]) Suresh Bhandarkar ([email protected])

Download Presentation

Bridging the Gap between MTOSI and OSS/J

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Bridging the gap between mtosi and oss j

Bridging the Gapbetween MTOSI and OSS/J

Nigel Davis ([email protected])

John Reilly ([email protected])

Suresh Bhandarkar ([email protected])

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

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 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 ([email protected]) for further information on OSS/J

OSS/J: Primarily Java interfaces facilitating OSS integration leveraging J2EE platform and reference implementations


Mtosi value positioning

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 ([email protected]) for further information on MTOSI

MTOSI: Complete XML interface specification (operations, model, comms) facilitating out of the box OSS integration.


The models tmf608 mtnm mtosi sid and cbe

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 ([email protected]) or John Strassner ([email protected])

  • 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

Complementary Positioning


Exploration work

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

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


Bridging the gap between mtosi and oss j

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

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


Bridging the gap between mtosi and oss j

Before

Managed Element

140M Trib Card

E4

ES

Phys

VC4

STM4 Card

VC4

MS

RS

OS

Phys

140M

Signal

Path trace = <blank>

STM4

Signal


Bridging the gap between mtosi and oss j

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

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


Bridging the gap between mtosi and oss j

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

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.


Bridging the gap between mtosi and oss j

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


Bridging the gap between mtosi and oss j

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


Bridging the gap between mtosi and oss j

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

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 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

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

Thanks !

Questions? Comments?


  • Login