Comments on OSS/J Initiative in a Letter

Hi …,

I have been more or less following OSS/J since its very beginning. It is not really what they try to achieve that captures my attention (in fact, in this direction, the effort is pretty much a failure up to this point). The interesting things in OSS/J are on two aspects, in my opinion:

(1) The architecture side. The idea of exposing system interface in both a standard API way and a message way (and making those two approaches equivalent) is very important in the OSS domain, because OSS components must be built with integration in consideration from the very beginning and a message interface is essential to get integration successful in most scenarios. Also, if you look at the design guideline document in OSS/J, you can find that the architects driving OSS/J tried very hard to have reasonably generic domain object model so that it not only captures known business logics, but also is equipped with a pretty rigorous mechanism to allow extension and customization of those domain objects to accommodate unexpected future requirements. For software product architecture, this is always a very challenging job for architects and designers. The question here is how to make sure the product can be used in so many different contexts with all the different requirements.

At this moment, the second point discussed above is still valid; but the first one is more or less out of date, and WSDL, JAX-RPC 2.0 and the WS-* family of technologies provide better solutions and, more importantly, already gained the whole industry's support.

(2) The domain knowledge side. There may be other efforts in the OSS industry that I am not aware of, but OSS/J seems to be the first initiative to capture the body of knowledge in OSS through a set of open specifications and characterize it in current enterprise information technology context. If we look at the specifications on QoS, IP Billing, Service Activation and others, it really tells a lot on what OSS really means and what features are expected in such systems. The overall architecture provides organized structure showing how OSS is actually working. This kind of knowledge can be critical for lowering the barrier of entry to OSS industry.

In summary, my thought is that OSS/J is not something we can propose as a whole for solutions meeting the OSS challenges faced by telecom industry. But there are definitely a lot of things in OSS/J we can learn from, particularly on OSS middleware architecture and on domain knowledge.

The fates of technology initiatives in telecom such as OSA/Parlay/JAIN, SIP and OMA etc. are not all clear to say the least. The convergence of IT and telecom is yet to be well understood. This is an emerging domain. Business conditions are still evolving and keep changing very quickly. It needs some real vision and guts from the senior management teams of OSS middleware providers to do things right.It is not always a technical issue.

Best,

Young