Catching up with Java Use in Telco Companies (OSS/J)

Posted by Floyd Marinescu on Jun 21, 2006

Community

Java,

SOA

Topics

JCP Standards ,

EAI

Tags

OSS/J ,

Telco

Java is probably more widely used in the Telco industry than any other platform, but this fact is not very widely known. Many Java developers may have heard about OSS/J in passing but many don't know the full signficance of what it is or the large impact that Java is having in the Telco space.   A new article explaining the need and impact OSS/J is having on the Telco space appeared in the European Communications yesterday and is worth a read.

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 focus of OSS/J standardization is on the APIs and interaction models rather than either management communications protocols or data models. The first two integration profiles above are all tightly coupled to existing Java EE API's such as EJB and JMS, which also makes the Java EE itself more strategicly important for Telcos. 

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.

1. Back to top

   Consistent design for SOA

   Jun 22, 2006 10:28 AM by Eric Dillon

   Another interesting point is that while OSS/J provides Service Contract templates (for Order Mgt, Inventory, etc...), they are all based on the same guidelines, patterns and naming conventions. By doing so, OSS/J ensures that all APIs are consistent and can inter-operate nicely (in a BPM environment e.g.), but as a result, OSS/J actually delivers a complete cookbook for SOA through these guidelines: How do you address large datasets in a loosely coupled environment? How do you deal with best-effort bulk operations? How do you deal with atomic bulk operations? etc...
   
   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.

   Reply

• Older >