Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 210: OSS Service Quality Management API

Stage Access Start Finish
Withdrawn   23 May, 2012  
Proposed Final Draft Download page 21 Dec, 2007  
Public Review Ballot View results 16 Jan, 2007 22 Jan, 2007
Public Review Download page 19 Dec, 2006 22 Jan, 2007
Early Draft Review Download page 25 Aug, 2004 24 Sep, 2004
Expert Group Formation   01 Apr, 2003 19 Mar, 2004
JSR Review Ballot View results 18 Mar, 2003 31 Mar, 2003
Status: Withdrawn
Reason: The API has been completed and contributed to TMF and there is no reason to continue with the JSR.
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0

Provide an API via the OSS through Java initiative that allows telecom management applications to be developed and integrated with Java-enabled Service Quality Management Systems.

Please direct comments on this JSR to the Spec Lead(s)

Specification Leads
  Thierry Supplisson IBM
Expert Group
  ADC Agarwal, Niraj Hewlett-Packard
  IBM Instituto de Telecomunicacoes Mahindra British Telecom Ltd.
  Motorola Nokia Corporation Sun Microsystems, Inc.
  Watchmark Corporation

This JSR has been Withdrawn
Reason: The API has been completed and contributed to TMF and there is no reason to continue with the JSR.

Updates to the Original JSR

The following information has been updated from the original proposal.


Specification Lead: Thierry Supplisson

E-Mail Address:

Telephone Number: +353 21 730 6079

Fax Number: +353 21 730 6024

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Watchmark Corporation

Name of Contact Person: Eric Dillon

E-Mail Address:

Telephone Number: +1 425 564 8038

Fax Number: +1 425 564 8001

Specification Lead: Francois Gauthier

E-Mail Address:

Telephone Number: +1 425 564 8113

Fax Number: +1 425 564 8001

Initial Expert Group Membership:

Watchmark Corporation
Nokia Corporation

Supporting this JSR:

MetaSolv Software, Inc.
Telcordia Technologies, Inc.
Nokia Corporation

Section 2: Request

2.1 Please describe the proposed Specification:

Within an Operation Support System (OSS), a Service Quality Management (SQM) application is responsible for monitoring the overall delivered quality of a service, at the service level as experienced by a customer.

A number of Service Quality Management products are available on the market but they are all used through different sets of APIs necessitating custom integration into an OSS. The goal of this JSR is to define a standardized API based on J2EE, that will permit rapid deployment and integration of SQM products.

From a high level, Service Quality Management is achieved through comparison of service related Quality Indicators based on network-related data as well as on non-network-related data, against Service Quality Objectives. When the objective is not met anymore (threshold is crossed, e.g.), the SQM application reports a violation so that the Service Quality can be compared against Service Level Agreements (SLA) between the customers and the service provider.

The proposed SQM API is intended to implement the interface between an SQM application and an SLA application. To that extend the following functional requirements shall be met by the SQM API:

- allowing clients to create, update, delete and query quality objects (Quality Indicators and aggregated performance/usage data)
- allowing clients to create, update, delete and query objective objects (Service Objectives)
- allowing clients to subscribe for notifications on objective violation events (Service Objectives being compromised, e.g.)
- allowing clients to subscribe for notifications on availability of new quality data.
This API will leverage the OSS/J defined design guidelines 1.1 (available with JSR 144).

Note: The expert group will focus on the design of an API targeting Quality Management at the Service level. It shall also assess the relevance of this same API for a Process Quality Management scope.

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

Java 2 Platform, Enterprise Edition

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

A number of software developers in the telecommunication industry are already using EJB components for their next-generation OSS software. Without some standardization conventions for these components, the industry runs the risk of proliferating similar components with slightly different APIs. Hence, standardizing these component APIs through a Java community process is an attractive proposition.

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

Currently, no existing Java platform specification provides a standard API for OSS Service Quality Management (SQM) components. Existing SQM APIs are generally vendor-proprietary.

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

The OSS Service Quality Management API will be defined on top of J2EE. The most important J2EE APIs for this JCP will be the following:

- EJB (Enterprise JavaBeans):
To facilitate the integration of OSS components, the expert group 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 will be used.
- JNDI (Java Naming and Directory Interface):
The specification will include standards for JNDI names.
- XML:
The definitions for orders and services will make use of XML.

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 is "javax.oss". The remaining part of the package name will be defined according to a logical name for different parts of the API. The following are some of the proposed names:

The prefix "javax.oss" will be used in all OSS JSRs, including those recently submitted. Package names of all OSS JSRs will be coordinated by the OSS/J Common Team and/or Architecture Board to avoid ambiguous or conflicting package names.

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

The expected schedule for this specification is about 12 months and the major milestones in the project are listed below:

Spec Community Draft: July 2003
Spec Public Draft: Septembre 2003
Spec Proposed Final Draft: 4Q2003
Spec Final Release: 1Q2004
These dates are subject to change.

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

Once this JSR is approved, and the expert group is formed, a baseline specification will be created by a process of analyzing and comparing existing proprietary APIs, and this will be developed iteratively by the Expert Group using email and telephone conferencing as the primary mechanisms.

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI and TCK will be delivered according to the OSS Through Java Initiative guidelines.

2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).


2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

The Specification, RI and TCK will be available for download from the OSS through Java Initiative website following the same model as existing OSS/J APIs

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.

- The 3GPP ( is developing standards for 3G telecommunication networks. These recommendations can be retrieved from 3GPP web site. 3GPP Standards relevant to the OSS SQM API are

TS 32.101
TS 32.102
TS 32.111-x
TS 32.401/402/403
Work within 3GPP is done in an open fashion; there are a number of versions of each specification available. The current 3GPP release set is release 5. The 3GPP SA5 documents can be accessed here.

- The TeleManagement Forum ( has developed standards for Telecom Management. These recommendations can be retrieved from TMF web site. The TeleManagement Forum has done substantial work in the area of service quality management. Relevant TMF specifications/documents are

- Service Quality Management Business Agreement - TMF506 v1.5
- Service Quality Management for IMT 2000 Catalyst Interface Implementation Specification - TMF803 v2.1
- Wireless Services Measurements Handbook - GB923 v1.5
- Service Level Agreement Management Handbook - GB917 v1.5
- The ITU-T ( has developed standards Telecom Management. The M-Series recommendation have some relevant information. These recommendations can be bought from ITU-T web site.

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

The design of the SQM API will follow this already existing work In an effort to produce industry standard for inter-operability. When possible, existing standard and format should be considered and leveraged into the SQM API.