In the past few years there have been many discussions on the servers for enterprise applications and the overall trend has been that corporate containers have become easier and more lightweight. This trend has resulted, for example, in the transition from the heavy EJB2-container to relatively light frameworks like Spring or ones based on EJB3 specification. At the same time even the word ‘container’ gradually gave way to the term ‘framework’. However, they are still containers. Even after removing of many functions such as persistence and sending these functions outside the described platforms will remain the traditional IoC*-containers built with enterprise applications in mind. But we’ll talk about special containers designed for telecom applications. However, it is likely that all these thoughts are also applicable to other specialized application servers.
Telecommunication containers pose problems similar to those that actively discussed with respect to enterprise ones. But, beyond that, they also create special problems. The general situation is that the promises of convenience and efficiency of application development and support are not met and the complexity of such tools is still quite high.
To illustrate this idea we will consider three types of difficulties which any solution architect or application developer can face with one of the modern telecom application containers. The problems of the first type are related to the protocol abstraction service. The difficulties of the second category are imposed by the IoC nature of the application servers. And the third type of problems is related to the integration of the developed solution into operators’ OSS/BSS systems.
Protocol abstraction problems
Developers of telecom application platforms, as well as authors of the appropriate standards typically formulate requirements to their products according to the common ‘container’ philosophy i.e. concentrating on simplifying of application development by passing all the ‘secondary’ tasks such as threading, persistence, instantiation, failover etc. to the container and letting the developers to focus on application logic. Then features intended to be available to the application developer are packaged into the API based on high level service abstractions. This distinguishes the typical telecom applications server from any protocol stack which usually doesn’t restrict the access to the desired level of network primitives. Any SS7 stack available on the market represents a good example.
But development on top of protocol stacks is typically considered effort-consuming and demanding a very high level of network expertise. Both points usually correspond to the reality but the second one is not something specific for low-level development. I’ve never seen telecom application developer who did not understand the underlying network technology. And the experts preparing requirements typically have networks as their main area of expertise and usually they understand their domain not worse (and often better) than the developers of the container. From this perspective any attempt to simplify the network primitives by translating them into some more abstract and user-comprehensible API will be inefficient and will inevitably complicate the application development because popular applications changes constantly and as a result the set of features required from APIs also changes. Good example is Parlay/OSA specifications. All implementations I’ve seen contained holes drilled in the standard APIs to overcome the limitations of these API.
In addition to the problem described above, the ‘container’ model assumes that the mechanisms of providing of these ‘secondary’ features, such as external system connection pooling, fault tolerance strategy, multi-piring and other are built into the container code and virtually not accessible by applications. But the requirements to these mechanisms’ behavior can change dynamically for some applications and also can vary for some applications simultaneously deployed into the container.
At first glance to a lesser extent these problems are related to protocol-agnostic containers, for example, to these built on the basis of JAIN SLEE specification or similar. In such containers integration with network services is decoupled from the container and put into an isolated domain of resource adapters. But unlike the JCA and similar technologies in JAIN SLEE the usage of for RA is a major and not a secondary approach. However, the development of these adapters is a difficult and time consuming task and is usually implemented either by the container vendor or by its close technology partners. Therefore almost nothing is changed for application developers.
One possible work-around for the convergent containers can assume that two or more functionally similar adapters providing different levels of abstraction required by the developed application are deployed into the same container simultaneously. The problem then is that each adapter encapsulates the integration with the network subsystem and is usually identified separately on the network side. This strongly limits the applicability of this approach. There possible exist additional work-arounds specific for individual network technologies, but in general the development of applications is complicated so that for small ones which use a limited set of protocols (say one or two) for the network integration it becomes easier and cheaper to use protocol stack instead of application server despite the fact that this bring to the network an additional vertical application ‘silo’.
* IoC = Inversion of Control
** DI = Dependency Injection
Martin Fowler. Inversion of Control Containers and the Dependency Injection pattern