Figure 1: Data Integration vs Application Integration

(Article guest authored together with Syed Rasheed, Senior Principal Product Marketing Manager at Red Hat in North America)

One of the prime issues for someone examining their enterprise integration options is the question of how does Data Integration compare to Application Integration. These are two very different aspects in an organization as noted in Figure 1.

There are myriad of integration technologies and information exchange patterns and broadly speaking, integration solution typically falls under into one of two styles.

Application Integration

Also known as Process Integration, it's used for integration of end-to-end business processes that cut across application or functional boundaries where multiple applications need to be orchestrated as part of automation of business transaction. This type of integration usually helps to accelerate development of integrated systems processes solutions. 

JBoss Fuse is ideally suited for this type of integration and often complimented by JBoss BPM Suite to add business process automation services. 

Data Integration

This is used for accessing data and functions from disparate systems to create a combined and consistent view of core information for use across the organization to gain necessary insights and improve business decisions and operations. This type of integration usually helps to accelerate development of business intelligence systems. 

JBoss Data Virtualization is ideally suited for this type of integration.

Interestingly both integration tools, JBoss Data Virtualization and JBoss Fuse, deal with data abstraction, federation, transformation and meta-data. They also feature connectors and service oriented architectures.

Interchangeable?

The burning question is, are they interchangeable?

The answer is no.

The key difference is that in application integration, data is treated as a special type of  process step that typically contains a SQL statement to execute against a source. A service end point has a static or fixed service interface for executing a particular piece of business logic within an application.

That logic may retrieve data or it may update data in the course of its execution, but the primary purpose is the access to and  integration of the business logic for use in business processes. The artifact created by application integration platform like JBoss Fuse is a service that might contain a query,  but it cannot be queried.

This is important.

With data integration we attempt to rationalize, unify and abstract data sources for use by applications and business processes. In that sense, data virtualization platforms can be thought of as residing below application integration platforms in classic architectural block diagrams. They are enabling easier and more efficient data access by the application integration platforms or other mobile, enterprise applications and/or business intelligence and reporting tools. 

The primary interface presented by data virtualization platforms is the more dynamic relational data model, as opposed to the more static service interface. Exposing data in tables and views enables application consumers to decide in what shape they wish to consume the data versus the service provider.

Consider a simple example where:

• Customers reside in a table in one database
• Orders reside in a table in a separate database
• An application requires unified data combining customers and orders

In any type of application services integration platform, one would create a  getCustomers service and a  getOrdersservice using database adapters. One would then write a new service –  business logic – that invokes both of those base services to get the data from each database and then create transformation code to copy and merge the data into a unified result set. The application would then be able to invoke that top level service to get the unified data in the structure defined by the services platform. 

If the developer of the top level service did not allow for parameters to order or project different attributes or select subsets of rows, the application developer would be forced to do that work themselves or request that a new service be created. 

This is a static model for data access.

In a data virtualization platform, one would expose the customer and order tables as views to the application. The application would then connect to the data virtualization platform via standard Java Database Connections (JBDC) and issue a standard SQL query that joins the data from the two tables to retrieve the data. The application is free to dynamically change the SQL to order, project or select any subset of the data they wish at run time. 

This is not fixed by the static service definition.

Data virtualization platforms also have the ability to provide service interfaces. In fact data services bring the long desired alignment between traditionally isolated application and data integration technologies stacks. With the data services model, differences between the application integration and data integration blur, but they do remain. 

In that scenario, the data virtualization platform will generally provide a much quicker time to market and higher performance as standard SQL is used to define the services while the data virtualization platforms do the heavy lifting of optimizing the joining of the data through query optimization. 

In service integration platforms, the optimization of joining the data is the responsibility of each individual developer. It is highly unlikely that the individual services developer would build in the logic to dynamically select between a large collection of join algorithms depending on the inputs and shape of the sources. 

Looking to Automate your business?

Data virtualization optimizers do that and more.

The Bottom Line

In the end, application integration platform like JBoss Fuse are best suited for the functional integration of independent applications to implement a multi-step business process. Data virtualization platforms are best suited for the creation of data services where one is attempting to present a holistic view of the business data for analysis or operational visibility. Both technologies have different primary use cases and they are not interchangeable, however they can be used together.


[Feedback welcome, for more information feel free to contact the author through comments below or  @junooni, or visit  Red Hat Integration.]