Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 328: Change Management API

This JSR has been Withdrawn
Reason: The JSR 328 was designed to assure a 'standard' in handling OSS(/J) change amangement and to tie it the other existing OSS/J JSRs. It was developed in close cooperation with our customer based on his requirements. Since our customer constantly diverges from the standards and since the proposal was dormant for a long time without any interest on the topic it makes no sense for our company to further pursue this proposal.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Ascom Deutschland GmbH

Name of Contact Person: Gerd Hoeckelmann

E-Mail Address: gerd.hoeckelmann@ascom-ac.de

Telephone Number: +49 241 96806 262

Fax Number: +49 241 96806 225


Specification Lead: Christian Klaus

E-Mail Address: christian.klaus@ascom-ac.de

Telephone Number: +49 241 96806 275

Fax Number: +49 241 96806 225


Initial Expert Group Membership:

Vodafone Group PLC Vodafone Group Services
Ascom Deutschland GmbH

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.
The purpose of the Change Management process is to ensure that standardized methods are used for the efficient and prompt handling of all changes; that all changes are recorded in the Configuration Management System and that overall business risk is optimized. Change management delivers, to the business, reduced errors in new or changed services and faster, more accurate implementation of changes; it allows restricted funds and resources to be focused on those changes to achieve greatest benefit to the business. This JSR proposes an API Specification for Change Management systems to operate request for changes following the IT Infrastructure Library (ITIL) "Change Management" recommendations and principles (as described in Chapter 8: Change Management, of the "Service Support" document).
The data model for this API is defined around the Request For Change (RFC) entity. The main interface focuses on creating, retrieving, updating, approving and removing RFC.
This JSR is defined and developed on top the OSS Common API (JSR 144). It will use or extends the Core business Entities (CBE) following the OSS Design Guidelines and format (documentation, specification, Reference Implementation and TCK bundle format).

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.
The ITIL defines processes to manage changes, and there is a need to specify and standardize the interface exposed by the Change Management Systems supporting the requests for change process.

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.
? 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 based on the CBE definitions
? XML: There will be an XML over JMS integration profile for the API that enables clients to interact with an API implementation via the Java Message Service
? Web Services: There will be a Web Services integration profile for the API that enables web-based applications to interact with an API implementation via Web Services.

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

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
2009 Q2 Early Draft Review
2009 Q3 Public Review
2009 Q4 Proposed Final Draft
2010 Q1 Final Release

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.
The Expert Group will start work from the latest version of the OSS Common API (including the CBE) and the OSS through Java Design Guidelines.
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 Change Management project plan is accountable to TM Forum project plan, which is currently maintained by the OSS/J 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 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:
? Free of charge
? OSS/J Harmonized License Model (Apache 2.0 based)

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)
? OSS Common API, JSR 144 (http://jcp.org/en/jsr/detail?id=144)
? ITIL V2 "Service Support", Chapter 8: Change Management

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.