Event Driven Architecture (EDA) has had less press than its relation, Service Oriented Architecture (SOA), but it is probably going to be just as important.

The definition of EDA begins with a business event, which is anything that changes the status of the business in some way. The events can be of varying importance ranging from a major event, such as a customer placing an order, to a more trivial event, such as a product with an RFID tag passing a sensor, or it could even be a clock tick that signals the start of a new price list.

All of these business events can be represented in the IT world by a message, and in the EDA world that will be an XML message. EDA defines two concepts around these messages:

• Streams of messages
• Agents that influence these streams

The agents can be categorised into:

• Generator agents that create new messages based on external events
• Processor agents that process events
• Integration agents that ensure that generated events are routed to all the processor agents that need to process them

In this article I want to concentrate on the technology required to support a processor agent. A processor agent is an application driven by a stream of messages. It is given a message; it processes the message including persisting some data. It may also return a message to the generator or generate new events for consumption by other agents. It could further consume services using standard SOA interfaces.

The developer of a processor agent should be able to write it as if it was a single thread and there were no other related tasks running concurrently. Writing in this way removes much of the complexity required to ensuring scalability, determinism and persistence. Removing this complexity obviously reduces the cost and time required for the development.

WareLite Business Operating Support System (WL BOSS) provides the development environment and infrastructure for developing processor agents in this way. WL BOSS has four main components: the node manager, persistence driver, the global lock manager, and the integrated development environment.

The node manager is the environment within which a processor agent runs. When the node is idle the node manager interrogates a message queue (in the current release this is a Microsoft MSMQ queue, but future releases will support other queue managers), and based on the event type on the queue and the role of the event generator, the node manager will pass the event to the correct agent. One queue can be serviced by multiple nodes, and these nodes can be on multiple hardware nodes. The ability to connect multiple node managers to one queue provides a simple linear scalability. It also provides inherent reliability because if one node fails the others will carry on unaffected.

The persistence driver is the interface to a persistent data store (in the current release this is Microsoft SQL Server, but future releases will include other persistence technology). WL BOSS uses the persistence store as a bucket and does not depend on the persistent store to provide scalability or determinism. The drivers decide where the data should be stored and can store one object type across multiple physical databases if that will provide the required scalability and performance. The mapping of data onto the physical implementation is defined by parameters outside the application and can be changed without any change to the processor agent.

The global lock manager's role is to provide locking across the different nodes and different persistence stores. Deadlock detection is provided and this is coordinated with the node managers.

At first sight it was not clear to me what made this technology different as most of the concepts are not new and have been implemented many times before. However, on closer inspection it became obvious that by developing this infrastructure only to support EDA processor agents it has been possible to fully support scalability, determinism and persistence in a much simpler way. The benefits of the simplicity are higher performance, lower cost and simpler implementation.

Although this is a general purpose solution I expect that its early use will be to process new types of events; these might include RFID, other types of positioning sensors, ticketing applications etc. In all these situations the low cost of processing and the scalability should make it very attractive.