SOA, EDA, and CEP a winning combo
Saturday, November 1st, 2008.
There’s been some discussion on the SOA yahoo group around the connection between SOA, EDA, and CEP (complex event processing) since Jack’s original post on the topic. I’ve been waiting for the right opportunity to jump in and it seems to have come.
Dennis asked this:
There are different design choices in a SOA, even when you already have identified the services. I have a simple example that I would like to share:
Imagine a order-to-cash process. One part of that process is to register an order. Suppose we have two services, Order Service and Inventory Service. The task is to register the order and make a corresponding reservation of the stock level. I would be pleased to have the groups view on the following 3 design options (A, B, C):
A.
1. The “process/application” sends a message (sync or async) to “registerOrder” on the Order Service.
2. The “process/application” sends another message (sync or async) to “reserveStock” on the the Inventory Service.B.
1. The “process/application” sends a message (sync or async) to “registerOrder” on the Order Service.
2. The Order Service sends a message (sync or async) to “reserveStock” on the the Inventory Service.C.
1. The “process/application” sends a message (sync or async) to “registerOrder” on the Order Service.
2. The Order Service publishes an “orderReceived” event.
3. The Inventory Service subscribes to the “orderReceived” event .
On the whole “already identified the services” thing - naming a service doesn’t mean much. It’s all about allocating responsibility, and until that’s been done, those “services” don’t give us very much information.
Business Services
If we were to view this example in light of business services, and look at the business events that make up this process, maybe we’d get a different perspective.
Three business services: Sales, Inventory, and Shipping.
In Sales, many applications and people may operate, including the person and the application he used to submit the order. When the order is submitted and goes through all the internal validation stuff, Sales raises an OrderTentativelyAccepted event.
Inventory and Orders
Inventory, which is subscribed to this event, checks if it has everything in stock for the order. For every item in the order on stock, it allocates that stock to the order and publishes the InventoryAllocatedToOrder event for it. For items/quantities not in stock, it starts a long running process which watches for inventory changes.
When an InventoryChanged event occurs, it matches that against orders requiring allocation – if it finds one that requires stock, based on some logic to choose which order gets precedence, it publishes the InventoryAllocatedToOrder event.
Sales, which is subscribed to the InventoryAllocatedToOrder event, upon receiving all events pertaining to the order tentatively accepted, will publish an OrderAccepted event.
Orders and Shipping
When Inventory receives the OrderAccepted event, it generates the pick list to bring all the stock from the warehouses to the loading docks, finally publishing the PickListGenerated event containing target docks.
When Shipping receives the PickListGenerated event, it starts the yard management necessary to bring the needed kinds of trucks to the docks.
What else is possible
I could go on, talking about things like the maximum amount of time stock of various kinds can wait to be loaded on trucks, subscribing to earlier events to employ all kinds of optimization and prediction algorithms, having a Customer Care service notifying the customer about what’s going on with their order (probably different for different kinds of customers and preferred communication definitions). Obviously, we’d need a Billing service to handle the various kinds of billing procedures, whether or not the customer has credit, pays upon delivery, etc.
It turns out that many business domains map very well to this join of SOA and EDA.
What an ESB is for
When we have these kinds of business services primarily publishing events and subscribing to those of other services, you don’t need much else from your “enterprise service bus”. All sorts of transformation, routing, and orchestration capabilities don’t come into play at all.
In all truthfullness, those bits of functionality are really just a historical artifact of their broker heritage.
Don’t get me wrong, sometimes a broker is a nice thing to have - behind a service boundary in order to perform some complex integration between existing legacy applications.
Just keep that stuff in its place - not between services.
Complex Event Processing
We can look at how Sales transitions an order from being tentatively accepted to being accepted as requiring event correlation around InventoryAllocatedToOrder events. This isn’t exactly “complex” in its own right. If there were some kind of CEP engine that did this for us out of the box, it might be a possible technology choice for implementing this logic within our service.
As we add more concerns, like time, we may find new ways to make use of this engine. For instance, if the time to provide the order to the customer is approaching, we may choose to split the order into two - accepting one for which we have all the stock allocated, and leaving the second as tentatively accepted.
Summary
While it is difficult to move forward on service responsibility without discussing the events it raises and those it subscribe to, the whole issue of CEP can be postponed for a while.
Although there aren’t many who would say that EDA is necessary for driving down coupling in SOA, or that SOA won’t likely provide much value without EDA, or that SOA is necessary for providing the right boundaries for EDA, it’s been my experience that that is exactly the case.
CEP, while being a challenging engineering field, and managing the technical risks around it necessary for a project to succeed in some circumstances, and really shines when used under the SOA/EDA umbrella, it should not be taken by itself and used at the topmost architectural levels.
Related Content
And if you’re wondering about how to handle all that complexity inside services (different kinds of billing, periodic tests for electronics inventory, etc), you might like listening to this podcast about business components.
|
If you liked this article, you might also like articles in these categories: 
If you've got a minute, you might enjoy taking a look at some of my best articles.I've gone through the hundreds of articles I've written over the past 4 years and put together a list of the best ones as ranked by my 2000+ readers. You won't be disappointed.  If you'd like to get new articles sent to you when they're published, it's easy and free.Subscribe right here. Something on your mind? Got a question? I'd be thrilled to hear it. Leave a comment below or email me, whatever works for you. 10 CommentsYour comment... |
November 1st, 2008 at 6:13 pm
Hi Udi,
Good post! I totally Agree with this idea. SOA is a good pattern to clearly separate the different responsibilities within the application Then use EDA to have these Services communicate with each other. This gives a very high grade of louse coupling and with that all the nice abilities to make changes easier. I have been thinking about combining EDA with DIP as a technical pattern with the main purpose to make change easy (http://blog.fohjin.com/2008/09/no-dependency-architecture-nda.html). Adding SOA to this seems like a logical next step, I will definitely look more into this.
Thanks,
-Mark
November 2nd, 2008 at 11:26 am
Now you really are my friend, Udi. Excellent post!!
-Jack
November 2nd, 2008 at 4:50 pm
Mark,
Glad you liked it.
November 2nd, 2008 at 4:51 pm
Jack,
We need more people fighting the good fight
November 5th, 2008 at 7:53 am
Nice article. I follow Jack fight
What I do not like on it is following:
You call Sales, Inventory and Shipping “business services”. Actually there are three different component types: Services, Event producers and Event reaction processes (these are not reusable and catalogized in the same way as services or as events; http://it.toolbox.com/blogs/system-integration-theory/eda-soa-crossproject-documentation-26215).
ESB is still needed - for implementation of reaction processes and simple composite services (e.g. routing/transformation). Again ESB tools should differentiate between these three component types
(http://it.toolbox.com/blogs/system-integration-theory/what-does-the-letter-s-in-jbossesb-mean-27069)
We need to differentiate when to use event-driven communication for your example and not one-way command? It is not about loosely coupling only probably… (I tried to find out answer in http://it.toolbox.com/blogs/system-integration-theory/would-you-like-service-or-event-sir-26243; but it is not so easy…)
November 5th, 2008 at 2:43 pm
Peter,
I accept that you have a different opinion on the definition of “service” than I do. Apparently, it’s not just the two of us - everyone has their own definition
For me, I’ve given up on the whole reuse thing. I think it’s a crock. Has been since OO.
Also, as the example in my post describes, we can see the same thing being both an event producer and “reaction process” as you call it for different kinds of events.
I’ve read the posts you linked and it appears that you take an integration perspective on SOA. I perceive integration as something that occurs within the context of a single business service.
Anyway, glad you commented and I’m looking to hearing more from you.
November 6th, 2008 at 1:28 am
It is strange that European union standardize what is banana (and has exact criteria)… They should standardize notion of integration service
November 20th, 2008 at 4:32 am
Hello,
Congratulations, your post is the clearest view relating the combined use of SOA and EDA principles for Information systems specification I have ever seen. I am a “lonesome cowboy” fighting in the arena of a Telco operator and talking alone about EDA in the last years. Your clear objective view of the benefits of EDA + SOA and their complementary role will be determinant to open some minds around here. Thanks.
Mário Rui da Costa
of
November 21st, 2008 at 2:20 pm
Mário,
Glad you liked it.
And never underestimate the power of the lone ranger
December 7th, 2008 at 3:47 am
[…] More in depth example on events and pub/sub between services […]