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.
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.…