 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 264: Order Management API
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: This JSR defines an interface to an Order Management component, with specific extensions for activation and work order management use-cases. 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 |
Additional Information
Section 1. Identification Submitting Member: Nokia Corporation Name of Contact Person: Andreas Ebbert-Karroum E-Mail Address: andreas.ebbert-karroum Telephone Number: +49 211 9412 3928 Fax Number: +49 211 9412 3838 Specification Lead: Andreas Ebbert-Karroum E-Mail Address: andreas.ebbert-karroum Telephone Number: +49 211 9412 3928 Fax Number: +49 211 9412 3838 Initial Expert Group Membership: Covad 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:This specification continues the work that has been started with the OSS Service Activation API (JSR 89). The goal of JSR 89 was to specify an API, which standardizes an interface to service provisioning products in an Operation Support Systems environment. While that target has been reached and the JSR is well adopted, it has now become necessary to include features that have been intentionally left out in JSR 89, and to extend the scope to cover other related use-cases, which have not been in the original scope of JSR 89. The two main abstractions of JSR 89 were services and orders. While the order model was specified in detail, the service model had to be kept simple to allow implementations of all kinds of services. In fact JSR 89 is an Order Management API, which constraints order items to services only, and leaves the concrete service definition up to the implementation. This limitation will be overcome in this JSR, as a more generic Order Management API will be defined. Starting from JSR 89 the existing order management model will be used and extended in scope and functionality. The concept of an order will be generalized from only dealing with services to dealing with an abstraction that represents anything orderable or that is needed to be fulfilled by an order. This includes but is not limited to products, services, resources and work order items, since concrete instances of the generic order item abstraction will be defined in this API to cover the full eTom provisioning stack on one hand (product, service and resource activation) and on the other hand the ability to process work orders (as order items). Products wrap services as a bundle that can be presented and marketed to customers. Resources are the realization of services in the network. This layered approach enables the separation of the provisioning process for products, services and resources: The input to the product activation component comes from CMR or self service products, and then decomposes in two steps to separated (in implementation and deployment) but integrated (in concept and process) service and resource provisioning, with the latter then handling the necessary network element configuration internally. Work orders are used in workforce management systems that allow network and service managers to assign work orders to the best skilled persons, plan staff size and skill mix (avoiding costly overstaffing or poor service due to understaffing). Work orders take the form of repair tickets and installation orders that are similar to trouble tickets, but with additional information such as location, required skill and requested repair time. The functionality will be extended to cover left-overs from JSR 89 as well as new requirements: Those include bulk orders, atomic order handling, capability for extended order state model discovery and mapping of order types to distinct order item types. Special attention during the definition of the specification and implementation of the RI and TCK will be paid to the alignment with the latest version of the OSS Common API (JSR still to be submitted), which will include the OSS Core Business Entities (CBE). These Core Business Entities enable component-spanning processes with independent standardized interfaces for those components. For example the CBE defines the root service abstraction, which is used in the OSS Inventory API as well as it will be used in this JSR and thus enables use-cases that span OSS Inventory API implementations and Order Management API implementations. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Server 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 Order Management API is developed consistently with JSR 144 and the other APIs developed by the OSS through Java Initiative (OSS/J) (JSR 89, 90, 91, 130, 142, 210, 251, 254 and 263) and interoperates smoothly with them. 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?The JSR 89 has been well received by the Java community and there are several adoptions for it. This new JSR will address further requirements to and intentional omissions from the old JSR. The JSR will be aligned with the latest OSS Common API (JSR still to be submitted) and latest Design Guidelines, which will include the Webservices integration profile, further design pattern implementations and also the so called Core Business Entities (CBE). In short the CBEs allow business processes to span multiple OSS/J certified components more easily. That means, that in addition to the JVT and XML/JMS integration profile, this JSR will also define a Webservices integration profile by following the OSS Design Guidelines. Current users/implementers of the existing JSR 89 OSS Service Activation API will be able to continue using the OSS Service Activation API for as long as they wish. Once this JSR is completed, those individuals or organizations will have a straightforward migration path to implement the newer Order Management API, using their existing code bases. A complete rewrite will not be needed. 2.6 Why isn't this need met by existing specifications?At the time of the specification of JSR 89, either not all requirements have been clear or advanced specification items have been postponed to later JSR, to keep JSR 89 simple and still useful. 2.7 Please give a short description of the underlying technology or technologies:The Order 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 latest OSS Common API (JSR still to be submitted). The Key J2SE/J2EE platform APIs for the Order Management 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 base package will be javax.oss.om. 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 internationalisation 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?JSR 89 (OSS Service Activation API 1.0) will be deprecated once this JSR is completed. 2.13 Please describe the anticipated schedule for the development of this specification.2004-01-14 Expert Group Formation and Expansion 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 Service Activation API specification, 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 Order 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. The EG for this JSR will follow the policies and practices of the OSS/J Initiative. 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. 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 Order 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 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 Order 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.The work by OMG and WfMC was leveraged for the state model of the OSS Service Activation API. Documents provided by the OSS through Java Initiative will be followed to achieve smooth integration and consistency with other OSS specifications. 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
