Reflections on Integrating with EAI or ESB

Moganedi Sekele
Telkom SA
Belville
2008-10-17
The paper reflects on an EAI approach to application integration as it is implemented or
used in Telkom. It then makes a strong case for transitioning to integration with an ESB.

EAI succeeded addressing the enterprise’s need to enable disparate enterprise

applications to exchange data and/or information. However, there is now a new need to
design and develop enterprise applications with integrability, interoperability, extensibility
and reusability as primary objectives. The IT industry’s attempt to meet this need is the
Service-Oriented Architecture (SOA). The fundamental thread of SOA is providing
application functionality as sets of services. SOA’s technology for integrating services is
the Enterprise Service Bus (ESB).

In the light of the emergence of SOA and its adoption by Telkom SA, it follows that we
need to evolve our EAI technology based style of enterprise integration to the next-
generation enterprise integration technology of an ESB. This is not to say that we must
abandon everything that is part of EAI. On the contrary, we leverage the expertise and
infrastructure in EAI as the backbone of ESB. Hence, the key word evolution.

To better understand the reason(s) why we should evolve, a comparison of EAI and ESB
approaches of enterprise integration is provided and then three levels or phases of
integration are presented.

According to IONA Technologies (2007), ESB is better than EAI in three respects. Firstly,
EAI technologies generally integrate by creating a hub that translates data and messages
between different applications. An EAI hub uses adaptors to format incoming data into a
common canonical format that can be understood by the internals of the EAI hub as well
as outgoing adaptors. In contrast, an ESB system injects some intelligence at the point at
which an application interfaces with the outside world. Each ESB integration point presents
itself as a service accessible through an open standard such as WSDL thus resolving the
need to have a unique interface created for each application. Integration intelligence can
be deployed natively on the end-points (clients and servers) themselves. The benefit is
that data translation is by-passed in favour of directly formatting the payload to the
targeted format.

Secondly, the centralized hub nature of the EAI is applicable when applications with
different data or message formats have to interact. On the other hand, the light weight
architecture of ESB distributes processing logic to the end points (services). However, this
does not deprecates or make obsolete legacy applications as these can be wrapped up by
adapters and exposed as services in manner analogous to EAI’s “ring fencing” approach.

Thirdly, with EAI, the number of interfaces grows proportionally to the number of
applications required to integrate in an enterprise. In addition, most of these interfaces
introduce stacks of vendor proprietary features thus resulting not only in higher costs of
procuring them in the first place, but also get monolithic over time and often require
specialist expertise to maintain. ESBs on the other hand, supply a thin layer through which
different services with standardised interfaces integrate or interoperate.

BEA Systems (2007) has identified three levels at which integration can be realised in an
enterprise. The first level involves application integration where applications are integrated
to provide essential business functionality. The main drivers for application integration are
higher performance requirements and control over business processes affecting
applications involved in the integration. This is the EAI approach of integration.

The second level entails enterprise integration which assumes a SOA-based approach of
developing enterprise applications. Enterprise integration is geared to promoting a culture
of reusability and flexibility within a company. Reusability and flexibility are important for
short turn-around times in application development. Enterprise integration achieves its
goals through the core components of SOA which are data access provision, service
integration and process service enablement.

The third level of integration has as its goal the alignment of IT systems to business
processes. This level appropriately named business integration, represents the epitome of
IT in organisations. Some may feel that business integration is somewhat idealistic or
optimistic. The predominant function of IT has always been to automate information
systems. That is, the original assumption was that some form of information system
existed and that IT’s role was mainly to automate it. This approach led to long turn-around
times as IT tries to understand the business process (es) being automated. Business
integration enables IT to adapt to an organisation’s business model whilst also allowing it
to be proactive. With business integration, IT becomes part of core business of an
organisation rather than providing support services as is commonly the case. By placing
business and IT as partners in an organisation, business integration maximises the
organisation’s competitiveness and profitability.