In my last blog I highlighted aspects of Service Oriented Integration (SOI). In this blog I would like to quickly highlight the differences from more traditional integration approaches such as point to point (p2p), Enterprise Application Integration (EAI) and batch integration.
Point to Point
Unfortunately this is type of application integration I see most often in enterprises. Point-to-point integration is when one application connects directly to another application. The technology to facilitate the connection may be a third-party technology or product, but the result is the same – the applications are tightly linked together. The consumer application must know all the details of the source application for the integration to be successful. This results in a very brittle and difficult to maintain architecture. And as the number of systems increases, the number of point-to-point integrations grows rapidly. Despite the significant downsides,
point-to-point integration is very common primarily because it is the fastest way to integrate two systems. It is a classic “penny wise, pound foolish” approach to integration.
Despite the significant downsides,
point-to-point integration is very common primarily because it is the fastest way to integrate two systems. It is a classic “penny wise, pound foolish” approach to integration.
Service-oriented integration done correctly avoids the brittleness of a point-to-point integration architecture. In service-oriented integration the consumer is decoupled from the source system via the SOA Service that encapsulates and abstracts the source systems behind a service interface. Consumers of the SOA Service should need no details about the underlying source system. They should base the service usage solely on the contract provided by the SOA Service.
Unfortunately, simply adding a wrapper (e.g. Web service) to an existing system does not eliminate point-to-point integration. In fact point-to-point integration can be accomplished quite nicely using Web service interfaces. To be truly service-oriented, the SOA Services created must be well designed and constructed so the source system details do not bleed through. Service infrastructure that provides capabilities such as service discovery and routing is also essential to decouple service providers and consumers.
Enterprise Application Infrastructure (EAI)
Enterprise Application Integration (EAI) is an approach for integrating multiple applications. EAI products are built around messaging products and are deployed in either a hub-and-spoke architecture or in a bus architecture.
Some argue that service-oriented integration is actually a form EAI. This is not correct. EAI is an application-oriented architecture. EAI provides the mechanism to have applications interact to share data and functionality. Service-oriented integration adds the concept (and concrete deployment) of SOA Services that are separate and distinct, with a lifecycle that is independent, from any application in the computing environment.
Another major difference between traditional EAI and service-oriented architecture is the need for a common (proprietary) message infrastructure when using EAI. This is not a required artifact of EAI, but rather an implementation detail that was true for all major EAI products. In order to participate in the integration, each system needed to incorporate the message infrastructure client.
This was required because the communication protocol used by the message infrastructure was unique to each EAI product. [For this discussion, the
communication protocol includes the connection protocol (e.g. TCP/IP) as well as the message formats and message exchange patterns.] For example, there was no way for
a TIBCO client to send a message on a SeeBeyond message bus, or vice versa. Even
when the message programming interface was standardized (e.g. JMS) the communication protocol was still unique and proprietary. A JMS client could only enqueue or dequeue a message from a queue provided by the same vendor as provided the client. This led to vendor lock-in.
Service-oriented integration should be based on standardized communication protocols such as Web services or REST. Service-oriented integration can also use proprietary communication protocols (e.g. MQSeries, TIBCO, JMS) whenever appropriate. In fact, traditional EAI products can be easily incorporated into a service-oriented integration approach. The EAI product can provide connectivity to source applications which is especially helpful for legacy systems.
Batch Integration
Batch processing of data is another approach that is frequently used to integrate applications. There are two main types of batch integration. The first is where changes to a system are collected over a period of time by writing the change to some persistent storage (e.g. file). The changes are then transferred to another system and those changes are loaded in the other system. The primary disadvantage of this type of integration is the time lag for the data between the two systems.
The second type of batch integration is when large amounts of data are extracted from one system and then loaded into another system. This type of batch integration is frequently used for data warehouses. This type of batch integration is not easily replaced by a real-time connection between the systems. The amount of data being transported and the compute resources used to extract, transform, and then load the data is significant.
Service-oriented integration can be used to eliminate the first type of batch integration. The primary advantage is that there is no longer a time lag between the two systems with respect to the data changes. The second type of batch integration is best left as a batch process. From an integration perspective, it is desirable to minimize the number of batch integrations that are being performed, but when the business requirements dictate the movement of large amounts of data, batch processing is the best way to meet those requirements.
Lets Wrap Up
Integration is a continuing problem within enterprise IT. Although not a silver bullet, employing a service-oriented approach to integration provides tangible benefits and is superior to traditional integration techniques. Successful service-oriented integration is achieved by applying a “relaxed” layered architecture that provides all necessary capabilities and includes a consistent separation of concerns. Proper layering in the architecture eases maintenance by enforcing encapsulation of the various capabilities provided by the architecture.
Good Luck, Now Go Architect…
An Enterprise Architect's Musings 