JMS Courier Introduction
You usually find JMS Courier on-line because you have been given the task to look for a way to connect your C++ or .NET application to an Enterprise Java backbone. You quickly located some JMS vendors that claim to offer C++ or .NET bindings, but not both, and you also discover that prices are steep and that the bindings seem to be less than complete.
Then you come across JMS Courier. It claims to be feature-complete. It claims to be fast. It claims to work with any JMS implementation, including the free ones! Could this really be true or are these just inflated vendor claims?
Well, it really is true.
JMS Courier was first released in 2001. We had just previously released the first version of our JunC++ion tool that helps our customer to integrate Java with C++. We found that people had a surprisingly hard time understanding that it could solve their concrete integration problem, even when they understood that JunC++ion solved this kind of integration problem.
Thus JMS Courier was born as a proof of concept, to give people ideas about what might be possible.
How Did We Do It?
We used our JunC++ion and JuggerNET products to generate C++ and .NET proxy types for the complete JMS API and some assorted Java support types. Your developers code to these types, which are provided to you in the form of libraries/assemblies. At runtime, the proxy types delegate in-process to the underlying Java types.
Just to stress this fact: our code generators generate C++ or .NET bindings for Java types, they do not translate the Java types to native code. As the proxy types delegate to Java, you still need a regular 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. JMS Courier is essentially a high-quality shim on top of JMS.
Which JMS Implementations Are Supported
Any spec-compliant JMS implementation is supported. If the JMS implementation does not support a specific JMS feature due to bugs or feature incompleteness, the C++ and .NET types will of course also not support it. Anything that the Java implementation provides via the standard JMS API is supported.
What's Missing?
The only things that are missing are vendor-specific JMS extensions. We stuck to exposing the core JMS specification and Java types that are required to working with the core JMS specification. We added in a generous amount of Java utility types but vendor specific extensions are explicitly not part of the distribution.
If you need to use a vendor-specific JMS API from your C++ or .NET application, you can use JunC++ion or JuggerNET to create a provider-specific version of JMS Courier that includes the proxy types for your vendor's API extensions. We will help you with the customization if you give us a call.
Reliability, Reliability, Reliability...
The fact that the overwhelming 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 three 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."
No such bugs have affected JMS Courier... ever.
- Bugs in the Runtime Library
We've had our share of these over the years, but the majority tended to be relatively trivial and the last one was encountered in 2016. 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.
- Bugs in the Underlying JMS Implementation (at Runtime)
You will be using some vendor's JMS implementation at runtime, and that implementation will undoubtedly have some bugs. Your C++ and .NET clients will encounter exactly the same bugs that your Java clients encounter because they will be using the same Java implementation.
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.
By virtue of being generated, JMS Courier has a pretty stellar track record when it comes to reliability!