All About Interop : JMS

Weblogic JMS with .NET

DotNetInterop — Thu, 09 Oct 2008 18:36:00 GMT

This came out last month, I just learned about it from an email from Jesus today.

WebLogic Server 10gR3 now has an officially-supported .NET client for its JMS provider. Very cool. Some of you might be wondering, just what does that mean? It means there is a queue mechanism in the WebLogic Server, for a long time this has been called "Weblogic JMS". And you can connect to that queue subsystem via .NET applications. James Bayer has a blog entry on it, which you should check out.

pet peeve alert! Calling a queue "JMS" is strange and confusing. It would be like calling the Oracle database "Oracle JDBC" or "Oracle ADO.NET". Oracle Database is not the same as JDBC. JDBC is an API. ADO.NET is the name for an API. The database is not the API. The database (whether Oracle, Microsoft SQL Server, IBM DB2, or something else) exposes mutliple API families - some for Java, some for .NET languages, some for C and C++. The programmatic interfaces are distinct from the implementation.

With JMS, Sun and the Java guys have confused the issue. Maybe even on purpose: remember back when JMS was conceived, Sun had aspirations to make Java itself a platform - everything contained within Java as other things like the operating system and the database itself, and to the point, a messaging subsystem, recede into the background. Well, that didn't really happen, despite the huge popularity of Java as a programming language. Operating systems still matter, databases still matter, message queues did not get subsumed into the programming language. Java is a language and a VM and a base class library, but not a platform. Regardless, the side effect of Sun's unfulfilled platform aspirations for Java is that today, people call message and queue subsystems "JMS." Developers speak of JMS topics, JMS queues, JMS messages. But it is clear: just as JDBC is a Sun/Java API for databases, JMS is a Java API for Messaging subsystems.

IBM has always been very clear about this with its MQ product, later called MQSeries and then changed to "WebSphere MQ".   (For this post I'll just call it MQ.)   MQ is the implementation, and MQ exposes a bunch of different APIs - for C, for .NET, for Java, and I'm sure, for other languages. In what looks like a bit of schizophrenia, IBM also has message service within WebSphere Application Server, which is called WebSphere JMS if I am not mistaken, and which... you guessed it, exposes more than just a JMS programming interface.

For some reason, the queue infrastructure for some products has been called "JMS" as if that is the only API that has ever mattered. Seems like a result of shortsighted and wrongheaded product planning to me. And it's darned confusing, to boot.

A separate issue is that JMS is not merely an API! JMS actually injects some message protocol behavior, specifically the RFH2 header formatting stuff, which makes for tricky interop with other, non-Java applications through queue subsystems. Designing JMS this way presented a big, unnecessary obstacle to interop, and I've blogged on it previously.   IBM has had to introduce new APIs for MQ and its other queue subsystems, specifically to work around this interop barrier. I don't know a better way to solve it, than the way IBM did. But make a note to yourself - if you ever design a queue system or queue API, keep the API separate from the application protocol and message formatting.

Check it out!

JMS Adapters for .NET & BizTalk

DotNetInterop — Fri, 16 Nov 2007 19:12:00 GMT

Love it! I previously posted about a beta of the JNBridge JMS Adapters. I just got a form email from the company that they've publicly released their adapters.

There's a version of the adpater for .NET apps - this allows any .NET app to connect to any JMS resource. Think about that. It's really useful. If you have an IBM MQSeries queue, and you're using IBM's MQ JMS provider to get to it, you can use this new adapter to enable any .NET application to get to the same JMS resource. The thing is based on the WCF Line-of-Business Adapter SDK, which means any .NET application that can consume a WCF endpoint, can use the adapter.

There's a similar adapter that works for BizTalk Server applications, but it is not WCF-based.

These adapters work with any JMS server, and you don't have to change the JMS infrastructure to use them. They both use the .NET-to-Java bridging magic in JNBridgePro, so the .NET app actually connects into the JMS system via the JMS jars. That's why you don't have to change anything.

You can download a trial version on www.jnbridge.com.

The SOAP-over-JMS spec and interop

DotNetInterop — Tue, 24 Jul 2007 17:36:00 GMT

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.

JNBridge JMS Adapter Beta

DotNetInterop — Tue, 17 Jul 2007 01:33:00 GMT

I see JNBridge has a public beta now for their JMS Adapters for .NET. I haven't tried this out, but Wayne tells me that with the JNBridgePro JMS adapters, you can access JMS Services from a wide variety of systems. A MOSS 2007 app could connect to a JMS resource. A business process running in BizTalk Server could connect to JMS. Anything that can consume a WCF endpoint.

Thw way it works: your .NET app calls into the Adapter, which just looks like a .NET assembly. Through the .NET-to-Java bridging magic of JNBridgePro, that assembly calls the Java-based JMS client classes provided by the vendor of the JMS provider (let's say, Sonic or IBM or WebLogic). From that point on, it is just as if you were calling into the JMS resource from a Java application. At that point, there is a message on the JMS-accessible queue, and it can be picked up by whatever mechanism the JMS provider enables - pub/sub, or an EJB Message Driven Bean, etc. Communication going "the other way" - from Java to .NET - would work similarly.

Check it out.

Custom WCF Channel for IBM MQ

DotNetInterop — Mon, 16 Jul 2007 21:06:00 GMT

IBM have shipped an early version of a Custom WCF Channel for MQ. The dev team in Hursley contacted me to solicit feedback. It's apparently pretty simple now, supporting only SOAP one-way messaging, but they say if there is sufficient interest and feedback, they will consider developing it further and perhaps adding it to the MQ product (as they did with the MQ Classes for .NET, and other stuff).

Out of the box, WCF includes support for queued transport, over MSMQ, which is the Microsoft Message Queue, built-into Windows. This is available in the NetMsmqBinding. You can read more about it here.

What our friends at IBM are doing is similar, but different in a very important way: In the IBM channel, messages are encoded and sent via the message queue, just as with the NetMsmqBinding. However, with the IBM channel, of course, the queue is WebSphere MQ v6.0, and not the built-in MSMQ. There is one other important difference though: Messages are encoded using the SOAP over JMS (Java™ Message Service) message format described in WebSphere MQ 6.0. Why is this important? This enables interoperability with services and clients hosted by other environments that can also read or generate SOAP-over-JMS. Examples are such as CICS (Customer Information Control System) and WebSphere Application Server.

So this channel has the possibility of opening up some new interop capabilities between .NET / WCF applications and apps that run in non-.NET environments, including Java applications running in WebSphere Application Server.

Please do have a look:
http://www.alphaworks.ibm.com/tech/mqwcf/

.NET can connect to WebSphere's built-in JMS

DotNetInterop — Mon, 16 Jan 2006 16:36:00 GMT

Phil Willoughby of IBM dropped me a line. Phil apparently works on the XMS stuff, I'm guessing out of IBM's Hursley lab. Phil sez:

Re: http://blogs.msdn.com/dotnetinterop/archive/2005/11/04/488770.aspx

FYI, XMS can be used to connect directly to the WebSphere App Server embedded JMS system. There is no requirement to have WebSphere MQ, WebSphere Message Broker or WebSphere Business Integration Event Broker installed. Of course, if you're using another vendor's app server you would need to use WMQ or one of the brokers to bridge the gap.

Mark Phillips' developerworks article does a good job of explaining this:

http://www-128.ibm.com/developerworks/websphere/library/techarticles/0509_phillips/0509_phillips.html

Hey, that's good to know! One more way to connect...

XMS whitepaper from IBM

DotNetInterop — Thu, 03 Nov 2005 21:47:00 GMT

part of an ongoing series of posts on JMS and .NET interop.

I just saw this while looking around for something else - IBM published a paper in late September on the XMS client library for their MQ brokers. I posted about this previously. Essentially this is a .NET client for their MQ brokers, including an implementation of some stuff from JMS. That means publish/subscribe capability, partly. The new article offers some new info and clarifies a few things for me. Specifically, when IBM says "MQ Brokers", they include the regular MQSeries in that. Since CSD08 of MQ V5.3, IBM has offered a pub/sub capability in the base MQ. So this XMS stuff works with that. (IBM are now up to v6.0 of MQ.)

A nice interoperability option! This fixes the JMS-is-not-interoperable issue I had raised previously.

Remember, the .NET client library for plain-old-MQ is a separate thing - that has been a part of IBM's MQ product since MQ5.3 CSD05. But, what this XMS thing is, is a pub/sub client. Something a little different.

IBM and JMS-to-.NET interop

DotNetInterop — Wed, 03 Aug 2005 17:04:00 GMT

IBM's .NET Managed client for JMS

Today I received a comment on a prior entry of this blog. It is noteworthy so I thought I would re-post it here.

As previously mentioned in a previous blog entry (JMS Interop, revisited), there is a demand for .Net and JMS interop.

IBM Message Service Client for .NET (informally known as XMS) has now started an open Beta programme.

XMS is a non-Java implementation of the Java Message Service (JMS) API, currently implemented to work with the IBM WebSphere Messaging portfolio. Specifically, it is a fully managed .NET API that can be used by applications to send and receive JMS messages via IBM WebSphere Business Integration Brokers over Real-time Transport or via the default messaging provider within IBM WebSphere Application Server v6.

We welcome you to download XMS from: http://www14.software.ibm.com/webapp/download/search.jsp?go=y&rs=message,

Try it out, and give us your feedback via: news://news.software.ibm.com/ibm.software.websphere.mq.beta.

Cool!

First question I have is, does it work with plain old WebSphere MQ? I don't know what the term "WebSphere Business Integration Brokers" includes. I think there are some premium products like WBI Server, and WBI Message Broker and WBI Event Broker, and I guess all of those are included in "WBI Brokers". But what about just MQ? [ note added 4 Aug 2005 : The readme for this XMS.NET thing apparently states NB. Interaction with IBM WebSphere MQ is not supported in this release but is currently under development. So I think you need one of the higher-end MQ or WBI products, for now. ]

Anyone trying this out? I am interested in feedback, too! Comment on the blog or contact me privately. I'd love to hear if this thing is useful.

strange but true: JMS for .NET

DotNetInterop — Fri, 27 May 2005 00:09:00 GMT

TIBCO apparently has implemented the JMS API in .NET.

TIBCO Enterprise Message Service software not only provides a world-class JMS implementation, its .NET API supports and extends the JMS 1.1 specification. The TIBCO Enterprise Message Service .NET component fully incorporates .NET-style event handling and yet closely mimics the Java API. The implementation consists of fully managed .NET code.

I hear you gettin' all excited about this, but hold on. It is only for Tibco's enterprise messaging stuff. Supposedly, though, it works for .NET CF, too. Wow!

[ note added 3 Aug 2005 : IBM has announced an open beta for the IBM Message Service Client for .NET. ]

on Java-to-.NET interop via JMS and MQSeries

DotNetInterop — Tue, 07 Dec 2004 01:10:00 GMT

While looking around I found two articles, from SYS-CON's WebSphere Developer's Journal, covering J2EE and .NET interop via MQSeries.

part 1: http://sys-con.com/story/?storyid=43430&DE=1#RES

part 2: http://sys-con.com/story/?storyid=43452&DE=1#RES

These articles reference ma7p, the IBM supportpac, which is no longer available. ma7p has graduated into the MQSeries product. Upgrade to MQ V5.3 + CSD05 or later to get the MQ classes for .NET.

Interesting: the 2nd article documents a problem I ran into while trying to connect a Java/MQ application that uses the JMS api, with a .NET application that uses the MQ Classes for .NET. The JMS implementation essentially extracts function from the underlying MQ and embeds it into the API level. So, things like MessageId and CorrelationId, which are indispensable for a typical MQ app, are not transferrable between a JMS/Java app and a .NET app. JMS commandeers those MQ-isms and does not bubble them up into the application layer. In some cases there is a similarly named JMS thing, but it is not the same thing as the underlying MQ thing. In fact I could not find a way to set the MQ Message ID - the JMS doc I found said that the JMSMessageID on an outgoing JMS message will always be set by the JMS layer - the application is not able to set it. (not quite true, you can set it all you want, but as soon as you send the message, your MQ MessageId is over-written with a JMS-provided value).

The net result was that I found myself reverse-engineering the JMS implementation of message-munging. At first it looked like it was just one or two methods, but the JMS-isms just kept coming and coming. The correlation ID needed to have a specific prefix. Strings had to conform to a JMS-specific encoding. If you try to encode a simple buffer with a couple of integers and a string, you get a big hairy XML envelope (with no namespaces! The dreaded RFH2 envelope) - the JMS message envelope. Which may be just what you DON'T want in a high-throughput messaging app. The JMS pitfalls and traps seemed to just keep going and going. Eventually I just punted and switched the Java app to use the "MQ Classes for Java", a package which defines, like the "MQ Classes for .NET", an IBM-only programming interface. When I use the MQ Classes for Java, I don't get the surprises I mentioned above.

Stop and think for a minute; This is a completely ridiculous situation. Imagine if you inserted rows into an Oracle database with a JDBC app, and then you could only read those rows with another JDBC app. Imagine if your LDAP repository, once you accessed it with JNDI, became a resource that could only be accessed by Java apps. Preposterous, right? Well that's what JMS does. You have to go to the high-fidelity MQ Classes for Java if you want to have a reasonable effort connecting Java to .NET apps.

"Non-standard interface!" you point out. "Lock-in!" Yeah, you're right. But Interop trumps Neutrality. [Disclaimer, I never believed the "vendor neutrality" arguments anyway] The designers of JMS - either the IBM implementation of it, or the specification itself - have made decisions about message formats that specifically preclude any interop between a JMS (Java) app and a non-JMS app, without lots and lots of extra effort by the non-JMS side. The message formats are not published, so you either have to reverse-engineer them, and risk violating the JMS specification license, or ... you have to license and implement JMS. In either case, Vaya con dios, the future holds lots of work and lots of lawyers for you. Going with JMS, you may not get "Lock in" to a particular vendor of message middleware, but you do get "Lock out" - of anything non-Java.

So I have some questions for you all:

do you do interop between Java and .NET over MQ ? If so, do you use JMS? How do you resolve the issues I mentioned?
anyone have any helper classes in C# or VB that unpacks the JMS envelope?
what did you do about JMSMessageID?