I had the pleasure of attending Gregor Hohpe's keynote speech on the third and final day of WSO2Con in Colombo. (The conference was a hugely successful affair, by the way, judging by the quality of the talks and the fact that the attendance far exceeded expectations.)
Gregor's talk was a reference to his famous book "Enterprise Integration Patterns", and was titled "Enterprise Integration Patterns - Past, Present and Future". (For all his achievements and fame, Gregor is an endearingly unassuming man, as I found when I spoke to him person-to-person. He's also a very humorous speaker, and kept the audience in titters during his keynote.)
When he came to the Future part of the talk, one of the many gems he let slip was his insight that his famous book was really about Messaging Patterns, in which case it would be the first of four volumes (the other three devoted to Conversations, Processes and Events). He specifically called for two things from the audience and the community in general - some ideas on notation for these more complex patterns, and for exerting guilt-inducing pressure on him so he would actually write the books!
I have been interested in the Distributed Computing area for a long time (I would in fact have called these "Distributed Computing Patterns", because they are not specific to enterprise contexts, and the purpose of the interactions isn't always integration).
In any case, this is how I see the four volumes of the book that Gregor described, and how they would relate to each other. I would like to mail him on these ideas and I'm sure I'll have an interesting conversation.
"Messaging" is really the most generic description of a class of distributed computing systems. It also takes a top-down, system-wide focus (a "God" view). One can think of specific subsets of these generic interactions, and one can also shift focus from the overall system to a particular node. So, as we add a statefulness aspect to messaging, we begin to enable conversations. And as the purpose of the conversations becomes coordination (one participant controlling the others), we have (process) orchestration. Somewhere along the way, we can explicitly consider multi-way messaging, i.e., between multiple peers.
When we shift focus to a single node, we have an event-driven system because incoming messages at any node are "events". And when we take a set of event-driven nodes and consider them in aggregate, we have a choreographed system, where each node is ignorant of the existence of other nodes and only responds to events, and the system as a whole "works" because of these inter-related events. The design of a choreographed system is really the design of appropriate events, since the previous step (event-driven systems) has already designed the behaviour of the individual nodes.
So that's my simple view of the Distributed Computing universe. I also have a more complex diagram that I created a few years ago to explain how the various facets of distributed computing are related.