If integration blends data, applications, and processes into a functioning, unified whole to provide a single view of your operations, then the integration platform is the medium that delivers this bounty of information. But what is an integration platform? Basically, it's software. Specifically, it's the underlying software infrastructure, processes, tools, and development environments that enable heterogeneous networks to communicate. It's no longer good enough for sensor and sensor systems designers to build products that deliver their data only via an analog signal. Increasingly, operations managers and engineers are asking for devices that accommodate and support integration platforms.
"Integration is part of a bigger framework—the middleware framework," Amlan Debnath, vice president of server technologies for Oracle Corp., recently observed. "Over the years, I have seen integration go from black art in the early days to a mainstream technology that people now accept as a necessary part of any application-building framework. "
In response to these demands, integration has gone into the application-building domain. The integration platform has become an application-building framework based on three main elements: connectivity, abstraction, and process modeling and orchestration.
Connectivity creates a communications channel between the integration platform and each of the applications being integrated. Most platforms use adapter libraries and adapter-development frameworks to achieve this. Adapters are prewritten pieces of code that speak to the targeted application via its native protocol. An adapter-development framework is an environment in which you can build custom adapters to connect to applications that you cannot reach via any of the platform's prebuilt adapters.
For more information on integration
Once the adapters link the integration platform with each application, information is distributed in the form of messages. Most platforms use messaging engines—the components responsible for the queuing, routing, sending, and receiving of the messages circulating throughout the integrated system—to manage the flow of information.
"Historically speaking, this body of technology was called a message broker," says Trevor Matz, managing director of Ensemble for InterSystems Corp. "The core of the integration platform is the messaging component."
Before messages are routed, the information must be converted to the correct format.
For example, in Application A, machine monitoring information is formatted in such a way that the name of the machine appears in the first field and the machine manufacturer's name appears in the second field. There are two address fields followed by a field for the name of the facility. In Application B, however, the first field is the name of the machine, which includes the name of the manufacturer. The address could be three fields rather than two, with the third field containing the name of the manufacturer. As a result, you couldn't take information as it is formatted in Application A and input it into Application B because there would be a mismatch between the data.
At this point, the transformation engine (which is part of or sits on top of the messaging engine) dynamically transforms data from one format to another using preconstructed transformation maps. This allows information entered into one application to be fed automatically to another. In this way, the information in both applications can be kept up-to-date.
The next major element of the integration platform is abstraction. This mechanism presents the data and functionality of each application in a standard way, allowing other applications to invoke and use the data and functionality as if they were their own. In this way, data and functionality become services accessible to all of the applications in the integration system. This eliminates the need to understand and work with the various protocols and programming models used by each application. Some common approaches to abstraction are Web services and XML.
Process Modeling and Orchestration
The final element—process modeling and orchestration—allows you to model functionality graphically and define how you want a process to execute without having to think about the underlying code involved in automating the process. Many integration platforms include graphical tools for process modeling, and some generate XML code from the process diagrams.
The process modeling component enables you to create a process that spans multiple applications. The integration platform abstracts each function, or service, required from the applications. The process calls the service, and the service goes into the messaging engine, calls the appropriate adapter, goes into the message queue, and the process picks it up and sends it to the appropriate application.
For instance, you could model a process that viewed the status of machines in real time and alerted you when they were functioning at a less than optimal level. The process would run an application that monitors the status of a machine, trigger another application that analyzes the machine's performance, and support a third application that alerts a technician if there were a problem. The applications are not viewed as separate entities; rather, they are seen as a holistic, unified application.
This holistic view typifies not only the process modeling and orchestration component but also the integration platform and the integration process as a whole. It is the operating principle and the goal all rolled into one.
Tom Kevan is a freelance writer/editor specializing in information technology and communications. firstname.lastname@example.org