The goal of data consistency is to get multiple application systems, typically spread across disparate business units, to agree on data. Data consistency is always an issue when two or more databases hold information on the same subject, such as a customer address. A change in the originating application needs to be reflected in the target application(s). Data consistency is typically achieved by posting the update event to a publish/subscribe messaging-middleware (MOM) platform for immediate delivery to one or more receiving applications. The sender and receiver typically remain logically independent in the sense that both applications keep running indefinitely even if the communication breaks down (though the data would become increasingly out of synchronization). Data consistency integration thus involves unrelated applications/processes, one-way transfer of data and batched or individual (event-driven) message transfers. Because of these characteristics, data consistency patterns are best implemented via events, which allow updates to happen remotely in a decoupled manner, without constraining the operation of the sending and receiving applications.
A multi-step process is a business process that consists of a sequence of distinct steps, each of which is executed by an application system or via human intervention. Examples of such processes include, among others, processes to manage purchase orders, insurance claims, or financial transactions, each of which has a life-cycle that consists of steps that take a finite amount of time (seconds, hours or days). A multi-step relationship involves distinct applications participating in a single (typically distributed) business process, separate "steps" within the business process, a one-way transfer of data between steps, and batch or individual message transfers between steps. Each step within a multi-step process is typically executed by a separate application, which may be implemented at different times by different business units. Importantly, the applications participating in a multi-step process are logically dependent on each other, since the output of one application is the input to the next. This characteristic differentiates multi-step processes from data-consistency applications. Since the flow of data and events in a multi-step process is one-way, multi-step processes (like data consistency applications) are best implemented via events and event-enabled middleware.
A composite application is a software assembly consisting of
multiple coupled components, each of which is heterogeneous in its
information architecture. An example of a composite application is
servlet component that invokes one more databases in response to a
user-request, sends data to a separate enterprise application,
blocks until the result-set is available from both operations and
then returns the result to the caller. Composite applications
typically consist of client and server modules between whom the
relationship is always request/reply, ensuring tight-coupling (even
though the clients and servers may be modular business components).
Clients call into server modules and suspend processing until a
reply is received. Clients and servers in a composite application
use various connection-oriented middleware technologies, including
COM (Component Object Model), CORBA (Common Object Request Broker
Architecture), RMI (Remote Method Invocation), or raw TCP/IP
sockets, as well as connectionless middleware such as SOAP (Simple
Object Access Protocol) over HTTP or message-oriented middleware (
MOM ). A complete composite application typically serves as a single
step in a larger business process (such as a database consistency
flow or a multi-step process).