Engines Defined
Interface engines have been a logical market response to the need to close the logical distance between application systems. Also called "message brokers," they have emerged as a natural expression of the engineering axiom that each thing should do only that for which it was designed. Interface engines relieved applications of the management overhead of message delivery as well as the complexity of implementing and maintaining multiple message parsers.
Definitions
An interface engine is a software program designed to simplify the creation and management of interfaces between application systems. They are members of a class of software products called "middleware" that relieves applications and their systems-level communications substructure of the responsibility for owning and managing the functions of integration. Sometimes called "message brokers," engines themselves can fall into two broad categories:
| Interface Engine | An interface engine is a software system designed to simplify the creation of application interfaces between application systems. It commonly accomplishes this using the following approaches:
|
| Integration Engine | An integration engine is a software system designed to simplify the integration of application data and services. It commonly accomplishes this using the following approaches:
|
For practical purposes interface engines and integration engines can be considered roughly equivalent instances of a software solution to the challenges of integration. Their relevant difference is in the extent to which each attempts to offer its solution.
Architectures
The most common architecture for interface engines is a simple store and forward gateway scheme. Messages are received and queued so that the sender can be acknowledged immediately. Whether or not a message is solicited or unsolicited is usually incidental. A software program receives an unambiguously formatted message, and after validating it according to some configurable criteria, queues it to be forwarded to one or more destinations. The specific order of processing steps involved in translation and routing is frequently a matter of configuration.
Figure: Store and Forward Messaging
An emerging alternative to the common store and forward approach is a publish and subscribe architecture. Usually based on object-orient technology, publish and subscribe techniques can offer everything a store and forward engine does as well as provide additional application integration functions. Integration engines almost invariably use this architecture or one like it. From the outside, this approach looks basically the same as store and forward. Once the message has been received, however, it is generally translated into some standard intermediate form (normalized), stored or queued (published) to be picked up by one or more subscribers.
Figure: Publish and Subscribe Messaging
Where a target application is capable, it could theoretically retrieve its messages for itself. In practice, proxies pick up and forward messages within the engine for destination applications. The result is that both architectures will look quite similar in many production scenarios.
Typical Operation
In practice, an interface engine performs its work in three basic steps. The figure below illustrates a typical one-to-many transaction from a hospital Admission/Discharge/Transfer (ADT) system. Here ADT needs to communicate to various other systems some change in patient status. For the sake of this example, assume that a patient has arrived and been admitted.
-
The ADT system sends a message with relevant demographic and account detail to the engine. It is unaware of which or how many destinations may actually involved. It knows that it must receive an acknowledgement that the message was received successfully before it will transmit the next message.
-
The interface engine receives the message and after any necessary preliminary processing, queues it for delivery. Once a message is on queue, the engine guarantees to the ADT system that it will deliver it successfully to all the destinations, so it acknowledges receipt in anticipation of the next message.
-
The message is pulled from the queue and forwarded to each of the destinations. Which destinations and their locations are matters of engine configuration. If, for example, the laboratory system was down in this case, the engine would continue trying to transmit the message to the system until it came back on line. In the meantime, messages would continue to queue up.
Figure: Common Interface Engine Operation
Messages distributed from an ADT system illustrate some of the power of interface engine technology in its ability to take messages from one source and send them to multiple destinations. Many-to-one scenarios are conceivable, but generally more the domain of integration engines, which expand the possibilities with more sophisticated programming and application integration tools. This would be more an attribute of a composite application than a typical hospital workflow with ADT, orders management, clinical results, and billing—the main software clients for interface engines.
A more sophisticated application of this technology is a variation on the many-to-one approach. Occasionally, business workflow will require certain kinds of data to be aggregated, displayed, even managed in a way that none of the existing applications supports by itself. If the data from two or more applications could somehow be merged or made to look like one system, some benefit would result. Pulling data together and representing it this way through some kind of interface is just one example of what is called a "composite application"—an application composed of elements of other applications.
Figure: Composite Application
In a composite application scenario, an integration engine can provide much of the operational glue necessary to keep the various contributors synchronized as well as relieve each of the burden of knowing anything about other applications or their locations. Most healthcare applications are not evolved to the point where they can make objects or facilities easily available for this kind of object-oriented integration, so an integration engine could serve as a reasonable proxy.
Technical Notes
Engine vendors employ various technical approaches to constructing their products. A useful distinction is between the use of compiled versus interpreted elements in the system. Where compiled elements are used to construct the product and its interfaces, system performance tends to be very good, allowing for less hardware to do more work. Where interfaces and communications handlers are prepared in a high-level script language that is executed by an interpreter, more hardware is typically necessary to accomplish the same amount of work as a system using compiled elements. The advantage of a product that makes judicious use of an interpreter is its ability to insulate the customer from the upgrade pain that can result when an operating system vendor makes low-level changes that require recompilation of the engine software and all its interfaces. Interpreter-based products generally only require an upgrade to the interpreter.
This is an ambiguous area, however, and merits some specific attention when reviewing a vendor's interface/integration engine product. The specific questions are simple:
- How much of your product is dependent upon compilation and specific reference to operating system libraries?
- How much of your system is interpreted and independent of the underlying system?
- How does either of these answers influence performance and the hardware I need to buy?
- What will be the consequences for me if the hardware/operating-system vendor releases a significant upgrade?