Integration Technologies - Guide to Cloud Computing for Business and Technology Managers - page 133

Thus, by using the enterprise data model to exchange messages, we get
the best of both worlds. The number of transformations is reduced to 2 × N
(assuming a single interface between each end point). This gives us much
better modifiability characteristics. Also, as there are now considerably
fewer and less complex transformations to build, the transformations can be
executed in the end points themselves. We have no need for a centralized,
broker-style architecture. This scales well, as there's inherently no bottleneck
in the design. And there's no need for additional hardware for the broker
and additional license costs for our chosen broker solution.
However, the strategy of using an enterprise data model for obviating
the need of enterprise integration issues is not prevalent—the primary rea-
son for this is existing enterprises have to confront the reality of myriad of
enterprise applications and the corresponding enterprise data models and
the sheer impossibility of converting or migrating to a uniform canonical
enterprise data model.
5.13 Summary
Most of the enterprises have a host of existing enterprise applications and
infrastructure technologies including integration technologies themselves.
We looked at a spectrum of technologies that have been employed toward
obtaining integration between enterprise applications. These include data-
base access technologies, asynchronous and synchronous middleware,
message-oriented middleware, request/reply messaging middleware,
transaction processing monitors, object request brokers, application servers,
Web Services, enterprise service buses, and enterprise systems. The inability
of enforcing a uniform enterprise system/architecture/data model within
the enterprise gave a fillip to the service-oriented architecture, which we
discuss in Chapter 7.