You keep using that word. I do not think it means what you think it means.

Integration isn't a four letter word, but for many hapless IT folks stuck with the chore of integrating applications, it probably should be. SOA promised to make the world of application integration a painless, happy process in which the traditional basement sacrifice of live chickens and wild gyrations near a glowing rack of servers were no longer necessary. In many cases, the live chicken sacrifice was no longer necessary, but the wild gyrations were still a fact of integration experts' lives, mostly executed out of pain and frustration when systems failed to properly integrate together.

The problem is that there are multiple definitions of the word integration that tend to complicate things, and when you cross functional IT areas (network, application, servers) you tend to understand the meaning of integration a bit differently.  

There are many meanings of the word integration and we often use them interchangeably, much to the confusion and consternation of those who have to decipher exactly what is meant when the word is used. There are two core uses of the word integration, and we're going to focus on them as they are usually the ones that cause the most headaches when used in everyday conversation.

System Integration

System integration is the process of joining, or merging, two different systems, usually software, together. It's often an under-the-covers process that isn't readily apparent to the outside world. In the world of software, this type of integration refers to the process of development that results in the merging of two disparate systems. For example, at F5's core is the TMOS platform. System integration efforts merge separate - sometimes acquired - technology onto that platform so that they work together on a single, managed platform.

Application Integration

Application integration is the process of making two applications work together through the exchange of data. Sometimes that data exchange is accomplished via direct communication between the applications and sometimes the integration occurs through the modification of data sources specific to the application. For example, an order entry system can either request that the inventory application update its data source or it can directly modify the data source itself. The former is more easily accomplished when the inventory application presents a clearly defined interface or protocol through which the integration can occur. This is where SOA shines as it requires a well-defined interface (WSDL and its described operations) through which other applications can interact with the application. The latter can also be accomplished via SOA if the data source has been service-enabled; that is that the data source has been wrapped with an appropriate SOA-based service. It can also be accomplished by an application directly modifying the data source by employing adapters, plug-ins that are commonly used to enable access to data sources from applications through the application platform, e.g. BEA WebLogic, IBM WebSphere, Tomcat, and Oracle AS.

Application Delivery Networking and Integration

Application delivery networking does very little to to assist in system integration efforts as system integration is typically a development exercise that happens within a single application rather than application integration, which occurs between applications. Application delivery networking can, however, do quite a bit to aid application integration efforts, particularly when those applications are web-based or SOA applications.

ADN technology can, of course, improve performance through acceleration and connection management as well as provide availability assurance through load-balancing capabilities. But these are not integration specific capabilities. It may be surprising to learn that ADN technology can actually act as part of the integration process.

Part of integrating applications often includes conditional routing or processing. For example, a request should be routed to application A if some condition exists, such as an item being out of stock. The functionality to route a request to the proper application is often handled by EAI (Enterprise Application Integration) applications, but in many cases an intelligent application delivery controller (ADC) can provide the same functionality. If the ADC can inspect - and understand -  the request, it can determine the value of elements or data fields within the request and route the request to the proper application.

A second responsibility of application integration can be exception or fault handling. This is the process of recognizing that an error has occurred and, based on the error, performing some task - such as sending an error message back to the requesting application or client, retrying the request, or sending the request to yet another application. An intelligent ADC can perform these tasks with alacrity and, as with the ability to perform conditional routing, provides the additional benefits often associated with ADCs such as availability, security, and performance enhancing features.

An ADC can perform some of the tasks associated with application integration and, in many cases, can perform those tasks much more efficiently - and reliably - than its EAI counterpart. The ADC is often included in the architecture to ensure reliability and availability, and is therefore in the proper place in the infrastructure to provide these additional features without requiring changes to either the application or the architecture.

By assigning conditional routing and exception handling duties to an ADC the integration of applications often results in more reliable communications due to the core competencies of an ADC to ensure the availability of the applications for which it is providing integration services.

Imbibing: Mountain Dew