 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 210: OSS Service Quality Management API
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 Description: 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) Team
This JSR has been Withdrawn The following information has been updated from the original proposal. 2006.06.16: Specification Lead: Thierry Supplisson E-Mail Address: thierry.supplisson 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: eric.dillon Telephone Number: +1 425 564 8038 Fax Number: +1 425 564 8001 Specification Lead: Francois Gauthier E-Mail Address: francois.gauthier Telephone Number: +1 425 564 8113 Fax Number: +1 425 564 8001 Initial Expert Group Membership: Watchmark Corporation Supporting this JSR: MetaSolv Software, Inc. 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) 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): 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:
javax.oss 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 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).N/A 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 (http://www.3gpp.org/) 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 - The TeleManagement Forum (http://www.tmforum.org) 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 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
