 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 89: OSS Service Activation API
JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: Provide an API that allows telecom management applications to be developed and integrated with Java-enabled Service Activation systems. Please direct comments on this JSR to the Spec Lead(s) Team
Note that this information has been updated since the original proposal.
2008.10.09 Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification
Submitting Participant (Spec Lead): 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 Participant: Cygent, Inc. Name of Contact Person: David Hom E-Mail Address: david.hom@cygent.com Telephone Number: +1 415 913 3000 Fax Number: +1 415 913 3001 Co-submitting Participant: Ericsson Name of Contact Person: Stefan ?erg E-Mail Address: stefan.aberg@emw.ericsson.se Telephone Number: +46 31 747 1997 Fax Number: +46 31 747 2942 Co-submitting Participant: NEC Name of Contact Person: Hiroya Kawata E-Mail Address: h-kawata@bq.jp.nec.com Telephone Number: +81 45 939 2450 Fax Number: +81 45 939 2487 Co-submitting Participant: Nortel Networks Name of Contact Person: Colin Ashford E-Mail Address: ashford@nortelnetworks.com Telephone Number: +1 613 765 4929 Fax Number: +1 613 765 7387 Co-submitting Participant: Motorola Name of Contact Person: Frank Korinek E-Mail Address: frank.korinek@motorola.com Telephone Number: +1 847 576 1643 Fax Number: +1 847 538 5564 Co-submitting Participant: OSI Name of Contact Person: Ahmed Saleh E-Mail Address: ams1@osi.com Telephone Number: +1 905 282 1356 x1519 Fax Number: +1 905 282 9961 Co-submitting Participant: Sun Microsystems Inc. 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 Participant: Telcordia Name of Contact Person: Melbourne Barton E-Mail Address: mbarton@research.telcordia.com Telephone Number: +1 732 758 3081 Fax Number: +1 732 758 4372 Initial Expert Group Membership
Section 2: Request
2.1 Please describe the proposed Specification:In Operation Support Systems, the area of Service Provisioning is vast, and complete standards or even de-facto standards in this area are lacking. Several products manage specific parts of Service Provisioning. They can be integrated into an end-to-end solution, but these one-shot integrated solutions are extremely complex, difficult to achieve, due to the lack of integration standards. Therefore, the ability to reduce the integration effort via a set of standard, reusable software components to assemble OSS applications in a much shorter time, is an appealing prospect for all players in the OSS marketplace. The OSS Service Activation API is an API that is essential to build total OSS solutions by assembling commercial-off-the-shelf components. As the first step in the Service Provisioning area, this JCP defines the API to Service Activation products. By using the API, one can for example create, amend and cancel orders. These orders initiate the desired changes to the service, including activation, deactivation or configuration changes of the service. The terms used in the previous paragraph --- service and order --- will be the main abstractions for the API. While modelling services and orders in the API is neccessary to achieve integration, it might not be sufficient. To define a complete plug and play API for OSS Service Activation, it might be neccessary to include definitions for specific services to the API. In this case, the API will concentrate on 3G wireless services. The API is used (called) by order entry products, order manager products or workflow management products. The API is implemented by service activation products, which are often specially customised for certain network technologies (GSM, GRPS, ATM, IP, SDH, ). The API can also be implemented directly by subnetwork management systems or even by element management systems. If the API is implemented by the above mentioned products, the system integrator and service provider can buy products from different sources and integrate them with no or minimal effort to an end-to-end OSS solution. 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 components. Existing APIs are generally vendor-proprietary. 2.5 Please give a short description of the underlying technology or technologies:The OSS Service Activation API will be defined on top of J2EE. The most important J2EE APIs for this JCP will be the following:
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:
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 9 months and the major milestones in the project are listed below:
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. The TMF (http://www.tmforum.org) has developed standards for Telecom Management. These recommendations can be retrieved from TMF web site. The ITU-T (http://www.itu.int) 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.In the area of service activation, there are no standards that can be used directly as a basis for the Java API. However, some existing standards can guide the development and provide a vocabulary for the API. Among theses are the documents TMF 504 and TMF 603. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
