Monday, April 30, 2007

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: , ,

7 comments:

Anonymous said...

The example you have chosen can be serviced both by EDA as by "traditional WS" because it is an asynchronous service. EDA is an architecture that allows only for asynchronous services, if the business requirements would change and demand that the service is carried out in a synchronous fashion (say the service should give you a reference number for your request that needs to be passed to another system, say a budgeting system) EDA will hardly fit the bill. EDA, in my opinion, pins the service down to a very specific implementation and puts a barrier to change. I see EDA as another gateway into an application which should be mapped easily to a specific process rather than an architectural construct.

I concur with your ideas that the business side should not get too technical, but this doesn`t mean that everything out there can foot the bill. At the end of the day the architecture matters...

Anonymous said...

As we've built up our services library and SOA connections here at our Fortune 500 IT shop, along with our host of older technology inter-application connections (MQ, batch, FTP, RMI, RSP), we've reached the point where we need an enterprise class tool & methodology to catalog and graphically display these connections.

We're not looking to tie in any kind of real time monitoring across this (though that would certainly be nice in the future). Rather, we're looking for a catalog we can manage that will provide updated graphical representations of the inter-application connections, along with the ability to search the catalog for certain exposed functions.

Do you have any recommendations in this space?

James Taylor said...

SOA and EDA are complimentary as are EDA and BPM. They represent different ways to bring services (components) together to solve business problems. I would go further and say that decision services are the right way to bring rules into SOA. I have blogged before about SOA, BPM, CEP and business rules and why business rules matter in an event-driven SOA. I think event driven design is particularly suitable for what I call transaction-centric decisioning too and that's a good thing.

I also recommend two articles in SOA magazine - this one on business rules in SOA and this one on SOA and EDA.

Anonymous said...

Why Web Services? http://www.loudthinking.com/arc/000602.html

Anonymous said...

You really don't understand what an EDA is. This is clearly shown by the event-based design you make of the business scenario and sentences like "In the event based world its what the destination service is waiting to happen from the consumer"...

In the event-based world there are no destination services...

In the event-based world you wait for things to happen, but not from particular services (or consumers? ;-)). Producers and consumers are decoupled, they do not know each other (i.e. in your scenario the wareouse service would have no knowledge of the existence of the finance service and viceversa)...

In the event-based world events are first-class citizens and have a type (much like classes have in OO), a service's interface defines the event types the service is interested in and the event types the service ewmits; a middleware in between (i.e. commonly called event bus) delivers event instances to services according to the services' interfaces and explicit event routing/transformation rules that are incorporated to the event bus...

Your opinion that EDA is just irrelevant reminds me of the good old times when OO was born. Many people then, the ones who did not understand OO, kept saying that object-orientation was just a different style of procedural programming and that it was irrelevant and that it was just an implementation decision ;-)

Steve Jones said...

I knew that someone would think that I was having a dig at SOA/REST/EDA or whatever. I'd hoped that that person wouldn't have gone to the old "you don't understand it".

"patternstorm": I'm not saying that when you do implementation that it isn't important to choose the right approach but that from a business perspective its a good thing if they don't care about that implementation.

I do know that the implementation goal of EDA is to enable listening for events, but my point is that the business will (at this stage) articulate that as "on dispatch from the warehouse" now you might then choose to use EDA because there are lots of warehouses with new ones all the time and also you are using 4PL companies so some of them aren't even under your control.

That is my point. Hide the implementation details from the business, your job is to deliver flexibility and change to the business within their language, not in terms of the IT implementation.

For the business OO is an implementation detail. It isn't for IT because THAT IS WHAT WE ARE PAID FOR.

Do you care how the internals of your car engine management system work? Nope, you just care that it works. That is the service we should offer to the business, not a series of IT buzzwords disjointed from their business context and language.

PetrolHead said...

Patternstorm said:

"In the event-based world you wait for things to happen, but not from particular services (or consumers? ;-)). Producers and consumers are decoupled, they do not know each other (i.e. in your scenario the wareouse service would have no knowledge of the existence of the finance service and viceversa)...

In the event-based world events are first-class citizens and have a type (much like classes have in OO), a service's interface defines the event types the service is interested in and the event types the service ewmits; a middleware in between (i.e. commonly called event bus) delivers event instances to services according to the services' interfaces and explicit event routing/transformation rules that are incorporated to the event bus..."

Let's distill this down then - how do you register for events?

(1) Expose what events your interested in.

(2) Expose (1) to some entity that can supply the events.

So you have to know who to register with and what you want to ask for - could be you register with an event bus or some service. You can argue there's some additional level of de-coupling but it comes with several costs:

(1) You can't really be sure that the thing you want events from is posting them out via the same intermediary as you're listening to.

(2) The only way to avoid (1) is to have some single conduit that routes and dispatches all events across an entire system.

(3) If you want to avoid (2) for which there are good reasons such as organizational boundaries or scaling then you need to partition your event types across multiple brokers and your consumers potentially have to know which broker(s) to connect to.

As usual it's a bunch of tradeoffs and the choices you make today mightn't be great for tomorrow.

And the message as always is, there is no single solution that works under all circumstances for all time. Thus EDA and SOA are complementary approaches - it's wrong to focus exclusively on one or the other.

Which leads to where Steve came in:

What matters is the business - EDA or SOA at implementation level is a detail and it varies depending on circumstance.

Dan.
http://www.dancres.org/