1. Bridging the Gap between MTOSI and OSS/J
Nigel Davis
John Reilly
Suresh Bhandarkar
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

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

3. 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 for further information on OSS/J
OSS/J: Primarily Java interfaces facilitating OSS integration leveraging J2EE platform and reference implementations

4. 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 for further information on MTOSI
MTOSI: Complete XML interface specification (operations, model, comms) facilitating out of the box OSS integration.

5. The Models TMF608 (MTNM/MTOSI), SID and CBE
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 or John Strassner
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

6. Complementary Positioning
MTOSI
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 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)

7. Exploration work Considering the Model Considering the Interactions
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

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

9. 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)

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

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

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

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

14. Abstracted Diagram OSS/J SA API ( Java I/F) Service Provisioning App
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
createOrderByValue(orderValue)
orderKey
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

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

16. Abstracted Diagram OSS/J SA API ( Java I/F) Service Provisioning App
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
createOrderByValue(orderValue)
orderKey
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

17. Abstracted Diagram OSS/J SA API ( Java I/F) Service Provisioning App
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
createOrderByValue(orderValue)
orderKey
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

18. Abstracted Diagram OSS/J SA API ( Java I/F) Service Provisioning App
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
createOrderByValue(orderValue)
orderKey
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

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

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

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

22. Thanks !
Questions? Comments?