A business organization.

In the computer industry, the term is often used to describe any large organization
that utilizes computers.

Introduction to Enterprise application Integration (EAI)

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 other? The
answer would be easy, it is SOA (service Oriented Architecture), well it is a yes and no. Yes because all
these connections have to go through the SOA but no because SOA is not enough and need few more
things to ensure its reliability. 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 me 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 provides the pipes for shipping data between components and can be used in wide
range of different application domains.
 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'r 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
1. 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 manner. Connectors handle the complexities of message
translation, integration and any other relating messages operations used to access the application
features [3]. 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 vendor. With all these
reasons, the unsuitability of point-to-point integration for complex enterprise scenarios becomes
painfully clear [4]. While the advantage of point-to-point integration is its simplicity, the disadvantage is
its complexity [4]. 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; originating what
is commonly called “spaghetti” architecture. If we want to avoid this “spaghetti”, we need to provide an
intermediate layer that can isolate the changes between applications, effectively reducing the coupling.
To do this, we use middleware.
2. 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. Having a bigger box to scale the application has never been an ideal solution.
So to overcome this limitation, 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 metadata and
rules as well as global metadata. Changes to global rules and metadata 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.
3. 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 Architecture). So what is
this? Let me get it the most important part a developer, 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, let me give you an example when you integrate Bing’s map in your
application, all you have to do is to add the services in your application as service reference if you are
using visual studio 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.

ESB
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 based,
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 VETRO Pattern

VETO is a common integration pattern that stands for Validate, Enrich, Transform, Operate (see Figure
6). The VETO pattern and its variations can ensure that consistent, validated data will be routed
throughout the ESB.
Validate
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 ESB. 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.
Enrich
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.
Route
The "Route" step involves content-based router service which routes the message to the relevant target
based on the content of the message.
Transform
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.
Operate
The "Operate" step is the invocation of the target service or an interaction with the target application. If
the target operation is an enterprise application that requires its own data format, then the previous
transformation step converts the message to the target format required by the application.