Catching up with Java Use in Telco Companies (OSS/J)
In short, Telcos have similar business models all of which rely on fairly similar IT infrastructures to do things like billing, order management, inventory management, etc. These IT systems are called Operations Support Systems in the Telco space. Telcos typically rely on proprietary third party software to provide solutions for these problems rather than re-inventing the wheel each time. However, integrating third party software into a telco's IT is considered far more expensive than the cost of the software itself, and the proprietary third party solutions also cause vendor lock-in. To address this, the Operations Support Systems for Java (OSS/J) API's introduce standard API's covering the range of telco needs including Activation, Inventory, IP Billing, Quality of Service, Trouble Ticket, and Service Quality Management.
Just like J2EE APIs brought consistency, lowered barriers to education and appserver adoption, lowered costs, and protection from lock-in to companies requiring application servers (compared to pre-2000 when there were 30 appserver vendors all with different programming models), the OSS/J API's are enabling similar benefits in the Telco space, essentially creating a component market place of domain specific middleware all implementing consistent and understood API's.
OSS/J APIs are developed through the JCP, and as such consist of a specs, Reference Implementations (RIs) and Technology Compatibility Kits (TCKs) for each of the three integration profiles that are or will be available:
- Tightly coupled integration with Java/JVT profile (Spec, RI, TCK)
- Loosely coupled integration with XML/JMS profile (Spec, RI, TCK)
- Cross operational boundaries integration with Web Services (Spec, RI, TCK)
The article quotes a strong benefit of "Using clearly-defined, open interfaces eases the pain of integration – less time, lower costs, and better quality – and it allows the service provider to have more control over the development process." It later quotes a Vodaphone executive explaining the needs “The business driver for adopting OSS/J was our need to connect more and more OSS at reasonable costs, enabling us to spend our budget for application development instead of on integration."
In related news, earlier in May the OSS/J initiative joined forces with Telemanagement Forum standards group (the largest Telco stanards group). "Sun is really throwing its weight behind the TMF as it realizes this combination provides OSS/J with exposure to a broader audience and improves OSS/J's chances of being accepted as the de facto OSS/business support systems standard." The ecosystem of OSS/J certified products has also been growing rapidly.
Consistent design for SOA
Now, if you look carefully, these concerns have to be addressed in any SOA deployment (outside of the Telco space), but are at a higher level than what the current WS-* specs address. They are more "application-level" than "infrastructure-level". This is typically where current SOA designs require a "Guru"... well, these days might be over soon :-). With such proven guidelines, designing consistent, manageable and maintainable services across the enterprise become much less error-prone and risky.