SOA v EDA - The business don't care and neither should you

The old EDA v SOA or SOA 2.0 view is still doing the rounds I note, which isn't surprising given the technology focus of lots of companies. But I thought I'd try very very briefly to explain what the difference is and why from a business perspective it isn't important what the implementation approach is.

Business Scenario

Okay so the scenario will be a standard supply chain where the invoice is sent out at the same time as dispatch from the warehouse. Using the SOA Methodology this gives us two "what's"
A who
and a few "why"s one of which goes between the two services.

So that is the business view. The next bit is to compare the Event based and request based implementation of that single why between the services. The direction, from a business perspective, is clearly from the warehousing to finance as that is what works in the business language for this scenario, this however doesn't matter to the technical implementation of the services. They key as with Christmas SOA is understanding how the business objectives can be met by technology, not trying to do a one-to-one match.

Request based

So what is the implementation in a request/reply world? Well clearly we have two services to build from above, but the question is what is the implementation approach for the request. The key with a request implementation is that the question is "I need to ask the other service to do something" hence its all about the destination service in the request. In plain old pseudo code this means

service Finance has

SendInvoice capability, which accepts a purchase order and customer details

This is the "traditional" Web Service way of thinking about things (although of course REST would be a post of an invoice as the code implementation). This is fine and dandy and clearly meetings the requirements of the overall business scenario.

Event based

In the event based world the question is about what has happened that will trigger a change. In this world its what the destination service is waiting to happen from the consumer. So in old pseudo code terms this means that we have two definitions.

service Warehouse has

DispatchOrder capability which sends an order dispatched event on completion

service Finance has

SendInvoice capability which listens for dispatched orders

This is the "traditional" Event way of thinking about things. Again this meets the business capability.

Pseudo Event - Polling for requests

There is a "third" (and in my opinion often technically poor) way of working which is to pretend you are event based but really its building an event model by using polling on requests. In this world the Finance service would continually put a request into Warehousing to ask "have any orders been dispatched" so back in pseudo code we have

service Warehouse has

DispatchedOrders capability which returns a list of the recently dispatched orders

In this case its sort of like Warehouse publishing an RSS feed of dispatched orders and Finance subscribing to that feed, or in old school speak its like Warehouse dumping a batch file at the end of the day to a shared disk and Finance uploading it. This again meets the business objective.

Summary

My point here is that whether doing Request/Reply, Eventing or Polling this is an implementation decision and is irrelevant from the business perspective. The key is to understand the best implementation method that meets the business objectives, this will be based on performance, timeliness and other "ilities" or just down to "how the current systems work". This separation of the business objectives from technology implementation is part of the key to making sure that IT moves in step with the business, you need to make IT deliver in business terms which means understanding the objectives rather than blindly implementing the requirements. Request/Reply, EDA, Polling, BDI and the like are all just technical implementation approaches to meet the business objectives. They are tools in the toolbox, and they are about design rather than architecture.

SOA, as in Business SOA, is about architecture, then choose the right tool for the implementation job.

Technorati Tags: SOA, EDA, Service Architecture