 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 251: Pricing API
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: Standard for defining and using complex pricing data and business rules, enabling integration, allowing business differentiating extensions. Addresses usage-based business model needs, for communications and entertainment industries and utilities. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Dormant The following information has been updated from the original request. 2005.12.09: Specification Lead: John Wilmes E-Mail Address: jwilmes Telephone Number: +1 650 817 6435 Fax Number: +1 650 817 6311 Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Covad Communications Name of Contact Person: Gabriela Chiribau E-Mail Address: gchiriba@covad.com Telephone Number: +1 408 952 6464 Fax Number: +1 408 952 7613 Specification Lead: Gabriela Chiribau E-Mail Address: gchiriba@covad.com Telephone Number: +1 408 952 6464 Fax Number: +1 408 952 7613 Initial Expert Group Membership: Covad Communications Supporting this JSR: 4DH Consulting Section 2: Request
2.1 Please describe the proposed Specification:Product and offer pricing has historically been the domain of billing, and has recently been duplicated in Ordering, Customer Relationship Management, Sales Force Automation, and Enterprise Resource Planning. As more systems and channels are concerned with pricing and offers, it makes sense to view this vital function as a role unto itself. The offer and pricing functions are essential for a company to have dynamic responses to changing market conditions on a real-time basis. Resource utilizing transactions could be priced based on the current scarcity of the resource. A carrier could match multiple competitors? prices on a geographic basis. Lower cost channels could receive favourable pricing vis-a-vis higher cost channels. The Pricing API will provide a central point to consult and determine offers and prices based on a variety of criteria including the specific customer?s profile, location, current promotions, other parties in the transactions, factors peculiar to the request, and any other set of complex, possibly inter-related points. The subscriber systems can use the Pricing API to present a list of offers, determine either static or one-time prices, or present prices that change over time and across the customer base. The Pricing API will, by necessity, contain the offer and pricing definitions. These definitions, in aggregate, form the Pricing Catalogue. In the static pricing scenario, once a prospect selects an offer, its price must be bound to the order. That prevents future offer and price changes from effecting current customers, if that is the business' desire. The Pricing API covers both service and resource pricing via their association with products (e.g., both data services subscriptions and purchase of an end-user terminal device). The API will allow the expression of the pricing rules or algorithms that will be used to calculate all fees be they for product or equipment purchase, service installation, recurring subscriptions, service usage fees or cancellation fees. To compete, a carrier needs sophisticated offer and pricing methods and technologies, much like the mechanisms that have evolved in the air transport industry. Systems such as Billing, Ordering, CRM, ERP, and SFA should be seen as subscribers to pricing, not owners of it. This API promotes Offer and Pricing Management to first-class status within the enterprise systems environment, and supports the TeleManagement Forum's ( http://tmforum.org/) eTOM and its Product & Offer Portfolio Planning and Capability Delivery components. 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 target platform is Java 2 Platform, Enterprise Edition. The Pricing API is developed consistently with JSR 144 and the other APIs developed by the OSS through Java's Initiative ( http://ossj.org) (JSR 89,90,91, 130, 142, 210) and interworks smoothly with them. 2.4 Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?Pricing related products are, currently, proprietary, and bring in both business and technological complexity. This complexity and the costs associated with it are reduced by standardising basic, widely used pricing concepts and principles captured by the TeleManagement Forum (TMF) Shared Information Data specification (SID) using Java 2 Platform, Enterprise Edition. Service providers will be able to concentrate on the differentiating factors related to pricing while relying on good integration practices and common enterprise model offered by OSS/J and the Pricing API. The Pricing API covers the need of having a common, standard API for defining and using complex pricing data and rules. 2.6 Why isn't this need met by existing specifications?Currently there is no JCP API specification that covers the Pricing area. 2.7 Please give a short description of the underlying technology or technologies:The Pricing API builds on the OSS Common API and the supporting technologies. The Pricing API will be based on standard J2EE services. The most important J2EE APIs for this JSR will be the following: EJB (Enterprise JavaBeans): To facilitate the integration of OSS components, OSS 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 is being considered to be most viable. JNDI (Java Naming and Directory Interface): The specification will include standards for JNDI names. XML: The definitions for pricing data and rules will make use of XML. CBE (OSSJ Core Business Entities): describe the foundation for a data model by defining, modeling and implementing core concepts including products, services and resources, etc. 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.
javax.oss.pricing 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?None anticipated. 2.10 Are there any security issues that cannot be addressed by the current security model?None anticipated. 2.11 Are there any internationalization or localization issues?None anticipated. 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 might impact the OSS Common API (JSR 144) section Core Business Entities specification and the OSS Inventory API (JSR 142), in the ProductOffering area. The synchronization and necessary evolutions will be managed by the OSS through Java Initiative members through the JCP process. 2.13 Please describe the anticipated schedule for the development of this specification.Submission of the JSR: August 2004 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.Details of the day-to-day working model are TBD soon after formation of an Expert Group (EG), and might use the collaboration environments provided by JCP, OSS/J and java.net. Since OSS/J participation tends to be geographically diverse, ongoing conference calls and a dedicated mailing list are the most likely communication tools for tracking progress. Various EG members will be responsible for delivering the components of the JSR, RI, and TCK. Pricing API project plan is accountable to OSS/J roadmap and project plan, which is handled and updated 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 ( http://ossj.org/) and on the JCP site. The OSS/J leads have initiated efforts to provide more information to the public through projects on java.net. Pricing API will follow the plans for OSS/J as a whole. Pricing API progress will also be updated on the JSR community page on a regular basis. 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 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 might be delivered as part of the J2SE/J2EE platform edition. 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).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.Pricing API will be made available to the public under exactly 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 ( http://ossj.org/downloads/api.shtml). 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 API Roadmap: http://ossj.org 3.2 Explanation of how these items might be used as a starting point for the work.The OSS/J API roadmap provides broad directional guideline that describes the intended direction for Pricing API. The OSS/J Core Business Entities describe the foundation for a data model that ties together all OSS/J work, based on the TMF NGOSS SID. The Pricing API is closely related to the OSS Inventory API because inventory products specifications are exposed to the market via product offerings that have associated prices. The TMF SID documents specify entities that can be used as a starting point for the Pricing API specification. |
||||||||||||||||||||||||||||||||||||||||
