|
January 2008
January 21, 2008
Don't EDA between existing systems
In Nick Malik's great post, EDA: Avoiding coupling on the name he describes additional "handshakes" to be used to avoid the following problems:
Let's say I have a system to handle a call center for financial services or telco. When a customer calls on the phone and asks to be enrolled in "Heavily Advertised Program ABC," there may need to be three or four systems that interact to make that real.
...
Harry asks me to consider using a 'logical name' of the receiver. The sender contacts a logical end point, the addressing infrastructure turns that into a physical end point, and we still have decoupling.
Honestly, I like it but I think it is insufficient. What if we need to contact 20 downstream systems in a complex workflow, but I don't want a single "orchestration coordinator" to be a bottleneck (or single point of failure). I don't want to hand the orchestration off from my app to a central orchestration hub.
Let me propose a different approach.
When we use SOA/EDA (the same thing as far as I'm concerned), the top-level building block used is the Service. A service may make use of a number of existing systems to perform its work. The business-level events that we publish (and subscribe to) are done by the service, not the existing systems.
If there's any orchestration/workflow that needs to be done as a result of a service receiving an event, it is done entirely internal to that service. Inter-service orchestrations don't really exist, as in there is no orchestration coordinator that is not in a service. And the orchestration coordinators within a service don't touch other services' back-end systems - if anything, they publish other business level events.
Be aware: when just starting out on an SOA, you'll find that multiple Services make use of the same backend systems. This may be necessary, but not a desirable state to stay in for too long since it embodies the most insidious and invisible kind of inter-service coupling there is.
I want to go back to Nick's original question:
So what if no one picks the message up? Is that an error?
The answer is mu.
If a service publishes a business-event (message) and no other services currently care, that's fine. It's not an error. Actually, you'd probably have some kind of infrastructure "queue" where messages that haven't been received more than X time get sent to, so that the event isn't "lost". On the other hand, within a service - if an existing system sends out a message that needs to arrive at another system, and that message doesn't arrive or isn't picked up "in time", that is an error.
This is one of the advantages SOA brings to the table in terms of EDA (again, the same as far as I'm concerned). You get simple messaging semantics between services, while within the "sphere of control" of a service you need, and more importantly can do more complex messaging and orchestration.
Bottom line: you need higher abstractions than your existing systems to employ EDA effectively.
You might also want to check out my podcast on this topic: SOA, ESB, and Events.
Posted by Udi Dahan at 06:36 AM Permalink
|
January 07, 2008
More SOA stuff for the DotNet Rocks crowd
Now that the show I did with Carl and Richard is online, I just wanted to let the new visitors to my blog know about all the other podcasts that I've done on SOA.
Here are some of the more popular ones:
And there's always the archives with more than 30 shows up.
If you are a new visitor and are looking for more information on NServiceBus, you can find it all here. You might also want to take a moment to subscribe so that you don't miss out on any of the updates. And, as always, please do feel free to ping me about these topics via email or in the comments below.
Thanks for dropping by.
And there's always the archives with more than 30 shows up.
If you are a new visitor and are looking for more information on NServiceBus, you can find it all here. You might also want to take a moment to subscribe so that you don't miss out on any of the updates. And, as always, please do feel free to ping me about these topics via email or in the comments below.
Thanks for dropping by.
Posted by Udi Dahan at 02:11 AM Permalink
|
|
