You are on page 1of 11

Integration Basics

Enterprise Application Integration
•Enterprise - A business organization. In the computer industry, the term is often used to describe
any large organization that utilizes computers.
•Along with the increasing number of the business needs and the new software and applications
they get to always meet their customers’ satisfaction and to increase their system’s reliability. An
integration between all these applications and software is a must, so they can monitor their
systems and the transactions made more easily and efficiently.
•The main challenge always reside in how these multiple applications can communicate each
•The way of the Messaging between the applications which is most probable the point to point
integration. This will certainly oblige us to have a deeper look at the way the communication
between the apps is done, the middleware. If we are talking about a small IT infrastructure where
two or three applications needs to be connected then the point to point messaging would work
more than great, but with the increasing number of connectors, you will face certainly a high
degree of complexity and would not be able to manage all the connectors effectively.
•Well the solution for EAI is quite simple, is building a middleware that manages all the
connectors, loosens the coupled connections, which lead us to the Service Bus.
Introduction to Middleware
•Middleware is application-independent software that provides services that mediate between
applications. Middleware hides the complexities of the underlying operating system and network
in order to facilitate the easy integration of new and legacy systems.
•Is a means for connecting clients to servers, clients to clients, and servers to servers without
having to navigate through many operating systems, networks or resources server layers.
•There are two types of middleware, logical, that is related with how information moves through
the organization and physical, that really moves the information and covers the technology used
for this purpose.
•Middle ware provides proven ways to connect the various software components in an
application so they can exchange information using relatively easy to use mechanisms.
•Middleware can be used to wire together numerous components in useful, well understood
topologies. Connections can be one to one, one to many or many to many.
•From the application users perspective, middle ware is a completely hidden. Users interact with
the application and don't care how information is exchanged internally. As long as it works, and
works well, middleware is invisible infrastructure.
•The only time application users are ever aware of the role middleware plays is when it fails. This
is of course very like real plumbing and wiring systems.
Integration Architectures
Point-To-Point Architecture
•In a point-to-point integration architecture, when two applications need to communicate with
one another, a connection is established and a connector enables application A to speak to
application B by sending a message or executing a procedure.
•A connector is a bridge that allows access to data or application functionalities in a structured
•Connectors handle the complexities of message translation, integration and any other relating
messages operations used to access the application features.
•When is needed to change either application A or B, the interface needs to be updated in both,
and if we add one more application C, for our applications universe to be fully integrated we have
six connectors to update and maintain, and this number grows with each application added.
Remember that each of these connectors must be separately developed and maintained across
system version changes, scalability changes or, in some cases, even purchased at high cost from a
•While the advantage of point-to-point integration is its simplicity,
•The disadvantage is its complexity.
•Even though it is highly advantageous in scenarios where the universe of applications is small, as
this number grows, maintenance becomes very problematic and expensive.
Integration Architectures
Hub/Spoke Architecture
•Hub/Spoke architecture uses a centralized broker (Hub) and adapters (Spoke) which
connect applications to Hub.
•A Spoke connects to an application and converts application data format to a format which the
Hub understands, and vice versa. A Hub, on the other hand, brokers all messages and takes care
of content transformation/translation of the incoming message into a format the destination
system understands and routes the message.
•Adapters take data from the source application and publish messages to the message broker,
which, in turn, does transformation/translation/routing and passes messages to a subscribing
adapter which sends it to destination application(s). Having a single Hub makes a system with this
architecture easy to manage but scalability takes a hit.
•At some point, as the number of messages increases, scalability gets dependent on hardware.
•To address thid most vendors have incorporated the concept of a federated hub and
spoke architecture in which multiple hubs can be present. Each hub would have local meta-data
and rules as well as global meta-data Changes to global rules and meta-data are automatically
propagated to other hubs.
•Federated hub spoke architecture alleviates scalability issue while central management of
multiple hubs makes this architecture easy to manage and brings down support cost.
Integration Architectures
Bus Architecture
Bus architecture uses a central messaging backbone (bus) for message propagation.
Applications would publish messages to the bus using adapters. These messages would flow to
subscribing applications using the message bus.
Subscribing applications have adapters which would take a message from the bus and transform
the message into a format required for the application.
A key difference between hub/spoke and bus topology is that for the bus architecture, the
integration engine that performs message transformation and routing is distributed to the
application adapters.
The bus architecture requires an application adapter to run on the same platform as the original
applications. Since each adapter has an integration engine and runs on same platform on which
source and target applications run, this scales much better and is relatively complex to maintain
compared to hub/spoke topology.
Service Oriented
Architecture Overview
•If you are a developer you will certainly hear a lot about SOA (Service Oriented
•it is a concept or you can use the services or code that someone else wrote, In other
words you don’t have to write the whole program from scratch, you will consume
other’s programs or services already built. Certainly that helps people a lot, it helps
you save time, effort and money,
•Example - when you integrate google's map in your application, all you have to do is
to add the api services in your application as service reference and if not, it will take
more effort adding the URL, however you will be able to consume the service, its
functions and you may reuse them as long as you need.
•This was the simple explanation for the SOA from the point of view of a developer; let
us go a little deeper. Any SOA mainly depends on 2 things WSDL: Web Services
Description language for describing web services and how developers can access
these services and the second thing is the SOAP protocol to describe the
communications protocols.
•The WSDL is a normal XML file mainly contains all the required information to invoke
the web service. The SOAP protocol is simple XML-based to let applications exchange
information over HTTP.
•Enterprise service bus is an infrastructure to facilitate SOA. Technically, the ESB is a
messaging backbone which does protocol conversion, message format transformation,
routing, accept and deliver messages from various services and application which are
linked to the ESB.
•The current EAI landscape is seeing many vendors who offer enterprise service bus
solutions and claim it to be a brand new concept. This brings a question on what
exactly is the difference between ESB and the bus based implementations which have
been there in market for quite a long time now.
•Actually there is not much difference between ESB and proprietary buses except for a
few subtle ones. The main difference between ESB and proprietary bus
implementation is cost, which is significantly lower for ESB. The reason for this cost
difference is twofold:
•(1) proprietary bus offers lot of built in functionalities as a suit of product which need
to be developed for ESB implementations based on business requirement,
•(2) most proprietary buses use some proprietary formats to enhance the
performance which increases the cost. ESB on the other hand is usually standard
•so it is a tradeoff between performance and cost between proprietary bus and ESB.
The main advantage of ESB is that it costs much less then hub/spoke or bus based
product suits, and is standards based.
The VETO Pattern
•VETO is a common integration pattern that stands for Validate, Enrich, Transform,
Operate. The VETO pattern and its variations can ensure that consistent, validated
data will be routed throughout the ESB.
•The "Validate" step is usually the first part of any ESB process and can be
accomplished in a number of ways. It's important that if possible, this step happen
independently; this removes the burden of validation from all of the downstream
service implementations and promotes reuse. Building validation directly into the first
service of a process makes it difficult to insert an additional service in front of it
without requiring that the new service also provide its own validation.
•An example of validation is to simply verify that an incoming message contains a well-
formed XML document and conforms to a particular schema or WSDL document that
describes the message. This requires that the service always have available the up-to-
date XML schema for a particular message type. The schema and WSDL can be kept in
the directory service and managed remotely by the management infrastructure of the
•A service may also have scripting associated with it, which can be made available to
the service as a configuration parameter.
•If the target data is not in XML format, or if there is no schema or WSDL available,
then a custom service can be used to validate the incoming message.
The VETO Pattern
•The "Enrich" step involves adding additional data to a message to make it more
meaningful and useful to a target service or application. The Enrich service could be
implemented to invoke another service to look up additional data, or it could access a
database to get what it needs.
•The "Route" step involves content-based router service which routes the message to
the relevant target based on the content of the message.
•The "Transform" step converts the message to a target format. This often involves
converting the data structure to an internal canonical format, or converting from the
canonical format to the target format of the "Operate" step. The target system may
have its own built-in validation rules requiring that the transformation step modify the
incoming data in order to prevent the target system from rejecting the message. In
this sense, the transformation step is also providing pre-validation protection in a
separate service that can be separately managed. While this may mean redundant
logic in the short term, it provides more flexibility in the long term, because it allows
the "Operate" step to focus on business logic.
•The "Operate" step is the invocation of the target service or an interaction with the
The VETRO Pattern