Applications, Databases, and Middleware

Too often, when we consider the details of integration servers, we put the cart ahead of the horse. The first step in an integration server evaluation must include an evaluation of the types of systems to be integrated.

The source and target systems may consist of any number of entities database servers, Web servers, host applications, user screens, distributed objects, ERP applications, and custom or proprietary applications. The benefit of integration servers rests with their ability to link different types of systems, adjusting to the variations between all source and target systems. They are able to do this by exposing an API (and sometimes an adapter, which will be discussed later in this chapter).

It is also noteworthy that integration servers adhere to a noninvasive application integration model, where the source and target applications don't require many changes to move information among them. Because integration servers are able to leverage many points of integration (including database access, screen scraping, defined APIs, and middleware), in many cases no changes at all are required.

An API is nothing more than the mechanism that allows an application to access the services of an integration server (see Figure 9.4). When using APIs, the developer can create a link between the source or target application interface and the integration server API. This requires creation of a program that binds the application's point of integration to the API of the integration servers, or changing the application to communicate with the integration server using its API.

Figure 9.4. Integration servers provide services to applications through an application programming interface or an adapter.

Doing this has a huge downside. To bind an application to the integration server you must create code to accomplish the task, or change the application to accommodate the integration server API costly propositions, in terms of both time and money. The inevitable need for testing only adds to the costs.

By contrast, adapters can link deeply into an application or database. They move information to and from source or target applications without the need to create new code (or any code, for that matter). Adapters, which we discussed in the previous chapter and will discuss later, hide the complexities of the integrated applications by managing the movement of information into and out of the application on behalf of the integration server. Adapters leverage points of integration, such as a native interface (e.g., SAP's BAPI). They manage the consumption of information from the source application, converting it into a form that the integration server can understand. On the other end, adapters publish the information to the target application in a form that the target application can understand.