Thinking about one-way SOAP messaging

Working on the MSMQ provider for WSE 2.0 has really changed the way I think about SOAP messaging.  Most of my customers are still working with what I would refer to as “classic” or “traditional” Web services – SOAP over HTTP.  By its nature, SOAP over HTTP has a very RPC-like feel to it, regardless if you’re bought into messaging semantics or not.  However, there are some distinct differences one must consider when moving to SOAP over MSMQ.

When working with SOAP over HTTP, you have to consider that one of three things could happen: (1) everything works as it should with your message reaching the target, the Web service performing work on your behalf and sending you back a response (2) the network link could break during transport resulting in your message never arriving at its destination, therefore no real harm is done (3) the network link could break after your message arrives at its destination, resulting in the Web service possibly doing work on your behalf but not being able to return the result to you.

When using SOAP over MSMQ, scenarios two and three above are mitigated substantially.  Assuming you’re using transactional and durable queues, your message will eventually reach the target regardless if you’re still around or not.  Likewise, the service is able to queue the return result and enable you to pick it up sometime in the future.

If you want request/response semantics when using SOAP over MSMQ, you must keep in mind that the WSE 2.0 channel model actually requires your client to become a server.  Your client must listen for incoming SOAP messages and understand how to act upon them to correlate them back to the original request, which is distinctly different from the blocking semantics you get with SOAP over HTTP.  Ultimately, this is nothing new to folks who have been working with messaging oriented middleware – MSMQ and MQSeries – but will be new to people who have always thought of Web services as a platform neutral way to do RPC.

Comments

• Anonymous
  February 09, 2004
  SOAP has another competitor, XMLRPC which would be more "lightweight".
  
  http://www.xmlrpc.com/
• Anonymous
  February 10, 2004
  That battle has been fought and the industry has aligned behind SOAP for interoperability.