About the printing – no, there wouldn’t need to be a common database. Both services would be involved in the printing, as well as another layout service.

Hope that makes sense.

I’m not quite sure i understand the second part of your answer. Could a concrete implementetion be two services each collecting data and storing this in a common database from where reports could be generated and printed?

Glad you liked the article. To your question:

> Who would hold the ordercustomer data?

The sales service would hold the order data indexed by customer Id.

Printing isn’t a service and can be thought of as a physical endpoint on which multiple services can run – each contributing the part of the data it owns.

As a goal, we should see services not requiring each others data beyond just IDs.

Does that answer your question?

Synchronicities abound

Continuing with your example of an order service and a customer service – who would hold the ordercustomer data? If a requirment was for a list of orders with associated customers to be printed (or used for some other purpose), would the printing service simply request data from both services or would this be pre-cached by listening for order and customer events?

EDA has been milling around my head for a few months now and it clicked. I think I get it and the more I conceptualize about systems and problems I’m having I see a good fit for EDA. EDA is a much better model for the real-world, a cleaner abstraction because things don’t happen request-response or in the order you want them to. The last 35 minutes of my presentation was Q&A and there were several people doing SOA implementations saying the same thing – when you conceptualize things in events it’s a better model. You can account for all kinds of things you couldn’t before, including time. Which, in justice & LE is ever prevalent.

There must be some sort of awesome EDA energy lighting up the web because the more people I talk to the more sense it makes. I’ve got a long way to go, but the gears are turnin.

Keep up the great work man, it’s shaping thoughts to a better way to deal with the real-world and align business with IT!

Glad you liked it. I share your hope for a more viable SOA/EDA approach that will gain broad industry adoption.

I have always felt that command-based layered service architecture, as advocated by Thomas Erl and others, will ultimately impede enterprise agility by increasing the cost and risk of change.

Hugh Taylor published a book on SOA and EDA this year, I haven’t read it yet, but the TOC suggests it supports and elaborates on the same arguments.

Is it possible that we’re witnessing a maturer SOA being born? Something that will finally removes Fowler’s (A)mbiguity from SO(A). Should we give it its own name? Perhaps EDSOA, or maybe SOEDA!

Ameer