Non-Java Versions of JMS

OK, so the JMS spec makes sense for market data. But is that just for Java? What about non-Java applications? While JMS is, by definition, a Java standard, the fact is that most JMS suppliers offer non-Java bindings. In effect, the JMS messaging model itself has been adopted as a standard by the market.

Design Approach

In providing non-Java bindings for JMS, our approach is to use native idioms and libraries where possible. This means that our non-Java JMS implementations integrate seamlessly with other APIs and libraries. The goal is to make our API as intuitive as possible for the developer.


Our .NET binding uses the native property getter/setter idiom and event delegates. This means it can be used easily in any .NET language such as C#.NET or VB.NET.


The MetaFluent C binding maps the JMS object-oriented model to a procedural interface with a pattern based on using an opaque "handle" to represent an object instance. The C API also relies on a typical return value pattern to indicate errors (rather than relying on exceptions, as is the case with Java and .NET). The MetaFluent Excel Add-In is an example of a C-based application.


MetaFluent hasn't released a C++ API yet, but our C++ strategy is to provide the source-code for a C++ wrapper around our C API. This avoids any issues with C++ compiler choice. The C++ interface itself will likely be the the Apache CMS interface with an implementation based on our C API.

Regardless of language binding, a JMS Provider still needs to solve the problem of delivering market data via the JMS API.

Also, application dependencies don't stop at the language-specific binding. Read how MetaFluent JMS supports flexible topic-naming conventions and data modeling.