bridging the gap between mtosi and oss/j

22
1 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005 Bridging the Gap Bridging the Gap between between MTOSI and OSS/J 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

Upload: adah

Post on 06-Feb-2016

32 views

Category:

Documents


0 download

DESCRIPTION

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

TRANSCRIPT

Page 1: Bridging the Gap between  MTOSI and OSS/J

1 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

Bridging the GapBridging the Gapbetween between

MTOSI and OSS/JMTOSI 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 communityThis position has not yet been ratified by the OSS/J community

Page 2: Bridging the Gap between  MTOSI and OSS/J

2 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

Focus of the presentationFocus 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

complementaryWork 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

Page 3: Bridging the Gap between  MTOSI and OSS/J

3 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

OSS/J Value PositioningOSS/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/JOSS/J: Primarily Java interfaces facilitating OSS

integration leveraging J2EE platform and reference implementations

Page 4: Bridging the Gap between  MTOSI and OSS/J

4 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

MTOSI Value PositioningMTOSI 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.

Page 5: Bridging the Gap between  MTOSI and OSS/J

5 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

The ModelsThe ModelsTMF608 (MTNM/MTOSI), SID and CBETMF608 (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

Page 6: Bridging the Gap between  MTOSI and OSS/J

6 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

Complementary PositioningComplementary PositioningMTOSI OSS/J

Model OSS-OSS interface for Multi Technology Networks for various OSS functions.

Full model defined in TMF 608.

Network Technology Independant APIs. No specific flavour/model Separate API for the various OSS functions. Note that Java interface classes for MTNM are on java.net (open source)

Primary API XML with web servicesDefines guidelines on implementation using JMS. Design does not force JMS usage. Being extended to also offer HTTPS.

Java/J2EE based. Java API, XML API & Web services API.XML API is wrapper over the Java API. The API leverages the J2EE platform

Operations Provides defined set of operations. Growing to provide interfaces for specific MTNM operations e.g. createAndActivateSNC. Builds on MTNM interfaces to provide OSS – OSS Integration capabilities

Provide generic set of operations e.g Methods like createOrderByValue() , startOrderByKey() defined in the ServiceActivation API.Note: these would be available to the client for SNC Activation.

Implementation Independence

Back end implementation technology independentWell suited to a heterogeneous platform environmentXML is primary specification Promotes a Service-Oriented interface

Back end implementation is JavaWell suited to an open source environmentXML specification is not the primary source of integration ( but rather it’s derived from the Java interfaces)

Page 7: Bridging the Gap between  MTOSI and OSS/J

7 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

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

Page 8: Bridging the Gap between  MTOSI and OSS/J

8 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

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

Page 9: Bridging the Gap between  MTOSI and OSS/J

9 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

Quad 140M Trib Card

STM4 Line CardSTM4 Line Card

VC4 VC4

VC4

STM4 STM4

E4PTT (Physical port)

CTP (logical payload)

SNC (Connection)

Card view of NE containing 140M ports and STM4 cards (taken from supporting document layers.pdf)

Page 10: Bridging the Gap between  MTOSI and OSS/J

10 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

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

Page 11: Bridging the Gap between  MTOSI and OSS/J

11 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

Managed Element

STM4 Card

140M Trib Card

140MSignal

STM4Signal

E4

ES

Phys VC4

MS

RS

OS

Phys

VC4

Path trace = <blank>

Before

Page 12: Bridging the Gap between  MTOSI and OSS/J

12 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

Managed Element

STM4 Card

140M Trib Card

140MSignal

STM4Signal

E4

ES

Phys VC4

MS

RS

OS

Phys

VC4

After

Path trace = “Hull”

Page 13: Bridging the Gap between  MTOSI and OSS/J

13 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

OSS/J ApplicationOSS/J Application

Application

JMS

Service Activation

 

Java Value TypeRMI/IIOP

JVT Events

JVT Events

QueueTopic

Stateless JVT Session Bean(Java Value Type interface)

MTOSI Adapter

EMS

SNC

CTP

PTP

NE

MTOSI

Page 14: Bridging the Gap between  MTOSI and OSS/J

14 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

OSS/J Actor

MTOSIAdapter

MTOSIInterface

JVTActivationSession

OSS/J SA API ( Java I/F)

createOrderByValue(orderValue)

orderKey

ProvisionRequest ( createAndActivateSNCService )

startOrderByKey(orderKey)

convertToMTOSIRequest

createAndActivateSNC

retrieveTheOrder

Set the responseattributes for each Service ieCreate SNC , Set TP Attributes and ActivateSNC and Set the Failed Service Array for the Services Failed & change the order Status to COMPLETE

OrderStateChangeEventContains OrderKeyWith STATE=COMPLETED

OrderStateChangeEventContains OrderKeyWith STATE=RUNNING

OSS/J SA API

Implementation

MTOSI Response

Retrieve Service Values for CreateSNC,Set TP Attributes and Activate SNC And Generate The createAndActivateSNC Structure

EMSService

ProvisioningApp

NE

Abstracted Diagram

Create SNC Info

Set TP InfoActivate SNC Info

Populate Service Objects for CreateSNC,Set TP and Activate SNC and set them in the OrderValue Object with the setServices() method

Update

NE native Operations

Page 15: Bridging the Gap between  MTOSI and OSS/J

15 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

Harmonizing OSS/J - MTOSIHarmonizing 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.

Page 16: Bridging the Gap between  MTOSI and OSS/J

16 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

OSS/J Actor

MTOSIAdapter

MTOSIInterface

JVTActivationSession

OSS/J SA API ( Java I/F)

createOrderByValue(orderValue)

orderKey

ProvisionRequest ( createAndActivateSNCService )

startOrderByKey(orderKey)

convertToMTOSIRequest

createAndActivateSNC

retrieveTheOrder

OrderStateChangeEventContains OrderKeyWith STATE=COMPLETED

OrderStateChangeEventContains OrderKeyWith STATE=RUNNING

OSS/J SA API

Implementation

MTOSI Response

Retrieve Service Values for CreateSNC,Set TP Attributes and Activate SNC And Generate The createAndActivateSNC Structure

EMSService

ProvisioningApp

NE

Abstracted Diagram

Create SNC Info

Set TP InfoActivate SNC Info

Populate Service Objects for CreateSNC,Set TP and Activate SNC and set them in the OrderValue Object with the setServices() method

Update

NE native Operations

Set the responseattributes for each Service ieCreate SNC , Set TP Attributes and ActivateSNC and Set the Failed Service Array for the Services Failed & change the order Status to COMPLETE

Page 17: Bridging the Gap between  MTOSI and OSS/J

17 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

OSS/J Actor

MTOSIAdapter

MTOSIInterface

JVTActivationSession

OSS/J SA API ( Java I/F)

createOrderByValue(orderValue)

orderKey

ProvisionRequest ( createAndActivateSNCService )

startOrderByKey(orderKey)

convertToMTOSIRequest

createAndActivateSNC

retrieveTheOrder

OrderStateChangeEventContains OrderKeyWith STATE=COMPLETED

OrderStateChangeEventContains OrderKeyWith STATE=RUNNING

OSS/J SA API

Implementation

MTOSI Response

Retrieve Service Values for CreateSNC,Set TP Attributes and Activate SNC And Generate The createAndActivateSNC Structure

EMSService

ProvisioningApp

NE

Abstracted Diagram

Create SNC Info

Set TP InfoActivate SNC Info

Populate Service Objects for CreateSNC,Set TP and Activate SNC and set them in the OrderValue Object with the setServices() method

Update

NE native Operations

Set the responseattributes for each Service ieCreate SNC , Set TP Attributes and ActivateSNC and Set the Failed Service Array for the Services Failed & change the order Status to COMPLETE

Page 18: Bridging the Gap between  MTOSI and OSS/J

18 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

OSS/J Actor

MTOSIAdapter

MTOSIInterface

JVTActivationSession

OSS/J SA API ( Java I/F)

createOrderByValue(orderValue)

orderKey

ProvisionRequest ( createAndActivateSNCService )

startOrderByKey(orderKey)

convertToMTOSIRequest

createAndActivateSNC

retrieveTheOrder

OrderStateChangeEventContains OrderKeyWith STATE=COMPLETED

OrderStateChangeEventContains OrderKeyWith STATE=RUNNING

OSS/J SA API

Implementation

MTOSI Response

Retrieve Service Values for CreateSNC,Set TP Attributes and Activate SNC And Generate The createAndActivateSNC Structure

EMSService

ProvisioningApp

NE

Abstracted Diagram

Create SNC Info

Set TP InfoActivate SNC Info

Populate Service Objects for CreateSNC,Set TP and Activate SNC and set them in the OrderValue Object with the setServices() method

Update

NE native Operations

Set the responseattributes for each Service ieCreate SNC , Set TP Attributes and ActivateSNC and Set the Failed Service Array for the Services Failed & change the order Status to COMPLETE

Page 19: Bridging the Gap between  MTOSI and OSS/J

19 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

Open Market Multi-Vendor OSS

PositioningPositioning

Close Partners working on single productwith collaborative model development

Product Component A Product Component B

Partners working on single product

Product Component C Product Component D

Many potential technologies.OSS/J is a good choice here

OSS/J is a good choice hereMTOSI could be used to formalise relationship

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

Page 20: Bridging the Gap between  MTOSI and OSS/J

20 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

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

Page 21: Bridging the Gap between  MTOSI and OSS/J

21 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

Conclusion – SummaryConclusion – 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

Page 22: Bridging the Gap between  MTOSI and OSS/J

22 Bridging the gap between MTOSI and OSS/J TMW, Dallas November 2005

Thanks !Thanks !

Questions? Comments?