 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 328: Change Management API
This JSR has been Withdrawn
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Ascom Deutschland GmbH Name of Contact Person: Gerd Hoeckelmann E-Mail Address: gerd.hoeckelmann Telephone Number: +49 241 96806 262 Fax Number: +49 241 96806 225 Specification Lead: Christian Klaus E-Mail Address: christian.klaus Telephone Number: +49 241 96806 275 Fax Number: +49 241 96806 225 Initial Expert Group Membership: Vodafone Group PLC Vodafone Group Services
Supporting this JSR: The JSR is supported by the initial group. Section 2: Request
2.1 Please describe the proposed Specification:Change Management (CM) ensures that changes are recorded, evaluated, approved, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The target Java platform is JavaEE running in an OSS. (Operations Support System). 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 Change Management API is developed consistently with JSR 144 and the APIs developed by the TM Forum (OSS through Java Initiative) and works smoothly with them. This specification being requested by this JSR provides for change management within an information/telecom communications network utilizing JEE technology. There is no apparent overlap or impact on other platform editions. 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 JSE/JEE EC is appropriate. 2.5 What need of the Java community will be addressed by the proposed specification?There is a growing trend within telecommunications industry towards the use of JEE for development of various aspects Operations Support Systems (OSSs). Without some form of standardization, there is a risk of divergent specifications proliferating throughout the industry. 2.6 Why isn't this need met by existing specifications?There are no existing open Java API specifications for change management systems; existing APIs are vendor-specific. 2.7 Please give a short description of the underlying technology or technologies:The Change Management API will be defined as a JEE API that is compliant with the OSS through Java Design Guidelines and implemented as an extension of the latest OSS Common API (JSR still to be submitted). The Key JSE/JEE platform APIs for the Change Management API will be the following:
? CBE (Core Business Entities) Value object representing business interactions, business interaction items, products, services, resources and other related objects like party and location will be modeled according to the CBE. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)The base package will be javax.oss.changemgt. 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 internationalization or localization issues within the API. The RI and 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?This specification is based on the OSS Common API (JSR 144) section Core Business Entities specification mainly in the BusinessInteraction, Party and Datatypes areas. The synchronization will be managed by the TM Forum (OSS through Java Initiative) members through the JCP process. 2.13 Please describe the anticipated schedule for the development of this specification.2009 Q1 Expert Group Formation and Expansion 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.OSS through Java Expert Groups have 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. Private and public projects will be created under the java.net collaborative environment to share the work in progress and keep the community informed of the progresses. 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 java.net projects in conformance to the policies and practices of the TM Forum (OSS/J Initiative). 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 Change 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: 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 Change 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.? OSS/J Core Business Entities (CBE) (http://www.tmforum.org/browse.aspx?catid=2951) 3.2 Explanation of how these items might be used as a starting point for the work.JSR 144 and CBE will provide base definition of the Data model as well as bases for the interface. The ITIL describes the Change Management process and the interaction with the other systems that support services. 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. |
