Transcript Bridging the gap between MTOSI and OSS/J

Bridging the Gap
between
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
1
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
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
2
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
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
•
Dave Raymer ([email protected]) for further information on OSS/J
Contact
OSS/J: Primarily Java interfaces facilitating OSS integration
leveraging J2EE platform and reference implementations
3
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005

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 SOAP binding and a limited number of transport/middleware technologies for
data transfer



Specifies principles for migration
Allows extension to enable differentiation
Interface capabilities growing rapidly via standardisation
Currently JMS bus (HTTPS in progress)
•
•
Embodies the Service Oriented Architecture
Does not constrain implementation of back-end technology (agnostic)
•
•
•
•
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
•
Stephen Fratini ([email protected]) for further information on MTOSI
Removes unnecessary variety to provide efficient integration whilst
enabling differentiation around a core model
Contact:
MTOSI: Complete XML interface specification (operations,
model, comms) facilitating out of the box OSS integration.
4
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
The Models
TMF608 (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
•
•
•
5
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
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
Complementary Positioning
Model
MTOSI
OSS/J
OSS-OSS interface for Multi Technology
Networks for various OSS functions.
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)
Full model defined in TMF 608.
6
Primary API
XML with web services
Defines 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 independent
Well suited to a heterogeneous
platform environment
XML is primary specification
Promotes a Service-Oriented interface
Back end implementation is Java
Well suited to an open source
environment
XML specification is not the primary source of
integration ( but rather it’s derived from the
Java interfaces)
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
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


7
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
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
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
8
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
E4
PTT (Physical port)
CTP (logical payload)
VC4
SNC (Connection)
Quad 140M Trib Card
STM4
STM4
VC4
STM4 Line Card
VC4
STM4 Line Card
Card view of NE containing 140M ports
and STM4 cards (taken from supporting
document layers.pdf)
9
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
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
10
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
Before
E4
ES
VC4
VC4
Phys
140M
Signal
MS
RS
140M Trib Card
OS
Path trace = <blank>
Phys
STM4
Signal
STM4 Card
Managed Element
11
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
After
E4
ES
VC4
VC4
Phys
140M
Signal
MS
RS
140M Trib Card
OS
Path trace = “Hull”
Phys
STM4
Signal
STM4 Card
Managed Element
12
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
OSS/J Application
SNC
Application
CTP
PTP
JVT Events
Java Value Type
RMI/IIOP
JMS
Topic
Queue
JVT Events
Stateless JVT Session Bean
(Java Value Type interface)
Service Activation
MTOSI Adapter
MTOSI
EMS
NE
13
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
OSS/J SA API ( Java
I/F)
Abstracted
Diagram
Service
Provisioning
App
JVT
Activation
Session
OSS/J
Actor
OSS/J SA
API
Implementation
MTOSI
Adapter
MTOSI
Interface
EMS
NE
Create SNC Info
Set TP Info
Activate SNC Info
Populate Service Objects for
CreateSNC,Set TP and Activate SNC and
set them in the OrderValue Object with
the setServices() method
createOrderByValue(orderValue)
orderKey
startOrderByKey(orderKey)
retrieveTheOrder
Retrieve Service Values for CreateSNC,Set TP
Attributes and Activate SNC And Generate The
createAndActivateSNC Structure
ProvisionRequest ( createAndActivateSNCService )
convertToMTO
SIRequest
NE native
Operations
createAndActivateSNC
OrderStateChangeEvent
Contains OrderKey
With STATE=RUNNING
MTOSI Response
OrderStateChangeEvent
Contains OrderKey
With STATE=COMPLETED
Update
14
Bridging the gap between MTOSI and OSS/J
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
TMW, Dallas
November 2005
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




15
•
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
TMW, Dallas
November 2005
OSS/J SA API ( Java
I/F)
Abstracted
Diagram
Service
Provisioning
App
JVT
Activation
Session
OSS/J
Actor
OSS/J SA
API
Implementation
MTOSI
Adapter
MTOSI
Interface
EMS
NE
Create SNC Info
Set TP Info
Activate SNC Info
Populate Service Objects for
CreateSNC,Set TP and Activate SNC and
set them in the OrderValue Object with
the setServices() method
createOrderByValue(orderValue)
orderKey
startOrderByKey(orderKey)
retrieveTheOrder
Retrieve Service Values for CreateSNC,Set TP
Attributes and Activate SNC And Generate The
createAndActivateSNC Structure
ProvisionRequest ( createAndActivateSNCService )
convertToMTO
SIRequest
NE native
Operations
createAndActivateSNC
OrderStateChangeEvent
Contains OrderKey
With STATE=RUNNING
MTOSI Response
OrderStateChangeEvent
Contains OrderKey
With STATE=COMPLETED
Update
16
Bridging the gap between MTOSI and OSS/J
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
TMW, Dallas
November 2005
OSS/J SA API ( Java
I/F)
Abstracted
Diagram
Service
Provisioning
App
JVT
Activation
Session
OSS/J
Actor
OSS/J SA
API
Implementation
MTOSI
Adapter
MTOSI
Interface
EMS
NE
Create SNC Info
Set TP Info
Activate SNC Info
Populate Service Objects for
CreateSNC,Set TP and Activate SNC and
set them in the OrderValue Object with
the setServices() method
createOrderByValue(orderValue)
orderKey
startOrderByKey(orderKey)
retrieveTheOrder
Retrieve Service Values for CreateSNC,Set TP
Attributes and Activate SNC And Generate The
createAndActivateSNC Structure
ProvisionRequest ( createAndActivateSNCService )
convertToMTO
SIRequest
NE native
Operations
createAndActivateSNC
OrderStateChangeEvent
Contains OrderKey
With STATE=RUNNING
MTOSI Response
OrderStateChangeEvent
Contains OrderKey
With STATE=COMPLETED
Update
17
Bridging the gap between MTOSI and OSS/J
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
TMW, Dallas
November 2005
OSS/J SA API ( Java
I/F)
Abstracted
Diagram
Service
Provisioning
App
JVT
Activation
Session
OSS/J
Actor
OSS/J SA
API
Implementation
MTOSI
Adapter
MTOSI
Interface
EMS
NE
Create SNC Info
Set TP Info
Activate SNC Info
Populate Service Objects for
CreateSNC,Set TP and Activate SNC and
set them in the OrderValue Object with
the setServices() method
createOrderByValue(orderValue)
orderKey
startOrderByKey(orderKey)
retrieveTheOrder
Retrieve Service Values for CreateSNC,Set TP
Attributes and Activate SNC And Generate The
createAndActivateSNC Structure
ProvisionRequest ( createAndActivateSNCService )
convertToMTO
SIRequest
NE native
Operations
createAndActivateSNC
OrderStateChangeEvent
Contains OrderKey
With STATE=RUNNING
MTOSI Response
OrderStateChangeEvent
Contains OrderKey
With STATE=COMPLETED
Update
18
Bridging the gap between MTOSI and OSS/J
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
TMW, Dallas
November 2005
Positioning
Open Market Multi-Vendor OSS
Close Partners working on single product
with collaborative model development
Product Component A
Partners working on single product
Product Component B
Product Component C
Many potential technologies.
OSS/J is a good choice here
MTOSI provides
efficient systems
integration through
mimisation of
unnecessary variety
whilst enabling
differentiation
Product Component D
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
19
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
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
20
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
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/opensource 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
21
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005
Thanks !
Questions? Comments?
22
Bridging the gap between MTOSI and OSS/J
TMW, Dallas
November 2005