Application integration brings a combination of problems. Each organization and trading community has its own set of integration issues that must be addressed. Because of this, it is next to impossible to find a single technological solution set and/or standard that can be applied universally. Therefore, each application integration solution will generally require different approaches. At this time, and in the foreseeable future, one-stop shopping is simply not an application integration reality.

Although approaches to application integration vary considerably, it is possible to create some general categories. These approaches include:

• Information-oriented
• Process integration-oriented
• Service-oriented
• Portal-oriented

Information-Oriented Approach
Technologists who promote the information-oriented approach to application integration argue that integration should occur between the databases (or proprietary APIs that produce information, such as BAPI) - that is, databases or information-producing APIs should be viewed as the primary points of integration. Within information-oriented application integration, there are many approaches. Information-oriented solutions can be grouped into three categories: data replication, data federation, and interface processing.

Data replication is simply moving data between two or more databases. These databases can come from the same vendor or from many vendors. They can even be databases that employ different models. The fundamental requirement of database replication is that it accounts for the differences between database models and database schemas by providing the infrastructure to exchange data. Solutions that provide for such infrastructures are plentiful and inexpensive, and many leverage common XML as the canonical format, accounting for the differences in schema using XSLT.

Now known as EII (enterprise information integration), database federation is the integration of multiple databases and database models into a single, unified view of the databases. Put another way, database federations are virtual enterprise databases that comprise many real, physical databases. Although database federation has been around for some time, the solution set has been perfected only recently.

Database federation software places a layer of software (middleware) between the physical distributed databases and the applications that view the data. This layer connects to the back-end databases using available interfaces and maps the physical databases to a virtual database model that exists only in the software. The application uses this virtual database to access the required information. The database federation handles the collection and distribution of the data as needed to the physical databases.

Interface-processing solutions use well-defined application interfaces to focus on the integration of both packaged and custom applications. Currently, interest in integrating popular ERP applications (e.g., SAP, PeopleSoft, and Oracle) has made this the most exciting application integration sector. These interfaces, while producing mostly data, also have the ability to act as an application service provider as well, and in many cases produce XML and leverage Web services interfaces. SAP, Oracle Financials, and PeopleSoft are examples of application interfaces that leverage XML standards in one shape or form.

Process Integration-Oriented Approach
Simply put, process integration-oriented products layer a set of easily defined and centrally managed processes on top of existing sets of processes contained within a set of enterprise applications. In the world of Web services we are calling this orchestration, leveraging standards such as BPEL. The concepts are almost exactly the same.

Process integration is the science and mechanism of managing the movement of data, and the invocation of services in the correct and proper order to support the management and execution of common processes that exist in and between applications. Process integration-oriented application integration provides another layer of easily defined and centrally managed processes that exist on top of an existing set of services and data contained within a set of applications.

The goal is to bring together relevant processes found in an enterprise or trading community to obtain the maximum amount of value while supporting the information flow and control logic between these processes. These products view the middleware, or the plumbing, as a commodity and provide easy-to-use visual interfaces for binding these processes together.

In reality, business process integration is another layer of value resting upon existing application integration solutions, solutions that include integration servers, application servers, distributed objects (such as Web services), and other middleware layers. Process integration offers a mechanism to bind disparate processes together, and to create process-to-process solutions that automate tasks once performed manually.

Service-Oriented Approach
Service-oriented application integration allows applications to share common business logic, or methods. This is accomplished either by defining methods that can be shared, and therefore integrated, or by providing the infrastructure for such method sharing such as Web services. Methods may be shared either by being hosted on a central server, by accessing them inter-application (e.g., distributed objects), or through standard Web services mechanisms such as .NET.

Attempts to share common processes have a long history, one that began more than 10 years ago with the multitiered client/server - a set of shared services on a common server that provided the enterprise with the infrastructure for reuse, and now, for integration - and the distributed object movement. Reusability is a valuable objective. A common set of methods among enterprise applications invites reusability and, as a result, significantly reduces the need for redundant methods and/or applications.

While most methods exist for single-organization use, we are learning that there are times when it makes sense to share between organizations. In a new twist on the longstanding practice of reusability, we are now hoping to expand this sharing beyond intra-enterprise to trading partners as well. For example, sharing a common logic to process credit requests from customers, or to calculate shipping costs using a set of Web services.

Portal-Oriented Approach
Portal-oriented B2B application integration allows us to view a multitude of systems - both internal enterprise systems and external trading community systems - through a single user interface or application. Portal-oriented application integration benefits us by eliminating the back-end integration problem altogether by extending the user interface of each system to a common user interface (aggregated user interface) - most often a Web browser. As a result, it integrates all participating systems through the browser, although the applications are not directly integrated within or between the enterprises.

While the other types of application integration are focused on the real-time exchange of information (or adherence to a common process model) between systems and companies, portal-oriented application integration is concerned with externalizing information out of a multitude of enterprise systems to a single application and interface. That's clearly an approach that goes against the notions of the other types of application integration, which are more real-time and event-driven oriented.

Application integration, while typically referring to the automated movement of information or the binding of processes between two or more applications, without the assistance of an end user, can clearly also occur at the user interface. Indeed, most examples of B2B information exchange today are also examples of portal-oriented application integration.