Integration Infrastructure and Technologies

By Matjaz Juric, S. Jeelani Basha, et al

Infrastructure Services

To make a better selection of technologies to use for integration let us first focus on the required infrastructure services. We will try to identify the services from a high-level perspective and separate them into the horizontal and vertical layers. The services in horizontal layers will provide basic infrastructure services useful for the majority of existing and new generation applications. The vertical layer services will provide functionalities related to a specific task within infrastructure that can span through several horizontal layer services.

The services on the horizontal layer include:

• Communication
• Brokering and routing
• Business intelligence

The vertical layers are:

• Transactions
• Security
• Lifecycle
• Naming
• Scalability
• Management
• Rules

The relations between the services are shown on the next figure:

Infrastructure Technologies

It is unusual to find a single technology for all the specified needs. In other words, for building a comprehensive enterprise-wide integration infrastructure we will need to use more than one middleware technology.

When selecting and mixing different technologies we have to focus on their interoperability. Achieving interoperability between technologies can be difficult even for those based on open standards; for proprietary solutions interoperability is even more difficult.

It is not only a question of whether we can achieve interoperability but also of how much effort we have to put in to achieve it. Therefore, companies lean more and more towards software platforms that gather compatible technologies. Using a software platform usually saves a lot of additional work. We will mention here three important platforms:

• Java 2 Platform, Enterprise Edition (J2EE)
• CORBA
• Microsoft .NET

J2EE and CORBA both have associated specifications, and different vendors offer products that comply with these specs. In this sense they are open platforms, J2EE controlled by Sun and the Java Community Process, CORBA by the Object Management Group (OMG). In fact, the J2EE and CORBA specs have been converging in the last few years. On the other hand, Microsoft .NET is proprietary and directed specifically towards a Windows platform. All three platforms provide a large set of technologies, and are more or less appropriate for integration.

A comparison of these platforms is beyond the scope of this article, which is focused on the J2EE platform. We provide an overview of all the technologies that the J2EE platform provides in our book.

In this article we will not focus on a specific technology. Instead, in the next section we will introduce the concept of the integration broker, which will abstract the technologies necessary to build the integration infrastructure.

The Integration Broker

An integration broker is an abstraction for the technologies through which we realize the integration infrastructure. The broker provides the horizontal and vertical services that we identified earlier.

We will use the concept of an integration broker throughout the rest of chapter 2 when we refer to the various integration architectures and services, but we won’t occupy ourselves with technologies that have been selected to implement the integration with. Rather, we will assume that the integration broker provides a high-level access to the infrastructure.

The integration broker will be used by both existing and newly developed applications to achieve integration on different levels. Applications will access the integration broker transparently through interfaces in either programmatic or declarative ways. A programmatic way means that applications will have to implement code to use the infrastructure services; the declarative way, on the other hand, enables us to just mark specific applications and declare which services they should use the infrastructure then takes care of the details of invoking a service. How we achieve this will depend on the selected technologies.

The transparency of the provided services will also depend on the choice of technology. Communication, brokering, and routing services can, for example, be implemented transparently with the use of ORBs, which mask remote method invocations to the level that they look like local method invocation to the developers. MOM, on the other hand, will require that the application creates a message, parses incoming messages, and reacts to them accordingly. Declarative transaction and security services can provide services to applications without adding any code to the application, and so on.

The integration broker is used on all integration levels, which we will discuss in detail shortly. It opens up the path to build the integration layers step-by-step and reuse the previous results, avoiding any reliance on point-to-point communication between applications.

Remember, point-to-point integration has the following disadvantages:

• The number of connections between applications can become very high
• A large number of dependencies between applications requires a lot of effort for maintenance
• Maintenance of links between applications can become more costly than the maintenance of the applications themselves, which will make the benefits of integration less obvious

The integration broker solves the point-to-point problem. It provides a common mediator, to which all applications connect, thus reducing the n-to-n multiplicity to 1-to-n:

When we compare this diagram to that shown earlier in the chapter which illustrated the point-to-point linking of five application databases from our cell phone operator case study, we can clearly see that the complexity has been greatly reduced.

Interoperability interfaces define relations between applications on which applications depend. Interfaces are effectively long living contracts that define the coupling between integrated applications. They provide a fagade through which client applications access the interoperability services and encapsulate the applications. As long as the interfaces stay unchanged we can replace parts or whole server applications without influencing any client application. Therefore great effort has to be put into the definition of interoperability interfaces.

The diagram that follows shows the role of interoperability interfaces when integrating through an integration broker:

Compared to point-to-point integration the integration broker offers the following advantages:

• The number of connections between application is
  reduced, thus reducing the level of coupling between integrated applications

• The dependencies between applications are defined as
  contracts in the form of interoperability interfaces

• Maintenance effort and costs are reduced to an
  acceptable level

• If the interfaces are carefully designed we can replace parts or whole
  applications without influencing other involved applications

This article is from Professional J2EE EAI by WROX Press To purchase the book, click on the title or the cover image. © Copyright WROX Press, All Rights Reserved