As the world moves forward, the industry expects its technologies to evolve and adapt to new challenges. With so many changes shaking things up inside and outside the telecom industry, standards have to consider a new landscape rich with opportunities instead of walling themselves up with obsolete methodologies and developing techniques. Both REST and JAIN SLEE promise a standardized architecture with ease of use and reduced costs, but their offerings are completely different one from another.
In this app-filled socially-connected world of ours, APIs have become the most important tools used in the implementation of communications services. Now, all major social media or web service providers like Google, Facebook, Twitter or Salesforce offer a REST-based API to integrate with their services. As a matter of fact, REST has become the de facto standard for APIs. The telecom industry, for its part, has followed this trend with the OneAPI, a broad set of REST APIs that give access to many resources within the telco environment. The OneAPI empowers the majority of web and mobile app developers to build and integrate their services into the telecom environment. It can be integrated the same way as other services do, like, for example, Google Maps.
Reliable Standards for Communication Services
At its inception, JAIN SLEE, a specification first introduced in 2004 and JAIN SLEE specification 1.1 released four years later by Sun Microsystems and OpenCloud, promised reliability, standardization, portability and interoperability, as well as reduced costs and reduced complexity. Years later, Sun was acquired by Oracle while OpenCloud became part of MetaSwitch and is now called Rhino. Their specification, more than 10 years after its release, has yet to receive what would be its first update, something that certainly doesn’t reflect the ever-changing nature of the telecom industry.
A Standard Environment Modern Telecom Services
On the other side, JAIN SLEE focuses solely on the integration of telecommunication infrastructure, leaving out the integration into the data infrastructure of the carrier as well as the integration into external web services or even the integration into the infrastructure of the end customer. In addition, JAIN SLEE concentrates only on the backend, leaving the frontend completely out. WebRTC and other new technologies are not considered in the JAIN SLEE specification and there is, for example, no way to integrate WebRTC easily, as backend and frontend components would be needed.
Build an Industry of Service Enablers
If we divide the costs into development and maintenance, JAIN SLEE turns out to be an expensive option. Firstly, because JAVA development per se is expensive and, logically, as JAVA developers specialized in JAIN SLEE are harder to find, they are even more expensive to hire. Most of the time, even if theoretically you could look for outsourced providers to work on your JAIN SLEE platform, the reality is that most of the tasks can only be done by your original vendor, as strict knowledge of the platform specifications and restrictions is needed in order to develop or make changes. With thousands and thousands of lines of JAVA code, it’s easily imaginable that maintaining and developing JAIN SLEE turns out to be expensive.
Modern development must be done within a web browser. Developers need languages and technologies they can use for other projects in their careers and not to be limited into a niche market by a complex development environment that needs weeks of work even to be completely set up.