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.)