Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Enterprise application integration using J2EE

Learn EAI and integrate your applications with Java

  • Print
  • Feedback

During the 1990s, companies bought packaged software solutions such as SAP, Oracle ERP, PeopleSoft, JDEdwards, Siebel, Clarify, and so on. Although such packaged software solutions worked well individually, they created information islands. In most cases, each system produced redundant information (like customer information). As a result, when common data changed, employees manually updated the associated information in each system, a process that quickly becames cumbersome. Eventually, some of the data across systems became inconsistent. When people noticed the resulting double data entry, inconsistent data, and data isolation problems, they decided to find ways to integrate the systems. From that search, enterprise application integration (EAI) was born.

Enterprise application integration

EAI combines separate applications into a co-operating federation of applications. Two logical integration architectures for integrating applications exist: Direct point-to-point connections and middleware-based integration.

Point-to-point integration

EAI developers pursue point-to-point integration because they find it easy to understand and quick to implement when they have just a few systems to integrate. A point-to-point integration example: One application makes direct JDBC (Java Database Connection) calls to another application's database tables. Initially, when you integrate two applications, the point-to-point integration solution seems like the right choice; however, as you integrate additional applications, you get a situation shown in Figure 1.

Figure 1. The later stages of a point-to-point integration



Considering all that, point-to-point integration's infrastructure proves brittle. Each application is tightly coupled with the other applications through their point-to-point links. Changes in one application may break the applications integrated with it. As another disadvantage, the number of integration points require support. If you have five applications integrated with each other, you will need 10 different integration points, as Figure 2 illustrates. As such, each additional application becomes harder to integrate and maintain.

Figure 2. Number of point-to-point connections



To avoid that problem, we need an intermediate layer to isolate changes in one application from the others.

Middleware-based integration

Middleware has stepped up to the task of providing a mediation point between applications. Middleware provides generic interfaces with which all integrated applications pass messages to each other. Each interface defines a business process provided by an application. Figure 3 shows a logical depiction of the service-oriented architecture using middleware.

Figure 3. Middleware-based integration



A service-oriented architecture lets you add and replace applications without affecting the other applications. If you have five applications to integrate, you'll have just five integration points. Compared to the point-to-point solution, middleware-based solutions easily support numerous integrated applications and require less maintenance. In addition, middleware can perform complex operations—transforming, aggregating, routing, separating, and converting messages—on the data passed from application to application(s). The only downside: the added initial complexity of setting up the middleware and converting existing applications to use the middleware APIs.

  • Print
  • Feedback

Resources