 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 263: Fault Management API
The following information has been updated from the original proposal.
2006.12.15:
Specification Lead: Marc Flauw, Hewlett-Packard E-Mail Address: marc.flauw Telephone Number: +33 (0) 1 57 62 4187 Fax Number: +33 (0) 1 57 62 75 20 Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Motorola Name of Contact Person: Dave Raymer E-Mail Address: david.raymer@motorola.com Telephone Number: +1 817 245 6834 Fax Number: +1 817 245 8113 Specification Lead: Dave Raymer E-Mail Address: david.raymer@motorola.com Telephone Number: +1 817 245 6834 Fax Number: +1 817 245 8113 Initial Expert Group Membership: Motorola Supporting this JSR: This JSR is supported by all the member companies of the OSS through Java Initiative. Please see http://www.ossj.org/aboutus/members.shtml for the current list of OSS/J member companies. Section 2: Request
2.1 Please describe the proposed Specification:The Fault Management (FM) API specification is the network-facing API. The network-facing FM API will interface element managers, and/or system managers and/or or sub-network managers that provide fault information when an undesired event occurs. The API will specify the configuration interface for fault detection including alarm formatting and reporting to enable discovery, isolation, and correction problems. Within the APIs that have been defined by the OSS through JavaTM Initiative, the fault management functionality is embedded within the OSS Quality of Service API. The FM API JSR is the first of two JSRs to separate the fault management functionality from the OSS Quality of Service API. The second JSR (to be submitted at a later date) will provide for a standalone (without embedded FM functionality) performance measurement and thresholding API (Performance Management). The specification that would be produced by this JSR would start by lifting the existing FM functionality for the OSS Quality of Service API, and then update that functionality based on requests received from the community since the first release of the OSS Quality of Service API as well as adding additional functionality to make the resulting API aligned with the 3GPP Release 6 Alarm and Notification Integration Reference Point (IRP) specifications. No existing interfaces or operations will be removed from the FM functionality. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Server. The target Java platform is J2EE running in an OSS, NMS, or EMS. (Operations Support System, Network Management System and Element Management System respectively). 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.The target platform is Java 2 Platform, Enterprise Edition. The Fault Management API is developed consistently with JSR 144 and the the APIs developed by the OSS through Java Initiative and works smoothly with them. This specification being requested by this JSR provides for fault management within an information/telecom communications network utilizing J2EE technology. There is no apparent overlap or impact on other platform editions. 2.4 Should this JSR be voted on by both Executive Committees?The initiating companies do not believe that voting by both Executive Committees is required. A vote by the J2SE/J2EE EC is appropriate. 2.5 What need of the Java community will be addressed by the proposed specification?Currently, if an OSS/NMS/EMS vendor wants to implement fault management functionality using the OSS/J APIs/Design Guidelines, they must implement some portion of the OSS Quality of Service performance monitoring and thresholding functionality in order to be OSS/J compliant/certified. This JSR will enable a vendor to only implement the functionality related to fault management and provide a more coherent component model for the OSS through Java API set. Current users/implementers of the existing JSR-90 OSS QoS API will be able to continue using the QoS API for as long as they wish. Once the follow-on Performance Management API is initiated, those individuals or organizations using the QoS API will have a straight forward migration path to implement the newer FM and PM APIs, using their existing code bases. A complete rewrite will not be needed. 2.6 Why isn't this need met by existing specifications?As noted above, the fault management functionality is currently embedded within the OSS Quality of Service API. For the developers of stand alone fault management applications, it will be more natural and straightforward to use only this JSR. 2.7 Please give a short description of the underlying technology or technologies:The Fault Management API will be defined as a J2EE API that is compliant with the OSS through Java Design Guidelines and implemented as an extension of the OSS Common API (JSR 144). The Key J2SE/J2EE platform APIs for the FM API will be the following:
2.8 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. The base package will ?javax.oss.fault?. 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?There are no known dependencies on specific devices, operating systems, etc within the specification. 2.10 Are there any security issues that cannot be addressed by the current security model?The existing J2EE platform security model is sufficient for the proposed API and implementations of that API. 2.11 Are there any internationalization or localization issues?There are no known internationalisation or localization issues within the API itself. The RI will provide a resource bundle for exception messages in the English language. The TCK will be delivered in English language only. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?Not directly; however the JSR 90: OSS Quality of Service API will be deprecated once the second related JSR (Performance Measurement and Thresholding) is completed. Even in light of the second API the existing OSS Quality of Service API can continue to be used. 2.13 Please describe the anticipated schedule for the development of this specification.
2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.In the past, OSS through Java Expert Groups have had membership from a geographically diverse set community members. In order to facilitate communications and minimize travel expenses for participants, the expert group will accomplish the vast majority of its work via conference calls and a dedicated mailing list. The Expert Group will start work from the existing OSS Quality of Service API specification, the release 5 3GPP Alarm IRP, the latest version of the OSS Common API, OSS through Java Design Guidelines, and the OSS Core Business Entities. The Expert Group will work via consensus, and where consensus cannot be reached a formal vote via email will be taken with a simple majority needed to carry the vote. The Fault Management project plan is accountable to OSS/J project plan, which is currently maintained by the OSS/J Product Team. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.Progress updates will be provided on the OSS/J main web site. The OSS/J leads have initiated efforts to provide more information to the public through projects on java.net. Fault Management API will follow the policies and practices of the OSS/J Initiative. In May 2004, the OSS/J technology has been formally endorsed by the TeleManagement Forum (TMF) has the first technology specific implementation of NGOSS standards. Some elements of the NGOSS standards are themselves referenced by the International Telecommunications Union (ITU) as de-jure ITU recommendations. The scope and progress of this JSR will therefore also be reported to the telecommunication industry through TMF, ITU and other standard bodies such as 3GPP, OMA, OMG. In addition the OSS/J Initiative reports progress of its work at various industry conferences and with its own public seminars, on line seminars and workshops.The progress of the API will be kept current on the JSR specific web page(s) provided by and hosted on the Java Community Process Website (http://www.jcp.org). 2.16 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 Fault Management RI and TCK will be delivered as stand alone packages, under the same licensing model and certification model as all other OSS/J APIs. If, by the time of release, a decision is made to include OSS/J APIs as part of the J2SE/J2EE platform, the RI and TCK may be delivered as part of the J2SE/J2EE platform edition, with the agreement of the OSS through Java membership and the expert group membership. 2.17 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).Not applicable. 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The Fault Management API will be made available to the public under the same terms and conditions as all other OSS/J APIs, which is called the OSS/J Harmonized Licensing and Certification Model. The agreements for the Specifications, the Reference Implementations and the TCKs can be viewed by downloading any OSS/J API. 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.
3.2 Explanation of how these items might be used as a starting point for the work.As explained above, this JSR intends to separate the fault management functionality from the JSR90: OSS QoS API into a standalone API therefore the existing QoS API specification will be used as the basis for the work. Additionally, the fault management functionality with the OSS QoS API is based on the release 4 version of fault management from 3GPP. This JSR will up-rev the fault management functionality to be complete with the release 5 Alarm IRP from 3GPP. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.At this time there is no additional information for this JSR proposal. |
