Inversion of Control
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.
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.