Sun's submitted Java Specification Request (JSR) 250, Common Annotations for the Java Platform to the Java Community Process (JCP). According to the JSR, "This JSR well develop annotations for common semantic concepts in the J2SE and J2EE platforms that apply across a variety of individual technologies. With the addition of JSR 175 (A Metadata Facility for the JavaTM Programming Language) in the Java platform we envision that various JSRs will use annotations to enable a declarative style of programming. It would be unfortunate if these JSRs each independently defined their own annotations for common concepts. It would be especially valuable to have consistency within the J2EE 5.0 component JSRs, but it will also be valuable to allowconsistency between J2EE and J2SE. It is the intention of this JSR to define a small set of common annotations that will be available for use within other JSRs. It is hoped that this will help to avoid unnecessary redundancy or duplication between annotations defined in different JSRs. The exact set of annotations will be developed in consultation with the various specifications leads who are currently planning to use annotations within their JSRs." Comments are due by August 30.
Covad Communciations has submitted JSR-251, Pricing API to the JCP. According to the JSR,
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.
The thing that jumped out at me about this was bit about "To compete, a carrier needs sophisticated offer and pricing methods and technologies, much like the mechanisms that have evolved in the air transport industry." Doesn't Covad realize how much customers hate pricing in the airline industry? Personally, I'm convinced an airline could charge more in total for its seat capacity if they simply sold one way tickets on any given route at the same price, instead of trying to figure which customers they had to entice with low fares and which they could gouge to make up the difference. I don't have an opinion about whether this a good API for Java or not, but the business model implied here is atrocious. Comments are due by August 30.