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.
There’s a unique energy that comes with starting something new — a blend of excitement,…
As I continued work on BrainExpanded and its MCP service, I came to realize that…
Just over a month ago, I published "Playing with graphs and Neo4j". Back then, it…
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…