In Event driven architectures, applications react to events being sent to them - most of which originate internally from other closely cooperating applications. Event distribution is performed using messaging systems such as JMS servers, MicroSoft MSMQ, IBM MQ Series, Tibco Rv, etc (these messaging platforms are also the underpinnings for most SOA/ESB platforms). At the very core of these messaging systems, they enable sharing of data with other applications by pushing events to other distributed processes through an asynchronous delivery channel. The sender is not affected either by the availability or the speed at which the receiver operates.
When you have several closely cooperating applications, what they typically want is sharing of information along with events. For instance, the application that takes in customer trade orders notifies the application that r outes the order to a trading exchange on the arrival of the order, but also has to share related information such as customer credit or delivery information. The common architectural pattern is to combine traditional messaging, used to notify events between applications with common databases to share the required contextual information.
There are numerous challenges/issues with this approach. Some are listed below:
Therefore, "closely cooperating" applications are better enabled by a new class of middleware data management infrastructure offering - technology that manages data in distributed main memory and combines this with the event management semantics found in high performance messaging. We refer to this class of middleware software as the 'data fabric' (also referred to as Data Grid).
Essentially, the data fabric manages large quantities of fast moving data along with steady state or historical information primarily in distributed main memory. Applications can register interest in what looks like a database rather than on messaging destinations (topics) and the applications are guaranteed to receive asynchronous notifications with the same reliability semantics like a messaging system. This allows applications to provide complex and sophisticated interest registrations like through the use of a complex query expression that joins multiple domain data types. Depending on the application usage, the data fabric can be configured to make multiple copies of data resident close to the application that is consuming it or spread the data across many nodes or a combination of the two. When data is updated it merely calculates the "delta" - how the data compared to what is already stored has changed and merely ships the change to consumers dramatically saving on distribution costs that would otherwise be incurred. As the publisher and consumer both operate on a data model that enforces constraints and relationships, data consistency is always preserved.
We would like to provide the motivation for architects and developers alike to take a deeper look at a new data/event distribution development model – one that is information centric instead of being message centric.