Using JMS from C++ or .NET
There are many possible motivators, some of which even we were surprised about. This page lists a number of use cases that we have encountered. Most often, Java is already part of the total picture, but sometimes we have customers who have otherwise pure C++ or .NET solutions and choose JMS for their messaging implementation for price/performance/choice reasons.
Many organisations have deployed a J2EE server for their enterprise solutions. Every J2EE server comes with a built-in JMS package ready for use. You might be using JMS already or you might just be starting to take advantage of already deployed yet unused features of your server infrastructure. It does not really matter, JMS is a great asynchronous messaging solution that is at your command, if only you weren't programming in C++ or .NET.
C++ or .NET come with their own —possibly built-in— messaging solutions. On Windows for example, many developers are using the various MSMQ bindings that are available. Others might be using IBM MQSeries via its C++ or .NET bindings. All these approaches work and they might even be a very good technical solution for your integration problem, but they have one thing in common: they tie you to the platform or messaging vendor.
JMS Courier allows you to use any JMS provider instead of the proprietary messaging solutions. You can choose any one from several dozen available providers. Commercial or free, lightweight or industrial strength, it's totally up to you.
Asynchronous messaging can be a great integration mechanism. Using a free JMS for this purpose and just paying for the C++ or .NET integration can be a financially/technically attractive alternative to other approaches.