After reading the comments by Mark Little and Mark Baker on Jim’s post (refer to my previous entry too), I wanted to say more on the subject…
I don’t really agree with the use of the term ‘event’ as an architectural construct. While Jim and I promoted the use of the event abstraction as a programming tool, at the architectural level it’s all about the transfer of data (through messages). The semantics or interpretation associated with the receipt of a message does not have be the same between participants in an interaction. I think that as being very important in loosely-coupled architectures. Participant A may see it as an operation call on a local object, participant B as a raised event, while participant C as another message arriving in a local queue.
At the architecture level, however, it’s all about the data being exchanged through messages. One or more messages make an interaction. The correlation of messages (e.g. sequencing) makes the messaging behaviour of a service. Jim said it really nicely:
“A message arriving at a service sets context for the processing of that message and contains an implicit request to the service to process that message. The arrival of a message is an event! [..] the truth is contained entirely within the message.”
2 responses to “Messages and events again”
Until we can sit down over coffee, we’ll have to agree to disagree. I think events (or at least a single event) is a fine architectural construct. The “contents” of the event are the state; we’re not just talking about something dumb that says “something has happened”, we’re talking about an event that says “trigger/fire & here’s the event content”. As I said in one of the comments to Jim’s original post, I find that a lot easier to use when conveying loose coupling. In fact, I don’t really think we’re talking at cross purposes: just look at what I said and the last sentence in your entry from Jim. In my mind they are identical statements, just phrased differently.
You say: “The semantics or interpretation associated with the receipt of a message does not have be the same between participants in an interaction. I think that as being very important in loosely-coupled architectures. Participant A may see it as an operation call on a local object, participant B as a raised event, while participant C as another message arriving in a local queue.”
and from that it seems to me that you don’t really have the same understanding of “event” as I do: what you are talking about is implementation, whereas I’m talking about event as an architectural construct and not binding it to a specific implementation. A messaging system can be modeled as an event system (just take a look inside your favourite PC to see a great example of that) in the same way that interactions with programming language objects can be modeled as events (and Smalltalk 80 did a good job of combining some of this). So don’t confuse implementation with architecture 😉 When I talk about “event” I mean that “a trigger has fired and the content of that event is an XML payload”. How that event fires and how that payload is delivered to cause it to be fired, are not important at this level – that’s implementation detail.