The SOAP-over-JMS spec and interop


In a previous post, I wrote about a WCF Channel for MQ that IBM is building.  Some customers had asked about this project and its implementation, specifically around the interop implications if other JMS providers, other than MQ that is, were used in an environment.


To be clear the WCF Channel for MQ is … how can I put this?  for MQ.  It is not an approach that particularly facilitates interop among JMS providers.  That would best be addressed by a spec that focuses at a different level, say AMQP.   AMQP as I understand it, is a queue-to-queue protocol that would facilitate interop between queue providers, and I believe that would be true whether or not a JMS API was used to access it.  In general the goals of AMQP are valuable when they are API-agnostic.  Heterogeneity anyone?


The WCF Channel fo MQ does provide interop, but to a particular limited degree: it is interop between endpoints in a messaging network that all use MQ.  .NET to CICS, .NET to WebSphere, C++-running-on-AIX  to .NET-on-Windows, and so on.  WCF isn’t available on all the various IBM platforms, so how does the interop work?  It happens because IBM is using the same message format on the queue, from all those endpoints.  [added 30 July 2007 215pm Pacific] In fact as I understand it, that is the point of the WCF Channel for MQ: the programming model at the different endpoints varies, but interop among those endpoints is still possible.


There is a related spec effort in this space – the SOAP-over-JMS proposal.  The message encoding IBM uses is NOT SOAP-over-JMS.  Why?  Because SOAP-over-JMS is an idea, not a real specification yet, let alone a standard one.   Thinking a bit more about this, it doesn’t matter very much that the WCF channel for MQ does not currently use a standard encoding, as long as the encoding is consistent across the endpoints that need to exchange messages.  That is to say, consistent among CTS, a Websphere EJB (MDB), a Websphere JMS app, and the WCF app, etc. 


If and when finalized and adopted, the SOAP-over-JMS spec aims to allow heterogeneous web services stacks (AXIS, Sun JWSDP, Websphere’s built-in, etc) to interop.  But still, this assumes that there is a single JMS provider.  The SOAP-over-JMS stack provides interop among web services stacks using a single JMS provider;  it does not provide interop among JMS providers. For that you would be looking at something like a point-to-point bridge or to AMQP.


What are your thoughts on this?  How much interest is there in AMQP? Drop me a line.

Comments (6)

  1. SOAP over JMS is quite useable already. We are currently already writing Services in Java, .Net and Tibco Business Works using SOAP/JMS.

    Currently our .NET implementation does not yet support XML <-> Object conversion but we will implement this as an custom transport like IBM did.

    We are using Tibco EMS for the JMS server. They deliver JMS drivers for .NET but as there is not standard API for Messaging on .NET our implementation will only work with Tibco EMS.

  2. mynamespace says:

    AMQP, is one of those things that can really help put fire under the business level messaging space. It’s approach as a light-weight wire-level transport, that handles durable messaging and reliability at the same time quite worthy. Obviously you would be intrested in its usage for interop senarios – though e-mail style loose coupling would be a bigger asset for me in terms of MOM.

    What would be really good would be to use WCF over AMQP, albeit no implementation exists. I guess, in general, the .NET community in the middlewear/backend space is always in the backseat – just look at ESBs in the java world.

    Anyway, are there any plans from your side or Microsoft to support AMQP? Especially atop WCF??

  3. DotNetInterop says:

    namespace, I’m taking your flame bait!

    "always in the back seat", huh?  Let’s take one example:  WCF.  WCF is a common programming framework that applies whether you are using binary encoding or angle brackets, whether you use transactions or not, whether your communications are queued or not, whether you prefer REST or SOAP.  In this respect it is ahead of any similar idea in Java, which still has a myriad of communication APIs and models, one for each variation.  JAX-RS for REST, JAX-WS for SOAP, RMI for binary transport, EJB Remote methods for transactions, JCA for 3rd party apps, JMS for queued messaging, and so on.  

    Now on to your question:  are there any plans for AMQP support from Microsoft?  I have nothing to announce, or not announce, at this time!   I will say that it’s an interesting question.

  4. mynamespace says:

    Firstly, agreed there is no peer that stands up to WCF, period. But, WCF is an infrastructure technology, and my comparision was with respect to middlewear implementations like AMQP, ESBs, ORMs, CEP etc. And especially in the open source arena the .NET community is way behind, just look at the number of java to .net ports. All the same, in terms of a lot of core infrastructure technologies (like WCF, WPF, WF, LINQ, .NET itself) and tool .NET ecosystem is lightyears ahead. And so, I choose the .NET side of life!

    The way you put it, I’ll be on a loop to your blog for a pending announcement on WCF for AMQP with a native .NET server please! 🙂

  5. Pankaj says:

    Hi can someone give me example of how to use jms/soap using spring.net for tibco?

  6. Pankaj says:

    Hi can someone give me example of how to use jms/soap using spring.net for tibco?