IoC concept is the basis of the functionality of any container. We won’t try to define exactly what IoC is and will understand this property as the ability of the container to take control of any application instance and affect it. The most common type of IoC is Dependency Injection (DI). The main purpose of an IoC introduction is to delegate to a container all the secondary services which are common for all (or for many) applications and leave for developers only the application logic. In that sense the very concept of IoC is synonymous with the containers.
The main disadvantage of the IoC concept is the separation of logic processing into two domains – the container and the application instance (in the case of JAIN SLEE there is also a third domain – the resource adapters – but for our purpose RA may be considered as a part of the container domain). Container interfaces hiding access to resources from applications significantly complicate the application development.
Another problem arises from the same cause along the incremental introduction of new services or service features. When adding new services that can be chained together with those already live within a single call it is necessary to transfer control from one application to another.
In the computational budget of average application which is using modern human readable protocol the parsing takes the main part. On another hand the communications between previously developed applications and a container and between applications are limited to their APIs and usually the problem of service chaining is solved on the protocol level (e.g. IN messages in SCIM or SIP in DFC). In other words, typically there is a special orchestrating application relaying all the protocol messages between the resource adapters and the chained applications. And even if container is not involved, usually applications are chained over the network protocols. As a result the average time of network request processing grows by orders of magnitude.

OSS/BSS integration

Without claiming to possess an exhaustive knowledge of all the deployed platforms for telecommunications applications, I note that I have never met one, which would be integrated into the operator’s OSS. Any solution always exposes a separate interface and a separate management console. Not to say that the presented solutions do not support SNMP or other interface for integration, but usually these interfaces are not involved and the solution is managed separately, which increases the TCO and complicates the organizational structure of the operator.
The fact is that while all proposed platforms offers a very flexible set of capabilities for integration of specific application logic with the network infrastructure, they usually do not contain adequate means for forming the control subsystem of the solution usually comprising many components and its integration into the operator’s OSS. The reason is that many components of the management subsystem such as congestion control, load balancing, monitoring, and others are usually implemented on the container side and do not allow any control from the application. Applications implementing specific logic cannot obtain the necessary API which would allow it to aggregate and to exhibit the OSS interfaces which would be adequate to the specific logic of the applications.
At the same time it should be noted that many umbrella OSS systems themselves represent similar containers with the specialized OSS applications inside. But separation of applications implementing service specific logic and OSS applications and a lack of direct integration between these two types of applications do not let to build a complete solution that is fully integrated into the operator’s OSS.

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’.

There is an excellent, albeit slightly outdated article dedicated to the key ideas put in the foundation of the JAIN SLEE specification. This article contains an interesting table that with the technical side-by-side comparison of enterprise and telecommunication applications. We will try here to expand this comparison by considering other aspects including solution and application life-cycle management, external integration environment, business and organizational aspects etc.

The interaction of the system with the user

Telecommunication systems require, as a rule, that their users interact with each other, not with the system itself, as in the case of enterprise solutions. From this perspective, the more transparently towards the subscriber system behaves, the better. In those cases where telecommunication applications interact directly with the subscribers, they use more often the same interfaces as human subscribers do – the voice and the messages (e.g. IVR) because up to the last time these interfaces were in fact the only available for the most part of subscribers. This greatly limits the total length of dialogue between the user and the system, because the excessive communication with the system irritates subscribers.

Interaction with other systems

Typical corporate application server interacts with a limited and pretty fixed set of systems (databases, etc.). Server hosting telecommunication applications can interact simultaneously with multiple external systems and fulfil different roles within the various network technologies. The specialists of the customer responsible for the solution requirements typically understand the network technologies the developed solution will be integrated with much better than the developers of the solution. Usually technical expert working on the operator’s side are network engineers and are not software experts.

The financial nature of intelligent service platforms

In contrast to the corporate application servers designed for IT needs in mind, telecom application servers (like the rest of the operator’s network infrastructure) represent the main production facilities of the operator. If we compare the operator with the confectionary, the enterprise application server will preserve its functions, but the telecommunications platforms will represent ovens where cakes are baked. We leave the reader to assess the business impact of this difference.

This is an Ubik Asynchronous Application Framework project blog. It is (mostly disordered) collection of ideas, thoughts and notes related to the project. I’m writing these notes mostly for myself, so sometime they could be not very well polished, to put it mildly.

The Ubik is a fun/research project aimed at creation of the sandbox for testing various ideas about asynchronous event-based system.

The most part of my experience lies in the filed of telecommunication intelligent service platform, including IN, NGIN, IMS/SIP AS, Parlay/OSA, SDP etc. So I will use this class of platforms and applications as a main source of application examples and challenges.