White Paper

The Role of ESB in integrating

B/OSS Platforms

Prepared by: Infotech Enterprises

Ltd.
Date Created: 18th Jul 2012

The Role of ESB in integrating B/OSS Platforms

Confidentiality Statement

Confidential

Page 2 of 21

The Role of ESB in integrating B/OSS Platforms

Document Information
Document Name:
Prepared By:

The Role of ESB in integration OSS Platforms

Infotech Enterprises Ltd

Title:

Document Version No:

Document Version
Date:

Reviewed By:

0.1
18-Jul-2012

Review Date:

Glossary of Terms

Sl.
No.

Abbreviation

Details

1.

CSR

Contact Centre Representatives

2.

ESB

Enterprise Service Bus

3.

EAI

Enterprise Application Integration

4.

OSS

Operational Support Systems

5.

BSS

Business Support Systems

6.

SOA

Service Oriented Architecture

7.

MOM

Message Oriented Middleware

8.

ETL

Extract Transform and Load

9.

SLA

Service Level Agreement

10.

JCA

Java Connector Architecture

11.

JMX

Java Management Extensions

12.

XML

Extensible Mark-up Language

Confidential

Page 3 of 21

The Role of ESB in integrating B/OSS Platforms

Confidential

Page 4 of 21

The Role of ESB in integrating B/OSS Platforms

Abstract
This Whitepaper discusses the use of an Enterprise Service Bus (ESB) in Telecommunication
domain
and
addresses
the
key
challenges
posed
by
traditional
integration
products/methodologies. However, this Whitepaper does not cover an end-to-end ESB
architecture or best ESB's to choose

Confidential

Page 5 of 21

The Role of ESB in integrating B/OSS Platforms

TABLE OF CONTENTS
INTRODUCTION........................................................................................................ 6
BUSINESS CASE........................................................................................................ 7
LIMITATIONS OF TRADITIONAL EAIS...........................................................................8
INTRODUCTION TO ESB.............................................................................................9
ESB IN ACTION IN TELECOM B/OSS PLATFORMS........................................................10
BENEFITS OF ESB................................................................................................... 12
REFERENTIAL ARCHITECTURE USING ESB.................................................................13
CONCLUSION.......................................................................................................... 16
REFERENCES.......................................................................................................... 16
ACKNOWLEDGEMENT.............................................................................................. 16

Confidential

Page 6 of 21

The Role of ESB in integrating B/OSS Platforms

Back Ground

Communication service providers (CSPs) are challenged by the need to grow

revenue, improve time to market, and improve operational efficiency while
reducing cost. CSPs must innovate and be agile to winand optimized
operations support systems and business support systems (OSS/BSS) are vital
to
future
success.
The
OSS/BSS integration solution
for
telecommunications can help you drive costs out of your operations and
provide an agile environment for new and innovative revenue-producing
services. In the last two decades, the IT Industry has seen the life cycle
of integration starting from traditional MOMs and then graduating to
vendor driven EAIs along with various other Enterprise integration
technologies. The latest and one of the most promising architecture to have
emerged during this period is Enterprise Service Bus. An ESB oriented solution
addresses lots of key challenges in the integration space and is out to
establish itself as a key trend.

Introduction
The ESB approach to integration can provide the underlying integrated solution as a service
based, loosely coupled, highly integrated and widely available network that extends beyond the
boundaries of a traditional hub and spoke EAI broker. An ESB has the following characteristics
that we would touch based upon in the later sections of the Whitepaper.

Highly Adaptable
Distributed
Ability to selectively deploy Integration components
Secure and Reliable
Ability to orchestrate processes

Monitoring
The Telecommunication Industry forms a business case for using Enterprise Service Bus as an EAI
broker particularly for an OSS/BSS solution. This white paper focuses on how ESB addresses
the key challenges of integration in Telecommunication domain.

Confidential

Page 7 of 21

The Role of ESB in integrating B/OSS Platforms

Confidential

Page 8 of 21

The Role of ESB in integrating B/OSS Platforms

Business Case
In a typical OSS/BSS ecosystem, there are various disparate systems involved, from customer
Servicing system to the Provisioning, Billing and Mediation systems. In addition, this niche Of
OSS/BSS environment consists of numerous third-party systems in order to complete the OSS/BSS
backbone of the Enterprise.
These systems are technically and functionally variant and connected using a single or multiple
integration methodology/products. All these various pieces are wired together and this
accomplishes the OSS/BSS environment.
CSRs obtain the data from the customers on a regular basis and populate the database with the
customer details. The CRM System communicates with various other systems like Billing, Order
Management and Provisioning to facilitate the order processing. Bearing in mind that all these
applications/systems are different, they communicate in a fashion that works best for them
and not necessarily in a way that is best for maintaining the elasticity of the architecture
Framework. The following section lists the problems that arise while implementing OSS/BSS
Telecommunication architecture with traditional integration methodologies.

Confidential

Page 9 of 21

The Role of ESB in integrating B/OSS Platforms

Confidential

Page 10 of 21

The Role of ESB in integrating B/OSS Platforms

Limitations of Traditional EAIs

Integration
Approach

In a Traditional approach to EAI (i.e. broker models), a central integration

engine, called the broker, resides in the middle of the network, and
provides all message transformation, routing, and any other interapplication functionality. All communication between applications must
flow through the hub, allowing the hub to maintain data concurrency for
the entire network.
Typically, implementations of the broker model also provide monitoring and
auditing tools that allow users to access information about the flow of
messages through their systems, as well as tools to speed up the
complicated task of configuring mapping and routing between large
numbers of systems and applications.
The connectivity between the CRM system and other communicating
applications is usually established using traditional EAI broker/MOM.
Like any other architecture model that uses a central engine , is that the
broker can become a single point of failure for the network. Since the
broker is responsible for all concurrency between application's data sets
and states, all messages between applicants must pass through it.
Under heavy load, the broker can become a bottleneck for messages. A
single central destination for all messages also makes it difficult to use the
broker model successfully across large geographical distances.
Lastly, implementations of the broker model are often heavyweight,
proprietary products, aimed at supporting a specific vendor's subset of
technology. This can present problems if your integration scenario involves
products from several vendors, internally developed systems, or legacy
products that are no longer supported by the vendor.

Proprietary
development
interfaces

All the traditional EAI products have their own proprietary development
interfaces and in the event of migration from one product to another, it can
be a nightmare for the Enterprise. Even though a work around (plugging
in standard components) is always available, it cannot resolve all the
connectivity problems but instead it gives rise to mainly three types
of issues:

1. The non-standard patch and play weakens the communication

Confidential

Page 11 of 21

The Role of ESB in integrating B/OSS Platforms

architecture and introduces new points of failure.

2. Basic inter component communication requirements are compromised.

3. In the whole exercise, the solution architecture moves further away

from
Standards.

Even if the new breed of EAI brokers use SOA based in the
communication architecture, they are normally inward focussed. Let us
imagine a scenario in which web services are used to pick up the
data from a customer-porting database. These web services would
have been developed using a specific vendor product. In case the
organization wants to migrate to a different application server, web
services cannot be simply plugged and played and would need to be rewritten up to a good extent.
Tightly Coupled

Business rules and integration logic is tightly coupled with software

components and any change in business environment will require
overhauling and rebuilding application. OSS/BSS system is not flexible to
handle frequently changing business requirements like introduction to new
policies and service offerings.

Introduction to ESB

Confidential

Page 12 of 21

The Role of ESB in integrating B/OSS Platforms

E n te r p ris e S e rv ic e B u s

E n t e r p r is e s e r v ic e b u s is w id e ly
d is t r ib u t e d , h ig h ly a v a ila b le , s e r v ic e
o r ie n t e d c o m m u n ic a t io n b a c k b o n e t h a t
p r o v id e s t h e s t a n d a r d s b a s e d in t e g r a t io n
a c r o s s t h e e n t e r p r is e .
A c c o r d in g t o G a r t n e r A n E n t e r p r is e
S e r v ic e B u s ( E S B ) is a n e w a r c h it e c t u r e
t h a t e x p lo it s W e b s e r v ic e s , m e s s a g in g
m id d le w a r e , in t e llig e n t r o u t in g , a n d
t r a n s fo r m a t io n . E S B s a c t a s a
lig h t w e ig h t , u b iq u it o u s in t e g r a t io n
b a c k b o n e t h r o u g h w h ic h s o ft w a r e
s e r v ic e s a n d a p p lic a t io n c o m p o n e n t s
fl o w .
T h e E n t e r p r is e s e r v ic e b u s ( E S B )
a d d r e s s e s t h e a b o v e -m e n t io n e d
c h a lle n g e s b y p r o v id in g t h e d is t r ib u t e d
p r o c e s s in g , s t a n d a r d -b a s e d in t e g r a t io n ,
a n d E n t e r p r is e -le v e l b a c k b o n e r e q u ir e d
b y t h e E n t e r p r is e .

ESB in Action in Telecom B/OSS Platforms

Having identified a case for standard based integration required between disparate
systems as depicted above, in this section we would identify why and how an ESB can be the
right fit to the key challenges in the Telecom B/OSS Platforms.
In the Telecommunication Industry, the Enterprise Service Bus (ESB) provides a new way to build
and deploy Enterprise service-oriented architectures (SOA). The true value of the ESB is to
provide suitable services within SLAs managing the service provided to operate and integrate
in a heterogeneous technology environment.
The diagram below depicts the components of ESB that can be used to form the integration
backbone in Telecommunication B/OSS IT Platforms.

Confidential

Page 13 of 21

The Role of ESB in integrating B/OSS Platforms

The following sections would highlight on how the drawbacks of using a traditional EAI solution
are addressed and translated into opportunity using bus architecture in the Telecommunication
Industry

Basic Connectivity

Confidential

Page 14 of 21

The Role of ESB in integrating B/OSS Platforms

The core of ESB is highly scalable Enterprise messaging backbone that transports the
data as messages in a secure and reliable fashion. ESB uses standard web services, JCA or
standard based JMS to provide connectivity to the plugging applications. ESB uses abstract
service endpoints to assemble services to form the process. In addition, it fully supports
integration of services that are themselves services or that connect to other services using
service endpoints.

The component that makes an ESB highly distributed is ESB container. A ESB Container is capable
of hosting multiple different services in a container environment.

In the Telecommunication domain, systems like self-service user interfaces, contact centres
etc., can use web services to invoke various services like customer management, credit card
authorisation etc., offered by the core ESB backbone. These services themselves invoke the
appropriate services using the abstract service end points to do the desired job and come back
with the reply (if desired and designed).

This is important to note that services offered by ESB in can be of both synchronous and
asynchronous nature. For example, credit card validation of a customer is asynchronous
service but the customer order activation can be an asynchronous service. For those
applications/systems that do not fall into the category of communicating through web-services,
standard JMS and J2EE connectors are used.

A good example could be CRM systems and Billing systems. There are products in the Enterprise
market that can provide the services required by CRM and Billing systems. An ESB way for them
to interact is using abstract service end points. If it is developed using the EJB server
architecture, it can get on to the bus using the MDB (Message driven bean). If the
application is developed in java, it can use JMS to connect to ESB. The .Net application can get
connected using a .NET client. This .NET client can be plugged into the bus using the MOM
internal communication protocol. Most of the ESBs today use JCA that supports both real time
and batch connectivity. ESB provides ESB Container architecture that allows packaged or
legacy applications to be plugged into the ESB through Service end points. Hence, by
adopting the Industry wide standard of using JCA, XML and Web services and other best
practices, the shortcoming of using proprietary development interfaces and protocols is
nowhere in the picture any more in ESB based solution architecture. to this, the
architecture gets inclined towards a standards based intelligent communication backbone.

Confidential

Page 15 of 21

The Role of ESB in integrating B/OSS Platforms

Service Oriented Architecture

SOA is an architectural methodology and ESB enables the same. ESB uses registry services in
which the information about the service end points is stored and configured. ESB
performs routing, transformation and validation of XML inputs from these services. As
defined earlier, once the Enterprise Service Bus is defined and created, integration of further
applications merely involves plugging new services onto this backbone or the re-use of
existing services.

In short, service-oriented interactions leverage underlying messaging and event communication

models. In the Telecommunication Industry, most of the requests (new customer subscription or
service cancellation etc.) from contact centres can be treated as requests for services. Each of
the services is linked to an individual set of services provided by the connecting interface
(for example service for security, service for logging, service for auditing etc.). Hence, the
whole Enterprise backbone is predominantly built upon the service concept. Futuristically
speaking, if a new business requirement evolves, the service for it can be either reused or
developed as desired and plugged into the ESB backbone with no impact on the ESB backbone.

Benefits of ESB
Standardization
One of the primary advantages of an ESB is that it gives you a standardized platform for
integration. When everyone is using the same tools you can develop enterprise-wide frameworks,
patterns and best practices for building re-usable services. Without a unifying platform, you get a
divergence of integration methods which leads to inconsistency and higher cost of management
and change. So an ESB platform helps with design-time governance. Note that this is not the
same as standardization in the sense of using web-services standards. The important thing is that
you use the ESB to support your own enterprise standards. These may be based on external
standards but that may be of secondary importance.

Loose Coupling
The bus architecture of an ESB encourages you toward a loosely coupled architecture.

Physically decoupled by making use of message passing mechanisms

(e.g. JMS) versus direct network connections (e.g.HTTP).
Semantically decoupled by use of message transformation so that
services are exposed in a system-neutral format which reduces
application lock-in and reduces the cost of change.

Confidential

Page 16 of 21

The Role of ESB in integrating B/OSS Platforms

Scalability and Reliability

Physical loose-coupling provides scalability advantages such as high-availability, fault-tolerance
and load balancing. The messaging layer in the ESB directs messages between service endpoints
to the appropriate instance of the endpoint. For example, in the event of a service provider
failure, messages will be redirected to a backup provider thus supporting high availability. In the
case of load balancing, messages are distributed between redundant providers (or consumers) to
handle high volumes of message traffic. You could say that physical loose-coupling supports
change at the micro level where short term changes in the system topology can be
compensated for via real-time message redirection.

Routing and mediation

Message routing supports scalability and fault tolerance. An ESB can also be used to support
business-level routing and mediation. For example content-based routing allows services to be
invoked based on the content of a service request. A business example would be routing of a
customer enquiry to the branch where that customer account is located. A technical example
would be the routing of a service request based on the version of the service being invoked.

Complex message exchange patterns

Traditional HTTP-based services support only one-to-one request-reply MEPs. An ESB supports
more complex MEPs such as asynchronous one-way messaging and to multiple subscribers using
topic-based messaging. Asynchronous publish and subscribe mechanisms support new ways of
intermediating service consumers and subscribers such as auditing, service monitoring which
are extremely useful for runtime management and governance of your services. Beyond mere
governance, higher level business functions such as complex event processing (CEP)
and business activity monitoring (BAM) are supported by this ability to listen in to service traffic
on the ESB.

Referential Architecture Using ESB

Below is the general referential architecture for integrating different OSS systems, the
architecture consists of components like In Adapters, Out Adapters, Transformers, Web Services,
queues and uses a ESB tool.

Confidential

Page 17 of 21

The Role of ESB in integrating B/OSS Platforms

Business Process Management (BPM) Layer:

It is used to define automated business processes.BPM systems can interact with the external
systems through its off-the-shelf or custom developed connectors. There are various players
offering BPM tools like IBM, BEA, Vitria, and Jboss. Most of the BPM tools deploy the business
processes on a J2EE application server as enterprise java beans (EJB) and the whole application is
assembled into an EAR. So these business processes have access to all the J2EE server features
like security, transaction, JNDI, remote connectivity etc.

ApplicationQueue:
The business processes defined in BPM can be invoked by sending a message in the Application
Queue. The application queue is deployed as JMS queue on application server in order to provide
asynchronous communication.

Connector:
Connector consists of In Adapter, Out Adapter, Web Service, Transformer and a connector specific
Queue. Connector can be invoked either by placing the request in queue or by directly calling the
web service. Connector is the only way through which the BPM layer can interact with the
external system.

Confidential

Page 18 of 21

The Role of ESB in integrating B/OSS Platforms

Connector Queue:
The entire asynchronous request that needs to be handled by Out Adapter need to be placed in
the Connector Queue. Each connector has its own queue that is deployed as JMS queue on
application server.

In Adapter:
In Adapter is used to place a request in application queue that will invoke a workflow of BPM
depending on the request type. For example, if account information has been updated in CRM
system by CSR, it should be synchronized with the billing system. In order to accomplish the CRM
In Adaptor will place an update account request in application queue.

Out Adapter:
Out Adapter is used to process the requests that are placed in connector queue. Consider the
same example the CRM In Adaptor will place an update account request in application queue.
Based on the message type this request will go to the Billing queue. And from there Out Adapter
will read the request will call the web service to create an Account in the Billing System.

Transformer:
Transformer is used to convert the object of Third party system into application specific object
and vice versa. It has only the transformation logic and no business logic. It should be able to
handle following type of transformations:

Java Object to Java Object

Java to XML or vice-versa
XML to XML

Web service Interface:

The functionality of the external systems can be invoked through the web service interface. The
Web Service interface will accept the application specific parameters and transform them to
external system specific parameters and will then call the functionality of the external system.
Similarly, the result will be transformed and returned.
Considering the example of account creation, a user will access the customer care portal to
submit a request for Account creation. The Account Creation request will be placed in the
ApplicationQueue of BPM. BPM will initiate a business process defined for it. It will then place a
creation Request in all the required connector queues like billing, CRM queue. The Out Adapter of
each connector of the respective external system will process the request placed in the connector
queue and will call the web service to create an Account after appropriate transformation. The
Response of the web service will again place in the application queue and execution of the BPM
process will resume.

Confidential

Page 19 of 21

The Role of ESB in integrating B/OSS Platforms

The proposed enterprise architecture offers number of advantages over the traditional OSS/BSS
architectures:

Whenever a new API is exposed or an existing API is changed by the

third party system, only the connector logic needs to be changed and
nothing else.
All the systems are loosely coupled. Whenever a new third party system
or service is introduced into the architecture, only a new connector
needs to be developed and appropriate changes need to be made in
BPM. No other system or its connector gets impacted.
There is a clear separation between business rules and integration logic.
Business Rules are implemented through business process defined in
BPM and integration is achieved through the connectors.
External system can expose its API through various interfaces like EJB,
CORBA, Web service, JNI, C++. But with use of connector based
architecture all the functionalities of external systems are exposed
through the web services which make the interface to all external
systems uniform.
Transactions are managed by BPM layer. If a same business process
requires interaction with multiple systems then this is done in a single
transaction. If due to some reason operation fails for one of the system,
the BPM can rollback operation/transactions in other systems.
Due to the use of BPM, we can define a business process that can be
used to define both the manual and automated activities.

Conclusion
ESB offers a powerful technology omitting out the proprietary development interface, without
having the need to retrain the staff and providing the need based integration at much lower cost
and high ROI on investments. As seen in the sections above, ESB holds lots of promise in the

Confidential

Page 20 of 21

The Role of ESB in integrating B/OSS Platforms

integration space for the Enterprise Industry. Equipped with web services and SOA under its
umbrella, it could prove as one-stop solution architecture for a variety of integration needs

References

Websites
http://www.eai-ideas.com/

Acknowledgement
I am thankful to Lakshman Munakala, Telecom OSS team for their valuable inputs during the
review period.
I would also like to thank Vijay Natamshanmugham for his support.
I would like to hear from you. Please send me your suggestions and comments at
prasant.kella@infotech-enterprises.com

=*=*=*=*=

END

OF

DOCUMENT

Confidential

=* = * = * = * = *

Page 21 of 21