MTOSI - OSSJ - Inventory APIs Comparison Note by BhFk7Br8

VIEWS: 408 PAGES: 33

									MTOSI - OSSJ - Inventory APIs Comparison Note




        MTOSI - OSSJ - Inventory APIs Comparison Note
Abstract
This document ???

Table of Contents

MTOSI - OSSJ - Inventory APIs Comparison Note ...................................................................................... 1
Abstract ......................................................................................................................................................... 1
Table of Contents .......................................................................................................................................... 1
1      Introduction ............................................................................................................................................ 3
2      Acronyms ............................................................................................................................................... 4
3      Input Documents .................................................................................................................................... 5
4      General Considerations ......................................................................................................................... 6
    4.1       OSSJ .............................................................................................................................................. 6
    4.2       MTOSI ............................................................................................................................................ 7
5      Information Model .................................................................................................................................. 8
    5.1       OSSJ .............................................................................................................................................. 8
    5.2       MTOSI .......................................................................................................................................... 11
    5.3       Comments .................................................................................................................................... 13
6      Architecture Components .................................................................................................................... 14
    6.1       OSSJ ............................................................................................................................................ 14
    6.2       MTOSI .......................................................................................................................................... 14
7      Interaction Patterns .............................................................................................................................. 16
    7.1       OSSJ ............................................................................................................................................ 16
    7.2       MTOSI .......................................................................................................................................... 17
8      How to uniquely identify an inventory instance .................................................................................... 20
    8.1       OSSJ ............................................................................................................................................ 20
    8.2       MTOSI .......................................................................................................................................... 20
9      API Style .............................................................................................................................................. 22
    9.1       Generic Aspects ........................................................................................................................... 22
       9.1.1       OSSJ ....................................................................................................................................... 22
       9.1.2       MTOSI ..................................................................................................................................... 22
    9.2       Specific Inventory Aspects ........................................................................................................... 23
       9.2.1       OSSJ ....................................................................................................................................... 23


???, Version 1.0                                                     TM Forum 2009                                                               Page 1 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

     9.2.2      MTOSI ..................................................................................................................................... 23
  9.3      Interaction, Operations, Events .................................................................................................... 23
     9.3.1      OSSJ ....................................................................................................................................... 23
        9.3.1.1         General Features ............................................................................................................ 23
        9.3.1.2         Operations related to Entities, EntitySpecifications, Associations .................................. 24
        9.3.1.3         Named Queries ............................................................................................................... 24
        9.3.1.4         File based export and import ........................................................................................... 25
        9.3.1.5         Events ............................................................................................................................. 25
     9.3.2      MTOSI ..................................................................................................................................... 25
     9.3.3      Comments ............................................................................................................................... 26
10      Positioning ........................................................................................................................................ 27
11      Synoptic Feature Comparison .......................................................................................................... 28
12      Administrative Appendix ................................................................................................................... 33
  12.1          Document History .................................................................................................................... 33
  12.2          Acknowledgments ................................................................................................................... 33
  12.3          How to comment on this document ......................................................................................... 33




???, Version 1.0                                                  TM Forum 2009                                                             Page 2 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




1 Introduction
This note is an attempt to present the key features of two OSS Inventory APIs: MTOSI 2.0 MRI and OSSJ
Inventory API 1.2 (JSR 142) and try to compare them.
Those two APIs have been developed separately by independent teams with different background and
different working styles but sharing the same ultimate objective of reducing the cost and complexity of
integrating inventory components when deploying OSS solutions.
       MTOSI originated from the MTNM with the original goal to provide a unified set of specifications
        for OS-OS interfaces for the management of all transmission/network technologies. The original
        scope was on management of Network Resources was further extended to cover the
        management of Services as well. MTOSI 2.0 exposes two separate sets of Inventory interfaces
        named MRI and MSI (respectively “Manage Resource Inventory” and “Manage Service
        Inventory”). While the MRI was intensively studied and carefully consolidated, the MSI was not
        elaborated with the same level of details. For this reason only the MTOSI 2.0 MRI is considered
        in this note.
        The MTOSI interfaces are specified in XML (WDSL and XSD) with no attempt or consideration of
        supporting APIs for a specific programming language.
       OSSJ also recognized that standardization of interfaces to network-, service-, and business-
        management systems has benefits for service-providers and network-equipment. OSS/J
        developed a set of interfaces based on consistent design patterns and realized in the three
        core JEE technologies: Java, Java Messaging Service (JMS), and Web Services.
        The scope has always been very general and those different APIs are applicable to
        Product, Service and Resource.
        The JSR 142 OSSJ Inventory API addresses inventory functions in different areas of service
        provider operations: Customer Relationship Management, Service Management and Resource
        Management.
        This being said, it is recognized that the artefacts of this API are in no case specific to the
        Telecom domain, in such a way that it could equally be used for totally different domains.


The two APIs are very comprehensive. Trying to compare them is not an easy task mainly due to the
profound differences between the two approaches used which is reflected in the different artifacts and
styles in the resulting specifications.
Mastering the two approaches in details is a real challenge. For this reason, we do not claim that this note
is exhaustive or even perfectly accurate. Hopefully it is useful and informative!




???, Version 1.0                             TM Forum 2009                                     Page 3 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




2 Acronyms
CBE                Core Business Entities
EJB                Enterprise Java Bean
HTTP               Hyper Text Transfer Protocol
J2EE               Java 2 Enterprise Edition
JMS                Java Message Service
JVT                Java Value Type
MTNM               Multi-Technology Network Management
MTOSI              Multi-Technology Operations System Interface
OSSJ               OSS through Java
SID                Shared Information/Data XML           eXtended Markup Language
XVT                XML Value Type




???, Version 1.0                               TM Forum 2009                       Page 4 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




3 Input Documents

MTOSI
    1. SD0-1_mTOPDictionary.doc
    2. SD0-4_mTOPGuidelines_IA.doc
    3. SD0-5_mTOPGuidelines_WebServices.doc
    4. SD1-25_objectNaming.doc
    5. SD2-5_Communication_Styles.doc
    6. SD2-6_VersioningAndExtensibility.doc
    7. SD2-7_ObjectNaming.doc
    8. SD2-14_AVC_SC_Notifications.doc
    9. TMF518_FMW.doc
    10. TMF518_MRI.doc
OSS-J
    11. OSSJ-DesignGuidelines2.0_Part1_Conceptsv2.0.pdf
    12. OSSJ-DesignGuidelines2.0_Part2_javaEEv2.0.pdf
    13. OSSJ-DesignGuidelines2.0_Part3_XML_JMSv2.0.pdf
    14. OSSJ-DesignGuidelines2.0_Part4_WSv2.0.pdf
    15. COM-API-SPEC_PART1_OVERVIEW.1.5.pdf
    16. INV-API-SPEC_PART1_OVERVIEW.1.2.pdf
    17. INV-API-SPEC_PART2_USERS_GUIDE.1.2.pdf




???, Version 1.0                         TM Forum 2009   Page 5 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




4 General Considerations

4.1      OSSJ
The OSSJ Inventory API addresses inventory functions in different areas of service provider operations:
Customer Relationship Management, Service Management and Resource Management.
The API is specified for 3 integration profiles:
       Java, EJB based
        The Java Value Type access interface (JVT) provides a standard EJB interface. The Client calls
        the implementation by using RMI. In that case objects are
        transferred as serialized Java objects.
        In addition, events are sent from the implementation to the Client by using JMS Messages
        containing serialized Java objects. This interface provides maximum performance, strong typing
        and full support of all J2EE features, like security and transactions. It is the most natural interface
        for Java Clients, for example other EJBs, application Clients and Web Clients.
       XML, XML messages vehicle via JMS
        The XML Value Type Request/Response (XML-JMS) access interface provides an XML-based
        request/reply paradigm. In this pattern, the managed entities are represented as XML documents,
        and the requests and responses exchanged across the XML-JMS interface contain the XML
        mappings to the methods and parameters provided by the JVT Session Bean.
       Web Services
The JVT and XML-JMS interfaces are access interfaces which provides basic getter and setter and
factory methods for field attributes of the entities involved as well as supporting usage data query and
transfer requests. The JMS Messaging interface is used by the OSS Inventory API to send notifications to
both types of clients.
The following operations are supported:
       Create, remove, update and query inventory entities, entity specifications and associations;
       Invoke named queries and update procedures;
       Perform metadata queries;
       Receive notifications of inventory events;
       Import and export inventory data;
       Validate inventory data.
Discovery of inventory information, computation and propagation of inventory entity state and
configuration management are outside the scope of the Inventory API. However the Inventory API
provides the base operations for file-based import/export, which can be used by resource discovery
components.




???, Version 1.0                                   TM Forum 2009                                  Page 6 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note


4.2      MTOSI
The goal of MTOSI is to provide a unified set of specifications for both an OS-OS interface and an NML-
EML interface covering assurance and fulfillment for all transmission/network technologies while using
enabling technologies such as JMS, HTTP, and CORBA to transport the management messages
themselves.
The Manage Resource Inventory API (MRI) addresses the following management capabilities:
            General Management such as (among others):
             o     Bulk inventory retrieval (retrieving selected information in a single operation)
             o     Multi-Object Inventory Update
            Inventory Management of Connection Oriented Technologies
            Inventory Management of Connectionless Technologies
            Inventory Notifications
MTOSI considers the more general scenario of OS-OS communications with NML-EML as a special case




???, Version 1.0                                 TM Forum 2009                                       Page 7 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




5 Information Model

5.1      OSSJ
The variety of inventory information can be classified in three groups defining three Inventory functions
focused on products, services or resources. Each function has its specific set of inventory entities and
relationships, its specific business logic and interacts with different subset of OSS functions. However, all
Inventory functions share common abstractions (e.g., entities, associations, entity specifications) and
common base interaction model (e.g., queries based on traversal of relationships, atomic update
procedures etc.).
The approach used by OSSJ to model information data is to define a framework for meta modelling inside
a three layers architecture. Each of the layers provides different levels of abstraction. These layers are
defined as follows:
       The instance layer is comprised of the inventory information stored in the repository. This
        information is also referred to as “inventory data”.
       The model layer is comprised of the meta-data that describes the inventory information. This
        layer is also referred to as “meta-data” or “inventory model”.
       The meta-model layer is comprised of the descriptions that define the structure and semantics of
        inventory models (i.e., information model for metadata).




                                     Figure 1. OSSJ Meta Modelling


The Inventory API specification uses the CBE (Core Business Entities) meta-model layer and partially the
model layer.
The CBE meta-model extends the UML vocabulary with the following concepts:




???, Version 1.0                              TM Forum 2009                                      Page 8 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

       Entity with stereotype “Entity” (<<Entity >>). Entities are value type objects representing inventory
        concepts such as “Product”, “Service” and “Resource”. The entity contains a list of methods to get
        and set the value attributes.
       Entity Specification with stereotype “Specification” (<<Specification >>). Entity Specifications are
        value type objects representing specifications of CBE entities. An Entity Specification captures
        characteristics and constraints applicable to instances of the same inventory entity type.
       Association with stereotype “Association” (<<Association >>).

The figure below shows CBE Core Model, sitting at the meta model layer, which is specified in the OSSJ
Inventory API. Specific implementations of the Inventory API will extend it in order to define models
specific to an inventory function (e.g., service inventory model, product inventory model, etc.) or a network
technology (e.g., wireless inventory model, optical inventory model, etc.).




???, Version 1.0                              TM Forum 2009                                     Page 9 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




                             Figure 2. OSSJ Inventory CBE Core Model


The Inventory CBE Core Model is a generic model, which must extended by implementations of the
Inventory API. The implementations require the extension of this model to map specific information



???, Version 1.0                            TM Forum 2009                                  Page 10 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

models whether related to industry standards or not. The model must be extended by sub-classing the
core model entities, specifications or associations.
An Inventory system will usually enforce a set of complex semantic rules with regard to the inventory
information it is managing. Clients making updates to the inventory information should be familiar with
these semantic rules in order to successfully update the data managed by the inventory system . The
Inventory API provides a partial support for this requirement by providing association rules and entity
specifications. However, the Inventory API does not define a generic language that will allow expressing
the constraints of association rules and entity specifications or the definition of complex semantic rules.



5.2      MTOSI
MTOSI uses a specific set of artifacts representing Resource related information. Those artifacts are
specified in UML using classes (with typed attributes) and associations to represent relationships
between them. In addition to the resource related classes, few general purpose classes have been
added: for example, the MD (Management Domain) class is used to help organizing an Inventory
repository into several separate naming trees. The same artifacts are also specified in XML
The diagram below represents the different classes of the information model supported with the naming
relationship (attributes are not shown).
As can be seen, a special kind of association (name) is used to enforce a naming schema, in such a way
that each object instance is given a unique name for a given OS.




???, Version 1.0                              TM Forum 2009                                    Page 11 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




                                    Figure 3. MTOSI Inventory Layout


Each of this relatively small number of classes contains a rich set of attributes and associations which are
used to support many network transport technologies.
It is one of the key aspects of MTOSI to provide a rich and flexible information model able to support the
Service Providers needs for the management of specific technologies. This is achieved through the
specification of a number of technology specific data entities (i.e., the specification of technology specific
transmission parameters, performance parameters and object classes.). In addition, the specification of
sets of generic artefacts in conjunction with the specification of technology specific data entities means


???, Version 1.0                               TM Forum 2009                                     Page 12 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

that MTOSI supports a number of different technologies in a generic way. The ability to support a number
of technologies in a generic manner also means that it is possible to add support for new technologies
relatively easyly without disrupting the existing technology support.
Support for extensibility is one of the essential design characteristics that are applied in the definition of
the MTOSI XML Schema driven by on the following two considerations:
       Allow vendor to customize by extension the interface definitions, and
       Allow evolution of the interface definitions with minimal impact on compatibility.
The MTOSI XML Schema extension capabilities have three aspects:
       Complex Type Extension such as MTOSI objects classes and notifications (events)
       Simple Type Extensions such as MTOSI object class attributes and parameters
       Vendor objects and notifications (creation of new object classes and notifications)
MTOSI R2.0 provides support for the following technologies:
    1. Synchronous Optical Networking (SONET)/Synchronous Digital Hierarchy (SDH)
    2. Asynchronous Transfer Mode (ATM)
    3. Dense Wavelength Divison Multiplexing (DWDM)
    4. Microwave Radio
    5. Digital Subscriber Line (DSL)
    6. Frame Relay (FR)
    7. Ethernet Transport



5.3      Comments
The way the information model is handled in the two APIs is probably one of the most striking differences.
While both information models have some relation with the SID, they approach the problem from a totally
different perspective.
The main part of the MTOSI information model related to network resources has been inherited from the
result of the MTNM technical work elaborated by top experts in various transportation technologies. The
resulting model contains lots of artifacts which can directly be used in deployed solutions supporting
those technologies.
There is no real specific information model in OSSJ. Instead, OSSJ offers all the generic meta data which
must be used to construct any specific information model for any domain. In particular Associations (used
to represent relationships between Entities in an information model) are themselves object classes.




???, Version 1.0                               TM Forum 2009                                      Page 13 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




6 Architecture Components

6.1      OSSJ
The following diagram presents the high-level architecture of a J2EE application based on the Common
API components.




The OSS Inventory API defines the JVT session façade and the XML-based messaging façade for
inventory components.
An entity can be an EJB Entity Bean, a Java Value Type (JVT) Object or an XML document. An OSS/J
Building Block provides interfaces to manage a specific set of entities. Different interaction models using
different representations of the same managed entities are identified.



6.2      MTOSI
MTOSI does not prescribe or suggest any specific architecture in the sense that the MTOSI specifications
are independent from any middleware transport technology. Being transport independent will allow
replacing the underlying transport without changing the application code (and the application logic) of
both the OS client and OS server. This property is achieved by keeping untouched the MTOSI messages
as the specific transport is deployed.
In order to meet this requirement a service oriented façade design pattern is used. This transport agnostic
abstract interface is called CCV (Common Communication Vehicle) and support different communication
patterns that can be used in association with each operation of the Inventory interface.




???, Version 1.0                              TM Forum 2009                                   Page 14 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




???, Version 1.0                        TM Forum 2009   Page 15 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




7 Interaction Patterns

7.1      OSSJ
OSSJ defines patterns (also called Integration Profile) to capture the nature of the interactions (i.e.,
invocation interfaces) exposed by OSS/J Building Blocks
Entities may be accessed in different ways depending on how information is exposed via an interface.
The definition of different interaction patterns depends on the type of actor accessing the managed
system. There are three types of interaction patterns which are graphically represented in the following
picture:




   Java Integration Profile
    Instances of a well-defined set of entity types are accessed via a single interface i.e., a Stateless
    Session Bean. Bulk operations are defined in the application-specific Session interfaces, which pass
    identities and states of managed entities using operation parameters using Java Value Type objects.
    JVT style
    interfaces are intended for use by Java clients that desire tight integration with OSS through Java
    applications.
    The following figure depicts a typical interaction between a client and a JVT Session Bean for the
    purposes of manipulating a JVT object.




???, Version 1.0                               TM Forum 2009                                     Page 16 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

                        Figure 4. JVT Integration sequence diagram example


   XML Integration Profile
    The XML Messaging interaction pattern provides access to the managed entities through an XML-
    based request/reply paradigm. In this interaction pattern, the managed entities themselves are
    represented as XML instances based on XML Schema definitions.
    Clients can interact with OSS/J Applications by creating XML request instance documents and
    passing that document to the Application via a JMS Text Message sent to a specific Messaging
    Queue. The Client then awaits an XML Response or Exception by listening on a provided JMS Reply
    Destination.

    The XML documents exchanged across this interface are XML requests and responses that contain
    the XML mappings of the managed entity value objects found in the JVT Session Bean.




   Web Services Integration Profile
    This Web Service interaction pattern is defined via a Web Service Profile.
    The Web Services profile is specified via a WSDL specification.
    The WSDL is added to the API specification and constitutes the API’s Web Service Integration Profile
    – or contract.

    As a minimal requirement, the Web Services Profile shall support SOAP/http transport with a literal
    message format and will rely on an XML Schema type system, following the existing XML
    Request/Response schemas used for the XML/JMS Profile.



7.2      MTOSI
MTOSI identifies four interaction patterns (called communication patterns):
       Simple Response
       Multiple Batch Response
       Bulk Response (e.g. file transfer)



???, Version 1.0                             TM Forum 2009                                  Page 17 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

       Notification
and two communication styles:
       synchronous style (AKA RPC style) which maps naturally to the HTTP technology
       asynchronous style (AKA Message style) which maps naturally to the JMS technology.

In the MTOSI methodology, the design of a service realizing a business activity includes selecting one or
more of these communication patterns.
While the MTOSI interfaces are specified in WSDL and come with bindings to JMS and HTTP, the
implementers are free to use any other middleware technologies (e.g. CORBA).




The combination of communication patterns and communication styles result in the definition of “Message
Exchange Patterns” (MEP). Each MEP fully identifies the messages and the choreography (sequencing
and cardinality) of messages independently from a business activity.
A MEP can be equated to a SOAP MEP.
The table below summarizes the possible 8 combinations of communication styles and communication
patterns
into individual MEPs. This table represents the MTOSI MEP portfolio: Each business activity can
reference to one or more MEP to fully identify the mechanism to achieve the business goal in the MTOSI
specification.




???, Version 1.0                             TM Forum 2009                                  Page 18 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




???, Version 1.0                        TM Forum 2009   Page 19 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




8 How to uniquely identify an inventory instance

8.1      OSSJ
All managed entities that are handled by the Inventory Sessions have a key. These keys are extended
from the OSS Common API CBEManagedEntityKey that defines a number of common operations and
attributes. Three of these attributes are the applicationContext, applicationDN and the type of managed
entity.
The hierarchical naming is typical for the Resource Inventory, where equipment containment hierarchy is
used for naming. However, in some cases hierarchical naming may also be useful in Service and Product
Inventory. The HierarchicalPrimaryKey interface (see the interface definition below) represents a primary
key used on a hierarchy, e.g., X.500 or LDAP directory.
Every entity in the hierarchy has a Distinguished Name (DN), which is made up of a sequence of Relative
Distinguished Names (RDNs). Commas separate the RDNs. An RDN is unique for given base in the
hierarchy. A DN is unique to the entire hierarchy.
If hierarchical naming is used the primary key of the inventory entity is equivalent to the DN of the entity.
The Inventory API allows both auto-naming, i.e., the inventory system provides the primary keys of
created managed entities, and client-provided naming, i.e., the client provides the primary keys of created
managed entities.




8.2      MTOSI
All MTOSI object instances have a unique Distinguished Name (DN) which is a sequence of Relative
Distinguished Names (RDNs).
A set of normative rules drive the naming scheme:
       Few MTOSI object classes can be used at the top level; they are: Management Domain,
        Operations Systems, Transmission Descriptor and Alarm Severity Assignment Profile.
       All other MTOSI objects must comply with the naming definition with respect to the MTOSI
        hierarchy by indicating its location with the identification of its parent object type. Such instance
        hierarchies must be rooted by globally unique Management Domain object instances.
There is notion of geography associated with a MD object since Management Domain objects are
introduced solely for the purpose of guaranteeing unique names. The way objects are organized as
subordinates of different MD objects is under the entire responsibility of the Service Provider when
deploying MTOSI.




???, Version 1.0                               TM Forum 2009                                     Page 20 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

The figure below shows an example of an inventory hierarchy of object instances, with Managed
Elements (ME) instances and Multi Layer Sub Networks (MLSN) instances structured using several
different MD objects.

                   MD=Alcatel
                                                ME=me1
                                                ME=me2            12 MEs and no MLSN

                                                          …
                   MD=Fujitsu
                                                 ME=me1
                                                 ME=me2           6 MEs and no MLSN

                                                           …
                   MD=Ericsson

                   MD=Cisco

                   MD=Nortel


                   MD=France
                                                 MLSN=Nice               2 MLSN and no ME
                                                 MLSN=Marseille


                   MD=Italy
                                                 MLSN=Turino
                                                                         3 MLSN and no ME
                                                 MLSN=Milano
                                                 MLSN=Roma




???, Version 1.0                          TM Forum 2009                                Page 21 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




9 API Style

9.1       Generic Aspects
9.1.1              OSSJ
The Inventory API uses the “javax.oss.cbe” package. The CBE package defines a set of interfaces that
represents the upper layers of a generic information model within the OSS domain. The CBE package
defines a set of shareable Data Transfer Objects aligned with TMF SID. The javax.oss.cbe package do
not directly define inventory-managed entities. It define a set of base abstract types from which the entire
inventory managed entities must derive.




9.1.2              MTOSI
??? TBD




???, Version 1.0                              TM Forum 2009                                    Page 22 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note


9.2       Specific Inventory Aspects
9.2.1              OSSJ
The Inventory API defines a JVT Session interfaces where all the operations are relative to the base CBE
Core Model Managed Entities. That is all Inventory API Operations are in term of CBE Entities,
Associations and Specifications.
The Inventory API provides JVT and XML/JMS based interfaces for the following         operations:
       Create, remove, update and query inventory entities, entity specifications      and associations;
       Invoke named queries and update procedures;
       Perform metadata queries;
       Receive notifications of inventory events;
       Import and export inventory data;
       Validate inventory data.
Discovery of inventory information, computation and propagation of inventory entity state and
configuration management are outside the scope of the Inventory API. However the Inventory API
provides the base operations for file-based import/export, which can be used by resource discovery
components.
The API implementers are free to choose their own entity implementations. They may use J2EE Entity
Beans to model the underlying entities, however, this is not required, nor is it visible through the OSS
Inventory API. Instead all communication between the OSS Inventory API Client and the OSS Inventory
API implementation is done via Value objects, using Java objects for the JVT access interface and XML
messages for the XML-JMS access interface. By, using Value objects, the Client can indirectly create,
modify and remove the underlying entities. To identify the entities, the attribute key of the Value object is
used.

9.2.2              MTOSI
??? TBD



9.3       Interaction, Operations, Events
9.3.1              OSSJ

9.3.1.1 General Features
       Template based operations
        Some JVT operations are used to retrieve or update managed entity values based on a simple
        associative lookup with the attribute values provided in a template or an array of templates. All
        the managed entities matching the attribute values provided in the value template are under the
        “scope” of the JVT operation.
       Iterator
        The value iterator, created as a result of such JVT operation, contains the complete result set and
        allows retrieving the results at client-controlled rate. The JVT operation returns a reference to the
        iterator and the client then invokes operations on the iterator to receive batches of results in sizes
        determined by the client through the “howMany” parameter. The iterator keeps track of how far


???, Version 1.0                              TM Forum 2009                                     Page 23 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

        through the results the client has progressed. The array of entities returned by the iterator is
        empty when no more results are available.
       Graphs
        Inventory graphs are collections that may include inventory entities, entity specifications and
        associations. These collections are normally returned as response to inventory queries. The
        results of some queries may be better presented as a set of sub-graphs instead of a single
        combined graph.

9.3.1.2 Operations related to Entities, EntitySpecifications, Associations
    The following table summarizes the “get” operations supported by the JVTInventorySession following
    the “get” operation specifications defined in the OSS through Java TM Design Guidelines. Only
    getters for Entities are shown; similar operations exist for EntitySpecifications and for Associations.




??? Equivalent list of operations exist for Set, Create and Remove.

9.3.1.3 Named Queries
    Named queries are used to implement complex query operations. The result of a named query is
    called a query response. The inventory specification uses query responses that are inventory “graph”,
    i.e., a collection of inventory values that may include entities, specifications and associations. Usually
    the template- based JVT operations are not sufficient to implement such complex query operations.
    As part of the query value definition, the OSS Inventory API specifies the complete set of inventory
    value types that may be returned by the query. A client may be interested only in specific value types
    and not in others. In order to deal with the requirement for filtering, all queries defined by the
    Inventory API have a setReturnedTypes(…) method that allows clients to specify the inventory value
    types they want to be included in the returned graph.

    The JVTSession defines the following operations for executing named queries.




    and operations associated with query types and query values:


???, Version 1.0                              TM Forum 2009                                     Page 24 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




9.3.1.4 File based export and import
    The JVTSession defines the following operations for file based import and export of inventory data:




9.3.1.5 Events
          The Inventory API defines the following events
          ??? same with EntitySpecification and Associations




9.3.2              MTOSI
??? TBD
…
event notification types supported at the interface should be replaced by the following list:
       object creation,
       object deletion,
       attribute value change,
       state change,




???, Version 1.0                              TM Forum 2009                                    Page 25 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note


9.3.3              Comments
In OSSJ, the interaction style (template, iterator, named queries) is driven by specific operations which
have specific names and specific signature which forces to take decision at development time (cannot be
delayed at run time). For instance, the way OSSJ uses Iterators is static in the sense that the returned
type of the invoked operation differs depending if iteration is expected or not (array of EntityKeyResult
versus EntityKeyResultIterator).
Same approach (compilation time static) applies to the mechanism how to control the value types
returned by a query:
As part of the query value definition, the OSS Inventory API specifies the complete set of inventory value
types that may be returned by the query. A client may be interested only in specific value types and not in
others. In order to deal with the requirement for filtering, all queries defined by the Inventory API have a
setReturnedTypes(…) method that allows clients to specify the inventory value types they want to be
included in the returned graph.




???, Version 1.0                              TM Forum 2009                                   Page 26 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




10 Positioning
??? TBD
OSSJ Inventory = Meta Modeling
   “The OSS/J Inventory API provides a large amount of operations which are appropriate for a client
   application “to retrieve attribute, role, cardinality and other constraints applicable to associations and
   entities for the purpose of data validation. (The definition and retrieval of complex semantic rules are
   beyond the scope of this specification.)”

    “It is appropriate for a client application that is totally agnostic of the information model supported by
    the server system it connects to, in order to discover this information model.”


MTOSI = Multi Technology




???, Version 1.0                               TM Forum 2009                                     Page 27 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




11 Synoptic Feature Comparison
??? I wrote the table below a while ago.
It may still be useful (not yet convinced for now); if I keep it it will need to be completed and revisited.


  Feature                  MTOSI                            Examples                               Comments
lexical            Lexical conventions       AlarmSeverityAssignmentProfile
conventions        for all kinds of          ASAP
                   identifiers are
                   precisely (see [1]).
                   Two aspects:              UccStyle, lccStyle, CONSTANT_STYLE
                   - Form (long or short)
                   - Capitalisation styles
                                             - Bool values should start with “is”
                   Also, conventions for
                                             - Reference should end with “Ref”
                   some value type                                                      aggregationKind’
                   representations.          - Enumeration should end with “Kind”…

Naming             Two styles:               The DN of all MTOSI objects is based
                                             on an un-constraint sequence of RDNs.
                      hierarchical:
                       - Uses the
                       concept of DN
                       and RDN
                       - valid RDN
                       attribute names
                       are specified
                       - MD
                       (Management
                       Domain) used for
                       top level object
                       name
                       - but there are
                       other top level
                       objects as well
                       (e.g. in RM: OS,
                       TMW, ASAP)
                       - note that there
                       is no hierarchical
                       naming style for
                       SM (??? to be
                       further
                       elaborated)
                       -
                       recommendation
                       for top level
                       object names:
                       CompanyName/
                       ObjectName
                      “key” based: A



???, Version 1.0                                  TM Forum 2009                                    Page 28 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

                       Network Access
                       Domain (NAD)
                       represents a
                       domain to which
                       certain
                       transmission
                       network
                       resources may be
                       assigned
                       (??? to be further
                       elaborated)
CBE                - SM uses CBEs from                                                 MB: there is no concept of
                   the SID                                                             RFSSpec in MTOSI, which
                   - RM does not use                                                   “forces” the inventory retrieval
                   CBE from the SID                                                    to repeat details for each
                                                                                       instance selected. As opposed
                                                                                       to the SM APIs where the
                                                                                       usage of CFSSpecs allows to
                                                                                       group all the globally set values
                                                                                       for all the associated instances.
versioning         ??? TDB
extensibility      ??? TDB
MEP                ??? TDB
                   SRR | ARR | SIT |
                   ABR | SFB | AFB |
                   SN | AN
CommonObj          ??? TDB
ectInfo
Attribute          ??? TDB
matching
rules
MART               ??? TDB
Multi-event        ??? TDB
notifications
Separate           - Data entities only
Data from          have attributes and
Operations         associations..
(DM versus         Notifications are also
OM DDPs)           treated as data
                   entities.
                   - Service interfaces
                   only have operations
IA:                Does not reflect any
protocol           middleware aspects –
neutral            HTTP, CORBA, JMS)
IA:                A UML Profile has        The "operation" metaclass has been
UML                been defined to          extended with the capability to specify:


???, Version 1.0                                 TM Forum 2009                                   Page 29 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

metamodel          extend the
                                            Message Exchange Patterns (MEP) for
extension          - "class",
                                            the operations (SRR | ARR | SIT | ABR |
                   - "structuralFeature"
                                            SFB | AFB | SN | AN),
                   - "operation"
                   metaclasses of the
                   core metamodel
IA:                - primitive types
Basic types        supplied by RSM
                   - plus 4 new ones:
                   ItuTime
                   ObjectName
                   Real
                   UnsignedInteger
IA:                Different categories
Categories of      (stereotypes):
complex            - dataType,
types              - enumeration,
                   - choice




IA:                Different conventions    Data type names must be unique            MB: name unicity does not
Conventions        are specified, such as   across all data type names defined in     scale, and breaks the rule that
for complex        (among others):          the whole mTOP.                           DDPs can be worked on in
data types         - name (of the type)                                               parallel by different teams
                   must be unique

IA:                Among others:            Attribute names must be unique across     MB: name unicity does not
Conventions        - name (of the           all data type names defined in the        scale, and breaks the rule that
for complex        attribute) must be       whole mTOP.                               DDPs can be worked on in
data types         unique                                                             parallel by different teams
attributes         - attr default value
                   - attr multiplicity
IA:                Among others:                                                      MB: name unicity does not
Object             - name (of the object                                              scale, and breaks the rule that
Classes            class) must be unique                                              DDPs can be worked on in
                   - inheritance and                                                  parallel by different teams
                   multiple inheritance
                                                                                      MB: there is no concept of a
                   may be used
                                                                                      root class.
                   - concept of Abstract
                   object class is used
                   - object notifications
                   contained in the
                   mTOPClass
                   stereotype for
                   (objectCreation,
                   objectDeletion,
                   objectDiscovery).
IA:                Among others:                                                      MB: name unicity does not


???, Version 1.0                                TM Forum 2009                                  Page 30 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

Object             - name (of the                                                        scale, and breaks the rule that
Classes            attribute) must be                                                    DDPs can be worked on in
attributes         unique                                                                parallel by different teams
                   - qualifiers: leaf,
                   ordered, static,
                   unique…
                   - invariant (contained
                   in mTOPAttribute
                   stereotype)
                   - attribute
                   notifications
                   (contained in
                   mTOPAttribute
                   stereotype)
                   - writeable
                   (contained in
                   mTOPAttribute
                   stereotype)
IA:                Among others:
Relationships      - format:
                   "<ClassName><Verb
                   Phrase><ClassName
                   >"
                   - name (of the
                   relation) must be
                   unique
                   - types of (e.g.
                   inheritance,
                   association,
                   dependency,
                   realisation)
                   - use of “role names”
                   …
IA:                Among others:
Operations         - name (of the
                   operation) must be
                   unique,
                   - qualifier: lleaf, static,
                   abstract, query
                   - preconditions,
                   postconditions
                   - idempotency
                   - MEP (contained in
                   mTOPOperation
                   stereotype)
                   - exceptions
IA:
Operation
parameters
IA:                Ampng others:                 EquipmentProtectionSwitchNotification
Notifications      - ends with the word
                   "Notification"


???, Version 1.0                                     TM Forum 2009                                Page 31 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note

                   - two common lists of
                   notification
                   parameters are
                   defined in the
                   Framework




???, Version 1.0                           TM Forum 2009   Page 32 of 33
MTOSI - OSSJ - Inventory APIs Comparison Note




12 Administrative Appendix

12.1 Document History


        Version Number        Date Modified           Modified by:            Description of
                                                                              changes



12.2 Acknowledgments


        First Name                     Last Name                       Company




12.3 How to comment on this
     document
Comments and requests for information must be in written form and addressed to the contact identified
below:


        <FirstName>      <LastName>      <Company>

        Phone:

        Fax:

        e-mail:


Please be specific, since your comments will be dealt with by the team evaluating numerous inputs and
trying to produce a single text. Thus we appreciate significant specific input. We are looking for more
input than wordsmith” items, however editing and structural help are greatly appreciated where better
clarity is the result.




???, Version 1.0                              TM Forum 2009                                   Page 33 of 33

								
To top