Learned a nice simple explanation of the relationship between SOA and EDA.
Actually, Kyle thinks I already came up with this. If I did, I've forgotten, but glad that it's circulated its way back around to me. If not, well, I wish I had.
I was spending some time with some colleagues learning more about WebSphere Business Events. Two interesting issues are how this product fits into the WebSphere Business Process Management portfolio of products, and more generally the relationship between service-oriented architecture (SOA) and event-driven architecture (EDA).
The explanation is this: EDA decides when, SOA decides what. Essentially, when an event handler decides to react to an event, in most all cases it should do so (ideally) but invoking a service (by which I mean a executable unit of an SOA). In this way, the service can be invoked either SOA-style by a service consumer that knows which service it wants to invoke; or EDA-style by an event emitter that has no idea what service to invoke, but the event triggers one or more handlers, each of which makes its own decision about what service to invoke.
So the service is the what: What you do to perform a task that someone's decided needs to be performed right now. EDA is one way to achieve the when: Deciding that now is a good time to perform the service. A traditional SOA service consumer is another way to achieve the when. It's all a matter of whether you want your code to say, "I know what I want to do, and I want to do it now, so I'm going to issue a request to do it now." -- that's a service consumer; or if you want your code in two more decoupled parts that say, "1) I know something happened, but not what to do about it, so I'll just announce it; and 2) I've received an announcement, I want to react to it, and I know what I want to do to react to it, so I'm going to issue a request to do it now." -- that's an event emitter and an event handler, where the handler also acts as a service consumer.
So, EDA and SOA: SOA determines what gets done, EDA is one way to determine when it gets done. Nice simple explanation.