lustratus LiteBytes

I thought this better be part 1, since I think this may have some way to run!

Lustratus was privileged to be invited to host a telecon discussion in the Integration Consortium SOA series, on the topic of SOA (service-oriented architecture) and EDA (event-driven architecture). The discussion proved extremely interesting, and got me to thinking more about trying to clarify the relationship of SOA, EDA, services and events. This is a subject Lustratus has been involved in for some time – indeed we produced a paper on EDA vs SOA recently.

This Lustratus report contained a table comparing the characteristics of SOA and EDA, the top line of which characterised the activity model of the two approaches – action-based for SOA and events-based for EDA. Action-based means that activity is driven by a user-initiated action, where user is in its broadest context. In other words, the SOA approach is based on services being driven to fulfill some user-driven operation, such as an order entry. The EDA approach is based on activity being driven when an occurrence, or set of occurrences, happens, such as a target sell price being reached to trigger a sale of a block of equities.

This is quite an interesting premise. Some people will say they are doing EDA because they are using an asynchronous message-driven connectivity bus such as WebSphereMQ or a JMS. After all, this is not synchronous but asynchronous, and therefore since events are asynchronous activities, this is EDA. But the previously stated premise would not class this as EDA, since the fact that the transmission of information between components is asynchronous is not relevant to the nature of the operation.

What if we take this further? So, I am performing an order entry service, and using an asynch message bus for communications, but I am running this from the laptops of my agents. When they meet with a client, and enter the order, there is no connectivity yet to the back-end system, so the request is queued, to be executed when the user hooks the laptop up to the phoneline at the end of the day. Is this EDA? After all, the event of the user hooking up to the back-end system triggers the processing of all the order entries.

I would claim this is not the EDA model, because the fact that asynchronous communications mechanisms, including queuing, are being used is an internal implementation detail – in terms of the business operation, the agent is driving a service to enter the order.

To me, the key is this. I may be using events as part of an implementation of a particular service, but the real question goes back to the activity model discussed at the start of this post – is the activity at the highest level, that is the business operation, user-driven or the result of a set of pre-defined occurrences happening. In the case just discussed, it is clearly still user driven.

Perhaps we should distinguish between events, and event-driven architecture. But similarly, we may need to distinguish between services and SOA. Turning things around, suppose I have implemented a particular business process in an event-driven architecture – perhaps these are compliance processes, where the system needs to watch and correlate operations to ensure that required limits are maintained. Activity here will be driven based on determination that an event has happened – for example the total exposure to a single supplier across all purchase orders exceeding a pre-defined limit.  This operation, triggered by the event occurring, may have a number of steps to be executed, such as generating a report of purchase orders concerned. But it may well make sense for these steps to be services in the SOA sense, to facilitate reuse etc.. So does this mean this is not EDA, but SOA? No, because the activity is event-driven even though services may be involved.

However, perhaps the top conclusion in all of this is that the A may be the real source of confusion. Architecture seems to imply that this is the choice for how IT systems as a whole are implemented – that in some way the choice of EDA or SOA is a binary one. In fact, everyone on the IC SOA call agreed that just about everyone will want to have both approaches, depending on the business process need. I guess as long as IT components are accessible as loosely coupled services, then they can be driven in either an event-driven or user-driven mode, and the choice of which will depend on what the process needs to do.

Steve