Home

News: Final Release: JSR 264 - Order Management API

  1. The Java Specification Request 264 Order Management API 1.0, has been released. It is one of the latest APIs specified within the OSS through Java Initiative (OSS/J). Operations Support System (OSS) are systems used by telecommunications service providers to manage their Network and IT infrastructure. The Order Management API proposes a generic interface capable of handling Product, Service, Resource and WorkOrder Orders. It will also support your own definition of an order by extending the generic orders. To our best knowledge, the Order Management API is the only open and standardized API available for order management, relevant to any organization developing order management solutions. Your Order Management solution based on this API reuses the wealth of the OM domain knowledge captured in the API (not reinventing the wheel). You are reducing your development and integration costs, creating a flexible Order Management solution. Beside the value the API is delivering on its own, it has been closely integrated with three other either new or maintained OSS/J APIs, defined within the Java Community Process (JCP): The OSS Trouble Ticket API (JSR 91), the OSS Inventory API (JSR 142) and the Fault Management API (JSR 265). With this new release, users now have a consistent set of standard interfaces built on a common foundation that enables rapid creation of OSS solutions, including supporting SOA Architectures. Offering WebServices, XML Messaging and EJB Integration Profile New to this release, three integration profiles that use Java, XML messaging or Web Services, are provided to support tightly coupled, loosely coupled or B2B integration scenarios, in the eTOM’s Operations Support and Readiness, Fulfillment and Assurance. "The addition of XML and Web Services integration profiles to OSS/J is great. This allows web services platforms to offer services that are standards-based using standard data formats. We are looking forward to leveraging this as we extend our Web Services platform." Says Kumar Rajan, Executive Director, Verizon Business IT. Order Management is a very common approach to interface and manage the business processes and virtually every organization does some sort of Order Management. This ensures that it can process requests from its customers, delivering the requested products or services. Although the OSS/J APIs has originally been targeted for OSS applications we have ensured that the OM API could alos be used in other domains or industries. Order Management API Key Features The key OM API features are:
    • Support for creation, starting, updating and removal of Orders;
    • Extensibility. The types of orders, their content and states can be extended for your specific needs;
    • Support for static and dynamic typing of attributes of an Order and Order Items;
    • Flexible query capabilities like query by a Key, query based on a template, named queries (comparable to JDBC Prepared Statements);
    • Support for both simple and complex use cases;
    • Support for long running transactions;
    • Definition of the managed entities upon which the Order Management API is based (Order, OrderItems, etc). The Core Business Entities (CBE) have been extended from the Telemanagement Forums Shared Information/Data Model (SID). The Entities used are the non Telecommunications specific;
    • Definition of the (extensible) state model for Orders and OrderItems;
    • Support for bulk operations to create, update or remove orders. These are available in an atomic (all must succeed) or best effort (failed items will be reported) mode of operations;
    • Support for bulk orders, orders that aggregate other orders.
    • Support for notification to keep OM clients informed of the progress of an Order (not only clients that submitted an order but also other interested clients);
    • Notifications – OM System can request the client to validate certain aspects of the order (before it continuing processing);
    • Notifications – OM System can request the client to provide additional input (before it continues processing);
    • Support meta-operations. For example, enable a client to discover at runtime what Order types, Products, Services, attributes, queries or optional features are supported by a particular OM System (implementing the API);
    The Order Management API applications are not limited to OSS or Telecommunications. The API will support your definition of order types and and thus can be configured to support 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’ has been defined. This Request type is the supertype for all Orders and all Order Management API operations operate on Requests. You can define your own Order types as subtypes of the Request, or as a subtype of one of the four predefined Request subtypes: ProductOrder, ServiceOrder, ResourceOrder, WorkOrder (WorkOrders are frequently used to manage Workforce requests). Free With Sources: Reference Implementation and Technology Compatibility Kit All JSR’s defined within the Java Community Process are provided with a Reference Implementation (RI) and a Technology Compatibility Kit (TCK). The JSR 264 specification can be downloaded from the JCP website. The RI and TCK are available at the TelemanagementForum website. More information on JSR264 can be found at the JSR264 java.net site. They all come with sources and licenses that make it easy for everybody to draw immediate value from them. The RI can be deployed on the latest Glassfish (JavaEE SDK) application server. Others can be supported with small modifications. The TCK can be run against any JSR 264 Implementation and can be used to test the Implementation compatibility with the API Specification. TCK run against an Implementation will produce a test report that can be used by the implementation organization to certify the Implementation/SW Product as JSR 264 compliant. References And Further Reading And Listening
  2. J2EE or JEE spec[ Go to top ]

    Can someone confirm if the OSS/J specs are J2EE oriented? If so, isn't a JEE update in order?
  3. Re: J2EE or JEE spec[ Go to top ]

    Hi Srgjan, the mentioned java integration profile is based on J2EE, as you say. It defines an interface for a stateless session bean and all the transfer objects. The javadocs are linked in the article for your review. You are also correct that an update of the OSS/J Design Guidelines is in progress, that will probably also include an upgrade to JavaEE 5. But it's still in a quite early stage yet. However, the current spec can still be implemented with JavaEE 5, as the reference implementation showed. Andreas
  4. Hi, I just realized that the javadocs are not linked from the article, but "only" from our website at java.net. Here's the direct link to the javadocs: https://jsr264-public.dev.java.net/nonav/javadocs/1.0/ Kind Regards, Andreas
  5. as i can see from JOSSO Features that it has build in support for Jboss & Tomact , but dos JOSSO has support for GlassFish or Websphere ?
  6. Hi Osama, could you explain a little bit more, how the app server support of JOSSO relates to the Order Management API? Andreas
  7. Soon after the final release of JSR 264 there are updates available to the RI and TCK with some fixed bugs, but most important major performance improvements in the TCK. Both can be downloaded from the TMF Next to bug fixing and performance improvements, the code was also moved completely to the public CVS repository. If you feel like you would like to work on either the RI or the TCK or just want to browse the sources, please go ahead. Help is more than welcome and the team is always open for new ideas. These are the details of the changes to the TCK and the RI. The numbers refer to the issue tracker. TCK 1.0.1 New features
    • Changed Version of the RI in JNDI Names from 1-0 to 1-0-1.
    • Changed dependencies in pom.xml such that 1.0 version of the TCK Foundation version is used. This provides more strict checking and a significant performance improvement. For details see the Changes History of the TCK Foundation at it's website: https://ossj-tck-foundation.dev.java.net. Issue: 15.
    • Changed version of TCK pom.xml to 1.0.1 and added the configuration for the changes report plugin. Also ensure that the version number of the TCK in the generated TCK report is dynamically aadjusted to the TCK version. Issue: 16.
    Fixed Bugs
    • Corrected version of javax.javaee dependency in pom.xml to 5.0. Issue: 27.
    • File src/test/resources/MANIFEST.BASE was not included in src distribution, now it is. Issue: 25.
    RI 1.0.1 New features
    • Fix OMRI WS profile getRequestSpecificationsResponse returns actions_ItemTypeSupportedActionsPair instead of baseActions_ItemTypeSupportedActionsPair. Fixes 22.
    • Fix OMRI. In all integration profiles (EJB, XML/JMS, WS), the getSupportedOptionalOperations method is now returning a String[ ] with the names of all implemented optional operations; all not-implemented optional operations throw a OssUnsupportedOperationException. Fixes 22.
    • Fix a bug in OMRI The getSupportedOptionalOperations method is now returning a String[ ] with the names o f all implemented optional operations. Fixes 20.
    • Fix a bug in OMRI createAndStartRequestByValueRequest now returns createAndStartRequestByValueException instead of startRequestByKeyException. Fixes 20.
    • Using jdk logger for om ri logging. Log information is written to file "oss_om_ri.log" and console Fixes 19.
    • Publish following message properties on JMS Response/ExceptionMesages: OSS_MESSAGE_TYPE -> RESPONSE OR EXCEPTION; OSS_MESSAGE_NAME -> For example getRequestSpecificationsResponse; OSS_APPLICATION_TYPE -> OrderManagement; OSS_REQUEST_SENDER_ID -> This value should be the same as the value of this message property on the Request message; OSS_REPLY_SENDER_ID -> JNDI name of the RI, should be according to the OSS/J design guidleines (just as the other JNDI names we use). TCK just checks the format. Fixes 19.
    • Changed version of RI pom.xml to 1.0.1 and added the configuration for the changes report plugin. Fixes 17.
    Updates
    • Changed version in POM to 1.0.1 and also updated the name of the release bundle to order_management_j2eesdk-1_0_1-src-ri.zip
    • Moved the changes.xml to oss_om_ri_dist project, included the generated html report in the final zip file
    • Changed Version of the RI in JNDI Names from 1-0 to 1-0-1.
    Fixed Bugs
    • Point to FAQ instead of document sections for referring how to setup maven. Fixes 24.
    • Ensured that JMSCorrelationID on response is populated with JMSMessageID of request if the JMSCorrelationID is not set on the request. Fixes 18.