Enterprise Service Bus in Telecom

It always puzzles me on how an operator should approach integration of IT applications and communication services that is being offered. So far I was under the impression that it requires 3 different types of enterprise service bus (ESB) or communication service bus in an operator’s data center.

a. Real time voice service broker

b. VAS service broker & bus

c. Enterprise service bus for BSS & OSS applications

I think there would one more addition to the above list.

d. Smart machine’s data integration bus – messaging & integration bus infrastructure to connect with the smart metering and other smart end devices and leverage the existing BSS/OSS infrastructure to offer value added service to the smart grid or any other M2M vertical service provider.

I strongly believe that as long as operator has a strong governance model to manage messaging/integration infrastructure (having different core requirement), it is better to keep them separated.

Cloud Service Broker Pattern

One possible cloud service broker pattern from Jamcracker. Couple of additional items could be; a workflow engine as well as integration layer that integrates data as well as events/messages from different entities.

Telecom IT Integration Patterns

I see there are 2 starting points for building IT integration platform in a communication service provider environment.

1. Start with the central business process engine that implements the business processes by taking eTOM as the basis and customize according to the market situation. I see that this approach is mostly taken by the ESB vendors who wants to control the IT environment through their BPM and ESB products.
2. Start with the unified product catalogue and build the business processes, data model and middleware strategy around that. I see that this approach would be taken by mostly the NEP who wants to expose capabilities of their BSS/SDP offering and to create the differentiation for their products as well as for the operators. Poduct & service assembly (PSA) and Cloud service broker catalyst (CSB) from TMForum would definitely help in providing a reference for NEP adopting this approach. Below diagram depict one such approach from Comarch.   

Service Exposure Pattern

Ref: NGNI paper on IT based SDP – evolution from mobile to IMS

Typical pattern for exposing the service capabilities and managing the same while exposing to developers. Shall do an analysis on what it takes to use programmableweb.com for service discovery and develop policy decision point capability & SEE in the earlier mentioned networked SDP.

Cloud Communication Service Provider Blueprint

http://www.parallels.com/spp/blueprint/

Interesting perspective on what is a typical blueprint of a communication-as-a-service cloud provider. I guess service integration or the composition of the service would play a major role in enabling the underlying applications. If this is coupled with service exposure platforms (which might use ParlayX/REST/WS API), then operator would have most suitable infrastructure for offering any type of cloud services (whether it is communication or computing or IT applications).

SOA Enabled OSS Pattern

With telecom operators moving towards a “life style” providers, the operation support system of the operator will have to start taking care of the complexities in the network elements involved in the delivery of the service for a consumer. In this aspect enabling existing OSS towards SOA based architecture is really important for the operator to embrace the agility required in service fulfillment requirements of a consumer. In order to ahieve this, integration infrastructure (consisting of adaptors, messaging infrastructure) and the business rule engine will play a critical role. On top of this infrastructure, if the TM Forum’s eTOM processes, SID and OSS/J interfaces are used as reference (along with a system integrators best practices), then transforming an existing OSS could be relatively risk free.

Telecom IT SOA Patterns

http://msdn.microsoft.com/en-us/library/dd129906.aspx – This link contains an excellent collection of real life patterns that are used in a typical integration scenario. These patterns are equally applicable in an telco’s IT integration scenario. Following is an attempt to map these patterns to telco business. 

Business process work-flow design pattern:

• Process driven development – utilizing the eTOM (for business operation) and ITIL (for infrastructure management) to design processes
• Separation of contract and implementation – using SID and different contracts like OSSJ
• Composite applications – utilizing SCA to consume the capabilities exposed by different producers and contracts of these capabilities exposed through a service registry
• Transparent process migration & resilience – moving processes among different machines when there is a disconnect. This would call for persisting the process data and the states and also development of distributed workflow infrastructure. This pattern becomes all the more important while planning for the business continuity and to serve large number of telco users
• Conversational processes – allowing a process to maintain its state/behavior across multiple calls from one or more callers. This is an important consideration for the orchestration which might happen at multiple levels. At the network service level (where real-time voice a main consideration), the orchestration would be done through SCIM or a service broker; at the value added and data bearer level it might happen through a traditional ESB or a telecom specific message broker; at the business process level it might happen through ESB o Stateful interceptors – correlating multiple operations – this is an emerging pattern wherein complex event processors (CEPs) would get included in deciding the marketing campaign in the real-time by understanding user’s behavior or initiation of a fraud control process based on certain event patterns. Another point to ponder is; whether in the service registry invoke related capability based on the actual state of the service provider
• Process-status & business activity monitoring – since many of the teleco’s IT infra is based on Java, it would have to consider JMX along with SNMP for the activity monitoring of the systems and this will have to get integrated with the automated ITIL processes that could be developed in a workflow system. For business monitoring, an event fabric will have to considered that gets integrated business dashboard, analytics and CEP. This area calls for vendors who have prior experience in applying their own best practices & patterns to achieve intended goal.

There are other patterns which can directly be applied to a telco environment. There is an interesting pattern to address consumption of the cloud based service. Shall update the same soon and would try to map the with the PSA initiative of TMForum.

Heartbeat between Java AS

When looked at the Mobicent loadbalancer code, realized that they have a neat implementation of heartbeat between Java application servers through RMI (remote method invocation). RMI server implemented in the Loadbalancer server waits for clients to call the ping method to maintain the AS nodes that are active. Code snippet in the below link shows how the heartbeat ping method is called by the RMI client. Very good reference for heartbeat implementation.

http://mobicents.googlecode.com/svn-history/r15682/trunk/tools/sip-balancer/jar/src/main/java/org/mobicents/tools/sip/balancer/test/BlackholeAppServer.java

Basic Event Handling Pattern

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.7777&rep=rep1&type=pdf

One of the old paper talking about the basic event handler design patterns – reactor and acceptor. I presume ASX (Adaptive Service Executive Framework) is evolved as ACE. Realized that ACE is well maintained communications best practices library and is used by most of the big NEPs in their products. Exploring similarities between JACE (Java implementation of ACE) and CAFE (SailFin AS based Converged Application Framework) to create reusable lightweight framework for a SLEE.