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|
|Ubiquitous domain language/model|
Please be aware that only generic elements of this model are used to ensure that the API is not bound to telecommunications specific systems only.
|XML Document based|
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.|
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 😉