JMS Courier for C++/.NET messaging
JMS Courier is a very successful Codemesh product. It enables C++ or .NET applications to use any Java Message Service specification v1.0.2 or v1.1 -compliant JMS provider for its asynchronous enterprise communications needs. You do not have to rely on optional (and often dubious) provider-specific C++ or .NET interfaces that will lock you into one particular provider's implementation for the rest of your life.
JMS Courier leverages Codemesh's in-process integration technology to convey all JMS features to the C++ or .NET developer. While we really mean "all" when we say "all", we list some of the features in the list below.
- support for all standardized message types, including ObjectMessage.
- support for all JMS implementation-supported modes of operation:
- support for all message attributes.
- support for JNDI-based lookup of queues or topics.
- support for natively (C++ or .NET) implemented MessageListeners and ExceptionListeners.
- support for transactions (if the underlying JMS implementation supports them).
How we did it
We used our JunC++ion and JuggerNET products to generate C++ and .NET bindings for the JMS API and some assorted Java support types. Just to stress this fact: our code generators generate C++ or .NET bindings for Java types, they do not translate the Java types. This means that you still need a JMS implementation to perform the actual messaging, JMS Courier simply provides an easy-to-use C++ and .NET gateway, both at development- and at runtime.
The fact that the majority of the code you will use as part of JMS Courier is computer-generated has some fairly dramatic consequences: while it does not guarantee the absence of bugs, it guarantees that there are only two kinds of bugs:
- systematic bugs in the generated code.
The chance that someone already stumbled over this kind of bug in the past is very large. We have a fairly large and active user base for all our products, so chances are that if there were a bug at all, it would be a fairly obscure one. To provide a now fixed code generator problem from the past as an example of such a systematic bug, here's a bug description: "two-deep nested inner interfaces don't generate correctly."
- bugs in the runtime library.
We've had our fair share of these, but the majority tends to be relatively trivial. You will benefit from not just the JMS Courier user base filing bugs against this module but from all JunC++ion and JuggerNET users as well! The runtime library is a shared component between all three products.
Why do we spend so much time talking about bugs? JMS is an enterprise messaging framework, so in all likelihood your C++ or .NET applications have pretty high reliability and performance requirements. We would never have dared publishing JMS Courier if we had had to handwrite or even just manually touch the generated types.
One other implication of the derivation of JMS Courier is that you could use our code generators yourself and add your custom Java types to the set of generated types, thereby publishing your own Java types in the same manner as we published the JMS API. This is trivially easy because the JMS use case is a packaged example in our code generator distribution. You would only have to modify the example build script to generate your custom JMS integration type set in addition to the JMS types.
How does it work?
At development time, you simply compile and link with our supplied libraries. At runtime, our in-process technology will load a JVM into your native process and execute all Java parts on behalf of the native code. This is described at more detail in the in-process document and the code generator runtime documentation. You might also wish to take a look at the architecture pages for the C++ and .NET integration products. To summarize the relevant parts here:
- There is a one-on-one correspondence between your native objects and underlying Java objects.
- When the native instance is destroyed/deleted/finalized, the underlying Java instance becomes eligible for garbage collection. This works safely in the presence of exceptions.
- The only additional threads that are started are the ones that are started by the Java infrastructure (garbage collector, etc.) and the JMS implementation (varies). JMS Courier itself is thread-neutral.
- Your native thread of execution where you make a Java call through a native proxy is the same thread on which the Java call is executed.
The only things that are missing are provider-specific extensions. We stuck to exposing the core JMS specification and Java types that are required to working with the core JMS specification. Vendor specific extensions are explicitly not part of the distribution.
You can use JunC++ion or JuggerNET to create a provider-specific version of JMS Courier if you wish to use such features at the same level of abstraction as the standard JMS Courier types. We will help you with the customization if you give us a call.
Which JMS providers are supported?
It should work with any spec-compliant JMS provider. We need to stress that JMS Courier will faithfully expose any JMS provider-specific bugs and spec violations to the C++ or .NET side. JMS Courier does not fix any provider bugs or spec-incompatibilities!
Our customers have successfully used JMS Courier with at least the following JMS providers (they don't always tell us which ones they're using and when they tell us, they don't always provide us with details):
nirvana is a high-performance, commercial messaging system with a very good JMS interface. It is popular in the financial industry and Codemesh enjoys a very good relationship with my-channels.
Due to this relationship, we can resell nirvana as a fully supported backend for JMS Courier.
Check out the runtime configuration for nirvana here.
Popular open source application server with embedded JMS.
Check out the runtime configuration for JBossMQ here.
|IBM WebSphere MQ||
IBM's industrial strength messaging solution.
OpenJMS is an open source JMS implementation that is popular as a stand-alone messaging solution.
Check out the runtime configuration for OpenJMS here.
BEA's enterprise messaging system, bundled with WebLogic application server.
Check out the runtime configuration for WebLogic JMS here.