Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Distributed Software Development for Java and .NET

Distributed Software Development for Java and .NET


Asynchronous messaging is the backbone of many enterprise systems. Unfortunately, .NET developers are often forced to make a though decision. Often this means they have to either roll their own messaging service or use Microsoft Message Queues and lose out on Java interoperability.

TIBCO Enterprise Messaging Service offers a solution to this problem. This platform not only offers Java/JMS bindings, but also bindings for .NET, .NET Compact Framework, C, and, if you really need it, COBOL.

Roger Voss offers an overview of JMS for distributed software development. In addition to the really good interoperability story, JMS offers some additional benefits. One of these is the ability to offer one-to-many queues they call Topics. Unlike a Queue, which guarantees each message is sent to only one client, a Topic ensures that every client gets a copy of the message. This eliminates the need for polling or sending the same message to multiple queues.

Another interesting feature pointed out by Roger Voss is the ability to create bridge rules.

A bridge rule uses this same JMS selection expression syntax for specifying the routing of messages amongst queues and topics that exist in the server. Administratively one can create a bridge rule in the server that will copy messages from one place where they are being published to yet another place where there is a newly defined interest in consuming that message.

Now if some application is currently publishing messages to its outbox topic and another existing application needs to be altered to begin consuming some of those messages, it is easy to add a bridge rule that will copy the desired messages from where they're being published to where they now need to be consumed. It will not be necessary to recode the consuming application to become a subscriber to yet another topic and establish yet another JMS session. Instead the programmer need merely add new message handling code for the new type of message to be consumed. (Indeed, in C# .NET or Java it doesn't take much effort to build an architecture for applications where message handlers can be added as a plug-in modules.)

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • follow up examples

    by Cameron Purdy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    See also Roger's responses here:


    Cameron Purdy

  • IBM WebSphere MQ

    by Saket R,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi there,

    IBM WebSphere MQ supports JMS and XMS (currently .NET, C and C++).

    XMS .NET:

    XMS C/C++:

    Other clients in numerous languages and for numerous platforms:

    A quick google search reveals an interesting blog entry by Dino Chiesa at Microsoft:

    Warm regards,

  • JMS as a standalone message broker

    by Roger Voss,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    One thing about JMS messaging products - such as Tibco EMS, SonicMQ, or ActiveMQ - is that they are deployed as standalone messaging broker services, i.e., they are not incorporated into a JEE application server. And they each have .NET client bindings support. (Tibco EMS even has .NET Compact Framework client bindings - so if a company uses industrial WinCE computers, like the superb Beckhoff CX1000, such embedded computers can participate as part of the JMS messaging substrate.)

    There may be a bit of confusion to .NET developers about this point as some may know JMS to be part of the JEE application server spec. However, JMS is also a spec unto itself. So there have arisen vendors and open source projects that concentrate on just implementing the JMS spec. (A contrast to this is JBossMQ - to deploy and use this particular JMS implementation, one has to deploy the JBoss application server.)

    Another thing to appreciate about the above mentioned JMS products is that they are each a superior messaging broker than Microsoft's MSMQ, as JMS is a more capable and flexible messaging specification than what is embodied in MSMQ. Of course much has already been made of the heterogeneous character of the JMS products. Yet .NET developers are faced with wide ranging integration challenges every bit as much as Java developers. JMS as communication glue is strong tonic indeed for that particular condition.

    This is just a build-up to say that if you're primarily a .NET development group doing behind-the-firewall enterprise distributed software, you'd find many advantages to consider toward adopting a JMS messaging solution.

    Ironically, Tibco EMS, being that its message broker is written in C, it is not even necessary to have a Java JVM to deploy it. (None-the-less, it is deployable on Windows, RS6000 AIX, Sun Solaris, Linux, and Apple Mac OS X.) Consequently one can be an all JMS-messaging shop and yet not even have a Java JVM installed anywhere in sight. That is precisely why Tibco renamed their product from Tibco JMS to Tibco EMS - it's first and foremost an enterprise messaging service that just so happens to support a generous set of client bindings.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p