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.”
As part of the BrainExpanded project, I’m building an iOS app that lets users easily…
Artificial Intelligence (AI) has rapidly evolved over the past few decades, becoming an integral part…
Happy New Year everyone! I was planning for my next BrainExpanded post to be a…
See "BrainExpanded - Introduction" for context on this post. Notes and links Over the years,…
This is the first post, in what I think is going to be a series,…
Back in February, I shared the results of some initial experimentation with a digital twin.…