Java in Telecommunications – Order Management API in a Service Oriented Architecture
Posted by Gero Vermaas at around evening time: June 6, 2007
In the previous episodes in this series we started from a high level Java in the Telecommunications industry, zoomed in on Telemanagement Forum and the basics of OSS/J, described the basics of the Order Management API and now we'll discuss why the Order Management API fits perfectly in an Service Oriented Architecture (SOA). Why is this a relevant question? Virtually any organization does with order management in one way or another and many organizations are currently evaluating or realizing SOAs. Reason enough to check if the Order Management API fits in an SOA.
SOA is the most hyped TLA over the last years... Because SOA is so hyped and every vendor is trying to give a definition that's a perfect match for their product, we decided to not start with an SOA definition in our JavaOne and TMW presentations. Instead we took a more practical approach and compiled a list of concepts that are important for an SOA. We then checked if the Order Management API applied these concepts. The more concepts applied, the better the fit for use of the Order Management API in a SOA. An easy and efficient approach.
Below is the list of concepts we identified and per concept how this is applied in the Order Management API.
| Service reuse | Services exposed by the API can be reused for different types of Orders and are not bound to any specific business process. |
| Modular and autonomous | The OM API is modular because it supports various types of Orders and each implementation can extend the types of Order supported. New order types can be plugged in without changing the API. From the larger architecture perspective an OM API implementation can be seen as a module with a clear task: Order Management. It does for example not cover inventory management or CRM.The OM API is autonomous because it does not depend on other APIs to be implemented. If you implement the OM API, you have a fully functional Order Management system which can work autonomously. |
| Coarse grained | It is coarse grained becuase it allows for creation and starting of Orders by one call. There is no nitty-gritty interaction needed to create orders. |
| Asynchronous | Asynchronous interactions are supported by the events that are available on all integration profiles (EJB, XML/JMS and web services) and of course for the XML/JMS profile all interactions are asynchronous. |
| Stateless | While interacting with an OM implementation there is no stateful session being maintained (with the exception of execution large queries in which the result can be queried in batches). |
| Composable | The services exposed by the API can be used in larger business flows. |
| Described services | The services exposed by the API are well described via the XSDs (XML/JMS and webservice profiles), Javadoc (EJB profile). |
| Ubiquitous domain language/model | All entities used in the API are based on the TelemanagementForums Shared Information and Data model. This provides the ubiquitous language. |
| Reliable messaging | Reliable messaging is supported through the JMS profile (and in future probably also for web service profile using the WS-Reliable Messaging standard). |
| Loosely coupled | Loose coupling is provided through the XML/JMS and web services profile. |
| XML Document based | Both the XML/JMS and web services profile use XML based message exchanges. |
| Interoperable | The web services profile support interoperability with other implementation technologies. Interoperability is also supported by the XML/JMS profile since many JMS providers provide APIs for non-Java clients. |
These are all the concepts that apply to the Order Management API. The following concepts are not addressed by the Order Management API and I'll explain why:
| Versioning | There is no standard way for versioning of (for example) orders without breaking already connected clients. For example, when you'd add an attribute to an Order on the server, clients that validate the XML against the XML Schema will break.There are some ways to deal with this, but the Order Management API (or the OSS/J APIs in general) dooes not define how this situation should be handled. Luckily the Order Management API does provide support for dynamic attributes and by using these the problem becomes less urgent, but it is something that should be addressed in the future. |
Policy Driven, Registry and discovery, Orchestration |
These concepts should not be defined by one single system in a SOA, but are the responsibility of the SOA eco-system. Order Management API implementations can perfectly participate in a policy driven SOA, or be registered and discovered, or be used by and orchestration engine, but, the API does and should not define how this is realized. |
Security |
The Order Management API itself does not specify how security should be addressed, but because it builds on the JavaEE and web service specifications, the security features of JavaEE and web services can be used to address security needs. |
In summary the Order Management API conforms to most of the relevant SOA concepts. If you're in a situation where an Order Management system needs to be integrated into an SOA, consider the Order Management API (JSR264). In case you're missing important SOA concepts, let me know, then I'll explain if and how the Order Management API applies these concepts.
This entry roughly covered the second part of our JavaOne and TMW presentations. What's next... not sure yet, but I'll be back with more Java and telco related posts. Suggestions are welcome 
Filed under: Java, SOA, Telecommunications
November 16th, 2007 at 10:32 am
[…] It integrates easily into a SOA, see previous blog posting. […]