When I recently joined the Innovation Department here at ECT, I did research on many topics relating to the telecommunications industry. While diving into the topic of Telephony Application Servers and Service Delivery Platforms in particular, I learned that at ECT, we use JavaScript libraries, XML and HTML5 as an alternative to the JAIN Service Logic Execution Environment (JAIN SLEE, or JSLEE). As you might know, JAIN SLEE solution vendors assert that JAIN SLEE is the “only” way to go.
Therefore, I was puzzled by the following question:
Why did we decide to use JavaScript, XML and HTML5 for the programming of services on our application server instead of JAIN SLEE?
By asking internally, I got to know the main reason behind this decision was that at ECT we believe JAIN SLEE ignores the IT industry trend to move to higher level languages. Languages like JavaScript and HTML5 are closer to web development and are easier to use and learn. This sounds quite reasonable to me, given the fact that, as far as my understanding goes, JAIN SLEE is an abstract specification for writing telecommunication services in pure JAVA, which in fact is a more complicated programming language familiar to far fewer people than say JavaScript.
I was interested in getting the bigger picture, so I looked closely into the claims made by JAIN SLEE vendors and found some interesting (and puzzling) things that I would like to share with you:
Off-the-shelf services that are network agnostic
First, I found out that vendors of application servers based on JAIN SLEE claim that all their services run instantly on any network. However, I have to admit that I could not fully wrap my head around this one. To the best of my knowledge, telco networks are inherently highly proprietary and are changing more and more rapidly. Therefore, wouldn’t you agree with me that this makes it hard to believe that services programmed in JAIN SLEE would work in any network instantly and without adaptation? Does that sound right to you?.
Carriers can break free of vendor lock-in
Quite often, it is claimed that with a JAIN SLEE platform carriers can save money by buying new services and programming capacity on the open market, and in addition, they can ask anyone when it is necessary to make changes once the service has been programmed.
This is clear as mud, right? I do not think it is that easy. To the best of my knowledge — and almost every software engineer I have talked to agreed — JAIN SLEE services are based on a really complicated language: JAVA. It is hard to understand how a sophisticated service programmed in JAIN SLEE would be easily and practically maintainable by anyone other than the original author.
Say you or your integrator program a VPBX service in JAIN SLEE, do you think you will save money by asking someone else to maintain and further develop this service? You’re asking a third-party company to change a service they did not write. Without saying this is always the case, I certainly think that this would be neither quicker nor less expensive than going to the original vendor. Why is that? Simply because this third party will require a lot of effort to first understand the service as well as to make the required changes.
So, doesn’t this mean that you as a carrier would have to heavily depend on the company that programmed your services for maintenance, development of new features and bug fixing?
Open source
I also found that the vendors claim there is nothing proprietary in their JAIN SLEE solutions. From my research, this is not exactly what I would conclude. It is my understanding that various vendors have in fact added their own proprietary extensions or JAVA libraries. They kind of have to do this in order to keep up with the many new developments in the telecommunications industry, because the JAIN SLEE standard is some 10 years old and thus far behind today’s telco reality. Correct me if I am wrong, but as I see it, once you have your services programmed in a specific vendor’s JAIN SLEE variant with all its own proprietary extensions, you won’t be able to simply add or change services via different companies unless they support this particular proprietary variant.
As far as I could see, there are also various development tools from application server vendors using JAIN SLEE variants. While they might after all be open source, they are in the end still proprietary tools. You are always dependent on the vendor for the maintenance and continued development of these tools, aren’t you?
So, after all, are these claims the absolute truth, half-truths or simply sales hype? I would love to hear your opinion and discuss this further with you. For now, I am continuing to think this through. Keep your eyes open as I expect to be writing about this topic again in the near future