Udostępnij za pośrednictwem

The SOAP-over-JMS spec and interop

  • Artykuł

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

  • Anonymous
    July 25, 2007
    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.

  • Anonymous
    July 27, 2007
    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??

  • Anonymous
    July 30, 2007
    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.

  • Anonymous
    August 14, 2007
    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! :)

  • Anonymous
    February 24, 2010
    Hi can someone give me example of how to use jms/soap using spring.net for tibco?

  • Anonymous
    February 24, 2010
    Hi can someone give me example of how to use jms/soap using spring.net for tibco?