Section 10.2. Enterprise Application Integration

10.2. Enterprise Application Integration

At first glance, Enterprise Application Integration (EAI) appears to be the perfect environment to employ an SOA: In fact, plenty of reasons to use an SOA as a driver for EAI exist, and vice versa. However, EAIs pose a certain set of requirements in addition to profound non-technical issues that you must consider.

Today, most large organizations have a highly fragmented application infrastructure, in which a vast number of client applications have been created using multiple programming platforms and communication infrastructures from multiple vendors. A recent example of the endeavor to solve all application integration problems is the introduction of a corporate "standard" ERP (Enterprise Resource Planning) suite. This process failed in most organizations due to the relatively low flexibility such a solution provides and the fact that businesses have a need for tactical IT solutions, as opposed to strategically planned applications.

This example of failure provides a reason to be wary of addressing EAI problems with an SOA. Nevertheless, if an SOA is properly deployed, it will address many technical and core concerns related to EAI. There are two ways of looking at EAI in a service-oriented world: as a service provider and as a service consumer. As a service consumer, you typically want a service that is easy to access, highly available, functional complete, and stable over an indefinite period of time. As a service provider, you might want a service that is easy to deploy and to upgrade; in an EAI environment, quality of service, single sign-on, and other attributes become paramount.

At the outset, it is worth noting that so-called EAI product suites are generally unsuited to tackle the aforementioned EAI challenges. Most provide a clear integration path that is usually supported by accompanying tools, some of which provide for quality of service and ship pluggable security modules, but they usually fail to provide a stable view of the result of the integration process. Furthermore, because they only partly adhere to open or industry standards, they are very unlikely to be stable for a reasonable period of time. This is one of the prime reasons that organizations that take SOA seriously almost always choose to build their core service architecture themselves while employing standards wherever possible (see the case studies in Chapters 14 through 17).

10.2.1. SERVICE ENABLEMENT

In order to provide EAI functionality in a service-oriented environment, the most common task is service enablement. Service enablement is the process that creates a service to encapsulate the functionality provided by an existing application. The type of application encapsulated can be anything from a monolithic mainframe application to a distributed application built on top of CORBA or DCOM.

Of course, service enablement is more than just wrapping and exposing an existing programming interface. As an example, consider the movement of an existing check-in application in a service-oriented domain. Assume thatas shown in Figure 10-4the original application is a typical client/server application. As a first step for service enablement, the application is separated into a visual and a non-visual part. Communication between both parts is grouped based on their business domain. Access to the non-visual layer is defined by one or more interfaces. If possible, the implementation of the interfaces and the persistent data upon which they act can also be separated. Finally, the application is moved to the service infrastructure.

Figure 10-4. Transformation of a monolithic application into a service-oriented application.

Depending on the application, one or more services might emerge from this analysis. For example, when analyzing a real-world check-in application, it is quite likely that services such as ticketing, baggage handling, and actual check-in will surface during such an analysis. After this analysis is complete, consolidated interface descriptions for the communication can be derived. This should include provisions for undoable actions and idempotency wherever possible. The implementation and possibly the interfaces need to be changed to include infrastructure services such as user management and security as well as internal changes for server-side resource handling. Now the visual layer and the service layer can actually be separated.

It is evident from the check-in example that the examination of a single application is unlikely to yield fully reusable services. Although it is reasonable to assume that one can obtain a fairly complete description of the check-in service itself, it is rather unlikely that sufficient information about the baggage handling or the ticketing service can be obtained.

If more than one application exists that relies on common underlying principles, immediate reuse benefits can be obtained from the service enablement. For example, many applications share the concept and even the persistence mechanism for entities, such as customer or contract in a business scenario. Factoring these out into services not only provides instant benefits for reuse but also acts as a successful demonstration of the suitability of the Service-Oriented Architecture that is likely to empower other departments to use the newly created services and contribute new services.

When service-enabling applications for EAI in the way we have described, it is essential that a service registry be available. This can be used to identify those remaining services that are already available in the application and that can be factored out of the existing application.

Another common scenario is to provide services for an already distributed architecture. Recall that a distributed architecture alone does not necessarily consolidate an SOA. Often, the interaction patterns between the application frontend and the distributed components are too fine-grained. A sensible approach is to define façade services that sit between the application and the distributed objects. The application is stripped of all knowledge regarding items such as distributed objects and uses the service as its sole communication channel to the backend logic (see Figure 10-5). The service then aggregates the functionality available in the distributed computing environment. At the same time, coupling in the distributed object layer can be replaced by explicitly coupling services. It will also use a common service infrastructure, as you have seen previously. It is often desirable to replace the distributed object implementation with a more localized implementation to reduce network load and latency. Because the implementation has been encapsulated in the service layer, it can easily be replaced without having an effect on the applications that use the service. The service façades to the distributed computing environment should be cut in a way that enables them to act as the sole owner of the data upon which they operate.

Figure 10-5. Creating a service layer that replaces direct interaction with distributed objects.

There are, of course, other scenarios that can be used to enable transformation toward an SOA. For example, rich applications that rely on backend services (see Section 10.4) greatly benefit from the creation of a service layer.

EAI Can Drive an SOA

EAI is an excellent driver for service-enabling existing applications. From a business perspective, EAI is introduced to simplify the application infrastructure and to foster reuseproviding good motivation for creating an SOA.

10.2.2. STABILITY AND UPGRADE ABILITY

Service stability and the ability to upgrade are two of the most desirable features in an EAI environment. The reason is that the service consumer might reside in a different department or even in a different country from the service provider. The service provider must be able to upgrade a service without having an impact on current applications that integrate this service. You can use various methods to solve this problem, with the two main styles being backward compatibility and the provision of different versions. Backward compatibility is illustrated in Figure 10-6. Effectively, this means that service interfaces can only be extended without violating existing interface contracts. This is similar to the discussion on payload semantics in Chapter 3, "Inventory of Distributed Computing Concepts." Unfortunately, this approach tends to weaken the interface contracts over time, which in turn makes it difficult to enforce a specific usage style.

Figure 10-6. A service that supports versioning by extension of the request document format. Although this is easy to achieve with pure payload semantics, it can be difficult in other environments.

Although it is fairly straightforward to achieve this using XML communication such as SOAP, it can be arbitrarily hard to do so using CORBA or DCOM without reverting to pure payload semantics.

On the other hand, you can easily provide different production versions of a service by deploying the service in different locations. These locations can be looked up in a registry that also contains information regarding the most up-to-date service available. Although this creates significant overhead in managing the SOA, it completely decouples service upgrades from existing applications. It is also straightforward to provide this using any available communication model. The out-of-date services are continuously monitored and can be shut down when no more applications are accessing them. Moreover, it might be desirable to reimplement the old services in terms of the new services. By keeping the contract unchanged, the old service clients can communicate transparently with the new implementations. Figure 10-7 illustrates two versions of the check-in service working with an online registry. Using the online registry for binding to the actual service implementation at runtime makes it possible to migrate older services to different, less capable hardware.

Figure 10-7. An SOA that enables different versions of a single service to be productive at the same time.

EAI Requires Repositories

EAI scenarios should use service repositories because this is the best way to ensure stability and upgrade ability. It is crucial to give your internal clients peace of mind when using the SOA.