Weblogic JMS with .NET

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!