What is Applications Integration?
Applications integration (or enterprise application integration) is the sharing of processes and data among different applications in an enterprise. For both small and large organizations alike, it has become a mission-critical priority to connect disparate applications and leverage application collaboration across the enterprise in order to improve overall business efficiency, enhance scalability, and reduce IT costs.
Before architecting an applications integration solution, however, it is crucial to understand the different levels of integration and in particular, how messages are exchanged in an applications integration environment. This article provides an overview of the different levels of integration - the presentation level, the business process level, the data level, and the communications level - and then examines communications-level integration in greater detail with a discussion of synchronous and asynchronous communication.
The Different Levels of Applications Integration
There are four different levels of applications integration. At the presentation level, integration is achieved by presenting several different applications as a single application with a common user interface (UI). Also known as “screen scraping,” this older approach to integration involves using middleware technology to collect the information that a user enters into a web page or some other user interface. Presentation-level integration was previously used to integrate applications that could not otherwise be connected, but applications integration technology has since evolved and become more sophisticated, making this approach less prevalent.
With business process integration, the logical processes required by an enterprise to conduct its business are mapped onto its IT assets, which often reside in different parts of the enterprise and increasingly, the cloud. By identifying individual actions in a workflow and approaching their IT assets as a meta-system (i.e. a system of systems), enterprises can use applications integration to define how individual applications will interact in order to automate crucial business processes, resulting in the faster delivery of goods and services to customers, reduced chances for human error, and lower operational costs. Business process integration thus supports a Service Oriented Architecture (SOA), which promotes the development of composite applications through the use of existing services (i.e. individual units of functionality) within the enterprise.
Aside from business process integration, data integration is also required for successful applications integration. If an application can’t exchange and understand data from another application, inconsistencies can arise and business processes become less efficient. Data integration is achieved by either writing code that enables each application to understand data from other applications in the enterprise or by making use of an intermediate data format that can be interpreted by both sender and receiver applications. The latter approach is preferable over the former since it scales better as enterprise systems grow in size and complexity. In both cases, access, interpretation, and data transformation are important capabilities for successfully integrating data.
Underlying business process and data integration is communications-level integration. This refers to how different applications within an enterprise talk to each other, either through file transfer, request/reply methods, or messaging. In many cases, applications weren’t designed to communicate with each other, requiring technologies for enabling such communication. These include Application Programming Interfaces (API’s), which specify how applications can be called, and connectors that act as intermediaries between applications. At the communications level it is also important to consider the architecture of interactions between applications, which can be integrated according to a point-to-point model, hub-and-spoke approach, or Enterprise Service Bus (ESB).
Getting the Message: Synchronous vs. Asynchronous Communication
Without effective communication, business processes and data cannot be properly integrated. Depending on an enterprise’s particular needs, communication can be either synchronous, asynchronous, or some combination of the two.
In synchronous communication, a sender application sends a request to a receiver application and must wait for a reply before it can continue with its processing. This pattern is typically used in scenarios where data requests need to be coordinated in a sequential manner.
In asynchronous communication, a sender application sends a message to a receiver application and continues its processing before receiving a response. In other words, the sender application does not depend on the receiver application to complete its processing. If multiple applications are being integrated in such a fashion, the sender application can complete its processing even if other subprocesses have not finished processing.
When designing applications integration solutions, asynchronous communication offers a number of advantages over synchronous communication, especially when it comes to services in SOA. In synchronous communication patterns, timeouts are more common when an application has to wait for responses from several other applications. This means that the availability of services increases since individual processes are not blocked out as frequently due to waiting on other subprocesses to complete. Subprocesses can in fact be executed in any order. Moreover, asynchronous communication allows for the loose coupling of applications, eliminating the need for connection management. This results in an applications integration solution that is more flexible, agile, and scalable - essential attributes for today’s enterprise systems.