In the previous two episodes in this series we described the position of Java in the Telecommunications industry, Telemanagement Forum and the basics of OSS/J. This episode focuses on the Order Management API (JSR 264), this is one of the OSS/J APIs being developed using the JCP process (proposed final draft 2 will be released May/June ’07). It is also the API we covered during last weeks session at JavaOne.

Order management is a common process and virtually every organization does some sort of order management to ensure that it can process requests from it’s customers and deliver the requested product (for example book, car, drivers license) or service (for example telephony, health insurance, TV). The Order Management API is (as far as we know) the only open and standards based API available for order management and therefore is relevant for many organizations developing an order management solution (not telecommunications only). By using this API as a basis for your order management solution you can reuse the knowledge of others (not reinventing the wheel) and reduce your integration costs.

The key features are:

• Supports both simple and complex use cases

• Supports long running transactions

• Defines the managed entities on which the Order Management operations work (Order, OrderItems, etc). These are extended from the Telemanagement Forums Shared Information/Data Model, the items used from the TMF SID are the non Telecommunications specific ones.

• Defines the (extendible) state model for Orders.

• Support for creation, starting, updating and removing Orders.

• Support for bulk operations to create, update, remove orders. These are available in an atomic (all must succeed) or best effort (failing ones will be reported back) flavor.

• Support for notification to keep clients informed of progress of an Order (not only clients that submitted an order but also other interested clients).

• Notifications that requests the client for validation of certain aspects of the order (before it continues processing).

• Notifications that requests the client for additional input (before it continues processing).

• Extensibility. The types of orders (and all contents) and the order states can be extended for your specific needs.

• Flexible query possibilities like query by key, query based on a template and defining named queries (comparable to JDBC Prepared Statements).

• Support for static and dynamic typing of attributes of an Order.

• Support meta-operations that (for example) enable a client to discover at runtime what orders are available.

The Order Management API is not bound to telecommunications specific orders. The API allows for definition of your own order types and and thus can be customized to the specific needs of other industries. To ensure that the operations exposed by the Order Management API are not bound to any specific industry, a generic type ‘Request’ is defined. This Request type is the supertype of all Orders and all Order Management API operations operate on Requests. It is possible to define your own Order types as subtype of Request, or as subtype of one of the four predefined Request subtypes: ProductOrder, ServiceOrder, ResourceOrder, WorkOrder (the latter requires human intervention).

“All nice and dandy”, I hear you think, “but can’t I achieve the same with BPEL?”. From a functional perspective you could realize the same functionality with BPEL (or many other technologies), however you would be inventing you own API instead of building on a standards based one. For example, BPEL will not give the standardized information model, state model or set of operations. You would need to define them yourself and thus you’re creating a proprietary solution. The advantage of reduction in integration costs is lost.