Enterprise Application Integration
Enterprises are facing the challenge of integrating complex software systems
in a heterogeneous information technology landscape that has grown in an
evolutionary way for years, if not for decades. Most of the application systems
have been developed independently of each other, and each application stores
its data locally, either in a database system or some other data store, leading
to siloed applications.
Data heterogeneity issues occur if a logical data item—for instance, a
customer address—is stored multiple times in different siloed applications.
Assume that customer data is stored in an enterprise resource planning system
and a customer relationship management system. Although both systems use
a relational database as storage facility, the data structures will be different
and not immediately comparable.
These differences involve both the types of particular data fields (strings
of different length for attribute CustomerName), but also the names of the
attributes. In the customer example, in one system the attribute CAddr will
denote the address of the customer, while in the other system the attribute
StreetAdrC denotes the address.
The next level of heterogeneity regards the semantics of the attributes.
Assume there is an attribute Price in the product tables of two application
systems. The naming of the attribute does not indicate whether the price
includes or excludes value-added tax. These semantic differences need to be
sorted out if the systems are integrated. Data integration technologies are
used to cope with these syntactic and semantic difficulties.
Data integration is an important aspect in enterprise application integration.
In this section, the traditional point-to-point enterprise application
integration approach and an approach based on message brokers following the
hub-and-spoke paradigm will be discussed.
Point-to-Point Integration
A typical enterprise scenario is represented in Figure 2.4, where siloed applications
are shown; typically, many more application systems need to be
integrated, often even several instances of a specific type of application system,
such as enterprise resource planning systems, which in many cases run
different versions of the software.
Enterprise application integration technology is based on middleware technology
that has been around for years. The goal is to take advantage of these
technologies so that data in heterogeneous information technology landscapes
can be integrated properly. In addition to data integration, the processes that
the application systems realize also need to be integrated. This means that
one system performs certain steps and then transfers control to another system
which takes the results and continues operation. In the context of this
book, the process integration part of enterprise application integration is at
the centre of attention.
Enterprise application integration faces the problem that each integration
project requires design and implementation efforts that might be considerable.
When directly linking each pair of applications, system integrators run into
the N × N problem, meaning that the number of interfaces to develop rises
to the square of the number N of applications to be integrated.
A sketch of this integration issue is represented in Figure 2.5, where N = 6
of siloed applications and their integration links are shown. Each link represents
an interface that connects the application systems associated with it.
Therefore, the number of interfaces between pairs of application systems to realize grows to the order of N ×N, incurring considerable overhead. If there
were links between any pairs of application systems, then the number of interfaces
to develop would be 5 + 4 + 3 + 2 + 1 = 15. In the general case, the
number of links between N application systems is
N−1 Xi=1
i =
1
2N(N − 1)
and therefore rises to the square of the number of application systems. In the
scenario shown, not all pairs of application systems are connected, but the problem of the large number of interfaces can nevertheless be seen.
In enterprise computing, changes are abundant, and a systems architecture
should support changes in an efficient and effective manner. The enterprise
application integration architecture resulting from point-to-point integration
does not respond well to changes. The reason is due to the hard-wiring of the
interfaces. Any change in the application landscape requires adaptation of the
respective interfaces. This adaptation is typically realized by reprogramming
interfaces, which requires considerable resources.
A specific realization platform of enterprise application integration is
message-oriented middleware, where applications communicate by sending
and receiving messages. While conceptually the middleware realizes a centralized
component, the direct connection between the applications—and therefore
the point-to-point integration—is still in place, because each sender needs
to encode the receiver of a message.
The main aspect of message-oriented middleware is execution guarantees,
such as guaranteed message delivery. However, the problem mentioned above
is not solved, since any change in the application landscape needs to be implemented
by changing the communication structure of applications.
A sample architecture of message-oriented middleware is shown in Figure
2.6. The sender of a message specifies the recipients of the message. As
a result, the supply chain management system defines in its interface that
a certain message needs to be received by a particular enterprise resource
planning system and a particular customer relationship management system,
hard-wiring these application systems via the implemented interfaces.
Message queues are used to store messages persistently and to realize guaranteed
delivery. A client uses an application that integrates a number of application
systems; this application is called Integration Application in Figure 2.6.
In order to realize this integration, the integration application sends a message
to another application system, for instance, to an enterprise resource planning
system.
In order to do so, it inserts the message into the message queue of the
enterprise resource planning system. The message is then relayed to the ERP
system, which invokes the requested functionality and returns a result message
to the integration application. This result message is inserted into the incoming
message queue of the integration application. Receiving this message, the
integration application prepares a message and sends it to the supply chain
management system. Because each sender of a message needs to encode the
receiver of the message, effectively a point-to-point connection between the
applications is realized. Therefore, the problems of point-to-point connections
in supporting change do not diminish in message-oriented middleware.
This example shows that the cooperation of the application systems is
realized in the integration application. As in the early days of information
systems evolution, the process that describes how this cooperation takes place
is implemented by an application—in this case an integration application.
As a result, the process is hardwired within an application, so that there is
no explicit process model that can be easily communicated and changed, if
required.
While message-oriented middleware provides important run time guarantees,
response to change is not considerably improved. Still, any change in the
application structure or in the process behaviour needs to be mirrored by a
change in the communication structure, implemented for each application.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment