Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 142: OSS Inventory API

Updates to the Original Java Specification Request (JSR)

The following has been updated from the original JSR:

2.11 Please describe the anticipated schedule for the development of this specification.

  • JSR Initiation July, 2001
  • Community Draft: April 2002
  • Public Draft: Q3, 2002
  • Proposed Final Draft: mid November 2003
  • Final Release: end of December 2003

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Nortel Networks

Name of Contact Person: Peter Gorecki

E-Mail Address: pgorecki@nortelnetworks.com

Telephone Number: +1 613 765 5165

Fax Number:


Specification Lead: Vassil Rachkov

E-Mail Address: vassil@nortelnetworks.com

Telephone Number: +1 613 763 1406

Fax Number:


Initial Expert Group Membership:

  • Co-Submitting Member: Ericsson
    Name of Contact Person: Lars Tenfalt
    E-mail Address: Lars.Tenfalt@erv.ericsson.se
    Telephone Number: +46 31 747 1974
    Fax Number: +46 31 747 2942
  • Co-Submitting Member: Motorola
    Name of Contact Person: Eric Coleman
    E-mail Address: E.Coleman@motorola.com
    Telephone Number: +1 480 732 3743
    Fax Number: +1 480 732 5117
  • Co-Submitting Member: Nokia
    Name of Contact Person: Stefan Vaillant
    E-mail Address: Stefan.Vaillant@nokia.com
    Telephone Number: +49 211 9412 3973
    Fax Number: +49 211 9412 3988
  • Co-Submitting Member: NEC
    Name of Contact Person: Ken Dilbeck
    E-Mail Address: kdilbeck@necam.com
    Telephone Number: +1 214 262 3250
    Fax Number: +1 214 262 3250
  • Co-Submitting Member: Sun Microsystems
    Name of Contact Person: Philippe Goujard
    E-mail Address: philippe.goujard@uk.sun.com
    Telephone Number: +44 1276 689 414
    Fax Number: +44 1276 677 121
  • Co-Submitting Member: Telcordia Technologies
    Name of Contact Person: B.Dasarathy
    E-mail Address: das@research.telcordia.com
    Telephone Number: +1 973 829 5038
    Fax Number: +1 973 829 2645


  • Section 2: Request

    2.1 Please describe the proposed Specification:

    The inventory functions are central part of an OSS solution and a key factor for the quick rollout of new services. They provide storage of physical equipment data and configurations, network topology, logical resources, service definitions and instances, customer account information, etc.

    The variety of inventory information can be classified in several groups defining different Inventory functions (e.g. Network Inventory, Service Inventory). Each function has its specific set of inventory entities and relationships, its specific business logic and interacts with different subset of OSS components.

    The integration of products implementing specific inventory functions in end-to-end OSS solution is not a straightforward endeavor and usually requires custom built functionality, difficult to extend and maintain. Traversal of relationships between inventory entities stored in different repositories is very complex due to incompatible APIs and different information models.

    The primary goal of the OSS Inventory API is to reduce the cost of integrating inventory products with other OSS components and allow traversal of information across the boundaries of inventory components.

    API positioning The OSS Inventory API will provide an interface between inventory repositories and client applications such as Customer Relationship Management, Service and Network Activation, SLA Management, Service Impact Analysis, Service and Network Planning, etc.

    The Inventory API will provide J2EE/EJB based interfaces to create, remove, update and query inventory entities, entity templates and associations. It will provide metadata queries and allows clients to receive notifications of inventory events. The Inventory API will also allow monitoring resource utilization. B2B integration mechanisms will be provided via the specification of XML messages, exchanged across a JMS based messaging infrastructure.

    This specification will also define guidelines for creating specific inventory models. A core inventory model, will allow the navigation across the boundaries of various inventory repositories. The core model will also capture the minimal set of common concepts, defined in various standard inventory models. This will allow the integration and traversal of repositories based on different standards (e.g. 3GPP, SP-DNA, etc.).

    2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

    The target platform is Java 2 Platform, Enterprise Edition.

    2.3 What need of the Java community will be addressed by the proposed specification?

    This specification will address the need to provide standardization conventions allowing interoperability of OSS components and reducing the cost of their integration in an end-to-end OSS solution.

    2.4 Why isn't this need met by existing specifications?

    Currently, no existing J2EE specification provides a standard Inventory API. Existing Inventory APIs are generally proprietary.

    2.5 Please give a short description of the underlying technology or technologies:

    The OSS Inventory API will be based on standard J2EE services. The most important J2EE APIs for this JSR will be the following:

  • EJB (Enterprise JavaBeans): To facilitate the integration of OSS components, OSS will define standard EJB interfaces.
  • JMS (Java Message Service): Besides the ability to execute synchronous (EJB) methods calls, there is also a need to send asynchronous messages. For this, JMS is being considered to be most viable.
  • JNDI (Java Naming and Directory Interface): The specification will include standards for JNDI names.
  • 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

    The API will have one or several packages and the prefix for all packages will be "javax.oss". The remaining part of the package name will be defined according to a logical name for different parts of the API. Package names of all OSS JSRs will be coordinated to avoid ambiguous use.

    2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

    The specification has no dependency to operating systems, CPUs, or I/O devices.

    2.8 Are there any security issues that cannot be addressed by the current security model?

    None anticipated.

    2.9 Are there any internationalization or localization issues?

    None anticipated.

    2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

    None anticipated.

    2.11 Please describe the anticipated schedule for the development of this specification.

    • JSR Initiation July, 2001
    • Community Draft: 1st Qtr, 2002
    • Public Draft: 1st Qtr, 2002
    • Final Specification: 2nd Qtr, 2002
    These milestones are subject for change based on the defined feature set.
    NOTE that this schedule has been updated since the original JSR submission. The updates are listed near the top of this page.

    2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

    TBD (The working model will be compatible with the JCP.)





    Section 3: Contributions

    3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

    Inventory models are defined by:

    3.2 Explanation of how these items might be used as a starting point for the work.

    The core inventory model will provide linkage with existing standards.