Wednesday, 30 July 2008

Telco APIs

The communications industry (telecommunications and internet) must have the largest number of standards specifications - from the layering of the network model, to individual protocols inside each layer. Even the same standard can be defined by more than one standard bodies - ITU-T, ESTI, ANSI, etc. The standards are very necessary in the communications industry. Afterall, communications are all about being able to interwork/interact with each other. So a common language is needed.

Traditionally, the standards stayed at the protocol level - i.e. to ensure that different systems/subsystems can communicate with each other. Typical exmaples are SS7 (and SS7 based protocols), VoIP protocols (SIP, H.323). More recently, as the industry matures, standard programming APIs have become prevalent, e.g. Parlay/X, OSS/J, JAIN APIs. These APIs enables inter-operability among different systems and system vendors. It also cuts down the effort of individual software vendors because much of the specification and documentation have already been done by the community/expert groups. Leveraging these standard APIs increases the software vendors' productivity and ensures smoother integration with other systems.

I have been involved in service development using legacy Service Creation Environment (SCE), which provides proprietory drag-and-drop type of 'programming' environment (think Visio). The legacy SCE boasts that no programming experience is needed and only drawing of the flow diagram is required. On the surface, this seems an attractive paradigm (apart from lack of documentation - zero documentation really), however, once you need to go beyond the surface, it's nothing but pure frustration. When you are stuck, you have to ask the vendor to provide another service building block (SBB) in order to put it onto the flow diagram. On the contrary, in a JAIN SLEE environment, a developer can write new SBBs using Java following the JAIN APIs and architecture. This gives the developer power and flexibility over the legacy approach.

No comments: