Previously in this column, I've discussed software tools that are invisible to the user, such as integration platforms and service-oriented architectures (SOAs). These mechanisms function in the background of information transactions and fall primarily within the purview of the IT department. However, they contribute individual technologies to (and are the support infrastructure of) the software tool that is the user's first point of contact: the composite application.
A composite application combines discrete functions and blocks of data drawn from other applications, Web services, and systems that coexist within an SOA. These independent components (a.k.a. services) can be accessed through standard interfaces by the other entities in the SOA, regardless of their native platform or programming language. Services can be combined in composite applications to support different functions, operations, and processes as needed.
Although a composite application can be assembled from both existing and new services, roughly 60%–70% is made up of existing functionality drawn from back-end applications (e.g., an existing database). "Composite applications are all about leveraging existing data and functionality that an organization already has, and building new applications, new functionality, and new interfaces on top of that," says Trevor Matz, managing director of Ensemble for InterSystems Corp., a provider of integration platforms.
Tools of the Trade
Composite applications use the same technologies that power integration platforms and SOAs. These include adapters, messaging buses, transformation and abstraction engines, and process modeling and orchestration.
An adapter is a prewritten block of code that allows the integration platform to speak to a targeted application via its native protocol, in much the same way that a network gateway allows two networks based on different protocols to exchange data. Once the adapters create the communication links, the messaging bus facilitates the distribution of data and functionality in the form of messages. Adapters and the messaging bus enable the integration platform to request and receive data and functionality from applications to create composite applications.
The transformation and abstraction engines provide the interoperability required to allow data and functionality from various applications to work together in a composite application. The transformation engine transforms data dynamically from one format to another, using preconstructed transformation maps. This ensures that all the data brought together in a composite application are in the same format. The abstraction engine presents the data and functionality in a standard way, allowing applications to invoke and use the data and functionality as if they were their own. Data and functionality become services accessible for composite applications, eliminating the need for the composite application to understand and work with the protocols and programming models used by each contributing application.
The process modeling and orchestration technology enables the integration platform to create a process that spans multiple applications. For example, let's look at a composite application handling quality control (QC) problems in an automobile assembly application. The application would take data from optical and color sensors, identify improperly assembled vehicles, separate them from those that meet factory standards, generate QC email alerts to assembly-line operators and factory managers, and notify suppliers of the additional material needed to meet production quotas. Thus, the composite application would collect data from multiple sources (sensor data and QC specifications) and combine functions (identifying QC problems, separating out the faulty vehicles, transmitting alerts, and notifying suppliers) to handle the process from end to end.
Software's Evolution
The development of composite applications reflects the changing attitudes toward the basic architecture of software and the way companies are willing to upgrade their applications' functionality. Before 2000, if a company found an application that provided more functionality than the software that it already had in place, it would rip out the installed software and replace it with the new application. This is not the case today.
"Composite applications reflect the fact that nobody really has the appetite anymore to rip and replace their existing applications," says Matz. "New applications have to leverage the functionality that exists within the applications of an organization and build on top of them. And this is just what composite applications do."
For more information: InterSystems Corp., Cambridge, MA; www.intersystems.com Trevor Matz, 617-621-0600
Tom Kevan is a freelance writer/editor specializing in information technology and communications.