He he he 🙂 I saw this post on messaging and events (via Jim) and I was amused. The chapter we wrote almost 1 1/2 years ago for a book on service-orientation (I think the book should be published soon) dealt with exactly this approach. In fact, in there we talked about the importance of designing message-oriented contracts and proposed a programming model abstraction that is different from today’s Web Services middleware. In our proposed middleware, the receipt of a message was represented by an event. SSDL was still an idea in the making then. So it was only natural to follow those ideas when we started experimenting with SSDL-related tooling. The code generated by the SSDL contract tool models incoming messages as events.
We explicitly ignored the XML-to-object problem (we assumed that we could go from one to another) because we wanted to concentrate on the principles of messaging. There is no reason why one couldn’t treat messages as plain XML documents rather than typed objects. One could argue in fact that processing plain XML documents or at most have a message abstraction is the way to program such systems.
This is nothing new. Messaging folks have been doing it for ages. It’s the discussion within the context of service-orientation that is interesting so I am glad that more and more believe the truth.
After my initial implementation of some BrainExpanded-related ideas on top of dgraph using its GraphQL…
Say hello to the Graph Model Domain Specific Language (GMDSL), created with the help of…
As I wrote in previous posts, the manual recording of memories for BrainExpanded is just…
Imagine a world where your memory is enhanced by a team of intelligent agents, working…
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…