Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.
Don't EDA Between Existing Systems
In Nick Malik's great post, <a href="http://blogs.msdn.com/nickmalik/archive/2007/08/12/eda-avoiding-coupling-on-the-name.aspx">EDA: Avoiding coupling on the name</a> he describes additional "handshakes" to be used to avoid the following problems:<br />
3 Min Read
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 businessl evel 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.
About the Author
You May Also Like
More Insights
