Enterprise Application integration (middleware) concepts

ERA OF Enterprise Application Integration (Middleware)
The Pre-Enterprise Application Integration Era:
There were large number of companies who bought in the 1990s the idea of packaged software solutions. These
solutions came from companies such as SAP, PeopleSoft, JDEdwards, Siebel, Oracle ERP, etc with the idea that it
would be able to solve most if not all of the problems ailing the particular company. In many cases, although the
packaged software solutions worked well individually, it was nigh impossible to integrate them with Z systems
within the enterprise. In most cases, each system produced redundant sets of information such as customer
information. The result of this was that when something like customer data changed, the company was required
to have someone manually updated the same information in other system. As can be imagined, this situation
became not only costly but cumbersome as well as data across systems became inconsistent due to the sheer
effort required to keep the data synchronized. The problems that cropped up with double data entry,
inconsistent data, and data isolation problems, forced companies to ultimately seek to find a solution to
integrate the systems. It is out of this search that the area of enterprise application integration (EAI) was born.
What is Enterprise application integration?
EAI is an architectural style for integrating disparate services and data in software. EAI looks to simplify and
automate business processes without the need for comprehensive changes to the existing applications and data
structures. As the organization evolves over time, it creates new departments with specific areas of focus,
interests, and expertise as well as merges with other organizations. Within this organization, all the departments
must work together, sharing business processes and data in order to achieve the overall goals and vision of the
organization. New business processes develop over time to help achieve new goals or further realize existing
goals. This can be done by either the purchase or development of software applications whose purpose is to
support said business processes. In this case, organizations can end up with a wide range of sometimes
overlapping, conflicting, or incompatible applications and systems. Many of these applications run on different
operating systems, support different databases, and are written in different computer languages. It
is a big challenge to bridge the gap of these disparate applications and services, due to their technical
incompatibilities as well as the prohibitive costs of cross-training personnel in the various systems.
The Problems of Point-to-point Integration:
In order to address the problems around the sharing and integration of data, EAI developers chose to pursue
point-to-point solutions initially as they find it easy to understand, quick to implement and low in cost when they
were only just a few systems to integrate. In a point-to-point integration, one application would make direct
database calls to another application's database tables using an API like JDBC (i.e. Java Database Connection).
Initially, it would seem that this way of integrating two applications using point-to-point integration solution
would be the best choice. The problem is that beyond a very small number of applications, as you integrate
more and more applications, the situation becomes more difficult to manage. This is shown in the figure below:

Created by-Shantanu Thakre. Page 2
Figure: Late Stage Point-to-Point Integration
An infrastructure based on strictly point-to-point methods of integration has proved to be brittle. Each
application ends up tightly coupled with the other applications through their point-to-point links. This
leads to a situation where even slight changes in one application can break the integration links with
other applications integrated. Also the number of integration points required to support increases as new
applications are added. For example, when you have five applications integrated with each other, they
will require 10 different integration points. This means that each additional application that needs to be
integrated will be not only harder to integrate but also to maintain over its lifecycle. This is demonstrated
in the figure below:

Figure: Multiple Point-to-Point Connections
In order we need an intermediate layer to isolate changes in one application from the others.
Benefits of Middleware-based Integration:
The intermediate layer that can serve to isolate the changes in any application is middleware. The
task of middleware is to provide a mediation point between applications. Middleware supplies generic
interfaces with can be used by all integrated applications in order to pass messages to each other. Each
interface serves to provide access to business processes provided by the integrated application. This type
of middleware is used quite frequently in the development of service oriented architecture (SOA). The
figure below shows a conceptual example of the use of middleware for integrating applications and
services in a SOA:

Figure: Middleware-based integration
The use of a service-oriented architecture allows you to swap in and out applications without impacting
on existing applications connected to the middleware. In contrast to point to point integration, there is a
one to one correspondence between applications and integration points. For example, if there are ten
applications that are to be integrated into your IT landscape, there will only be ten integration points.
These middleware-based solutions can easily support large numbers of integrated applications while at
the same time requiring less maintenance.
Benefits of EAI
An EAI based on the mediator pattern using middleware allows you to perform complex operations such
as transformations, aggregation, routing, splitting, and converting messages as well as using
orchestration to create new business process that uses the data and business processes of the various
applications in ways that previously was impossible. In return for the upfront costs of the complexity of
setting up and configuring the middleware, you are able to leverage and exploit your integration
architecture in ways that were previously unimaginable. The EAI architecture generally provides the
following benefits:
* Reusability - services are able to perform a set of operations that are described and
accessed through an interface. These interfaces enable interoperability between services
and promote the reuse of functionality.
*Encapsulation - services are encapsulated on each tier. They are accessible only
through the interface. The client of the service has no knowledge of the internal details of
a service. This allows for the implementation of the service to be modified without
impacting on systems that access this interface for this service.
*Distribution - the access to a particular service can be distributed and/or replicated
across many computers without modifications to the source code of clients. The

communication details are handled by the middleware layer, thus achieving location
transparency.
*Partitioning - this puts the functionality in the appropriate tiers so that we can then
build thin clients, build a middle tier that encapsulates all of the business logic, and build
the resource tier to address all issues related to data persistence. This use of abstraction
layers means that we can achieve flexible deployment options and configurations.
*Scalability - allows for the matching of the capacity of the middle tier to the client
demands by use of performance optimization techniques in the middle tier as well as the
ability to physically distribute and replicate the critical services enables good control over
the scalability over a long time period.
*Enhanced performance - applications leverage server-side optimization techniques
such as multiprocessing, multithreading, pooling, resource and instance management, and
thread management, without changing code and allowing dynamic configuration changes.
*Improved reliability - this avoids single points of failure and bottlenecks by the use of
replication and distribution.
*Manageability - By separating services into multiple tiers, it makes it easier to locate
services that need to be modified. The most frequent changes are made to those processes
in the business tier. These changes can be done without costly and time-consuming re-
installations. It is all centrally managed.
*Increased consistency and flexibility - as long as there are no changes to interfaces
between and inside the tiers, the code can be modified without impacting other parts of
the system. Multi-tier architectures are easier for adapting information systems to the
changing business needs over time. A change in the business tier services will consistently
effect all applications.
*Support for multiple clients - clients using devices of different form factors (i.e.
computers, tablets, smartphones) can access the business logic through the same
interface.
*Independent development - services can be developed independently of other
services. The interface between services defines the contract between them enabling them
to be developed independently as long as the contracts are respected.
*Rapid development - application developers are able to focus on rapidly development
and deployment of business functionality while remaining transparent to the underlying
infrastructure. Services can then be used in unpredictable combinations to form
applications.
*Composition - services can be composed in a variety of ways previously unimagined.
This provides great flexibility and support for business processes.
*Configurable - different implementations of the same service can be swapped at run-
time, enabling you to provide the capabilities that you need without redesigning
applications.

*Security - the measures that are applied to address different aspects of security, such as
authorization, authentication, confidentiality, non-repudiation, etc. require caution.

Enterprise Application integration (middleware) concepts

Related slideshows

More Related Content

Enterprise Application integration (middleware) concepts