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.
One response to “Messaging and events”
This is interesting and something I’ve been arguing for since designing a WS framework called WSPeer. I had a simple problem, which was to enable an application (Triana) to speak SOAP. Most of the WS middleware is based on the ‘container’ model where you stick your app into a hosting environment and walk away leaving the container to do everything. But this was no good for Triana because it has its own environment and responds to user input. So WSPeer is built entirely on events. If you want your app, or part of it, to send and receive SOAP messages you deploy that part via WSPeer. Incomming messages are returned to the app as an event. The app is then free to decide how it handles that message. It doesn’t seem like a lot, but it’s actually very liberating. As a simple example, we wrote a P2P WS chat application where peers discovered each others’ WSDL. WSPeer received the SOAP message and just passed it to the chat app. The chat app then just sent a response (in the widest sense of the word!) message – whatever the user types – back into WSPeer. This would be a complete pain to do, and overkill, using say a Web server and a servlet container.