Using JMS from C++


Many organizations build enterprise backbones on top of asynchronous messaging infrastructures. Very often they choose a Java Message Service (JMS) implementation on which to build the erst of the system. The reasons for this are manyfold:

  • there are many competing JMS implementations (providers), many of them free.
  • JMS offers a simple yet powerful abstraction layer for asynchronous messaging.
  • most JMS implementations are pure Java, therefore very platform portable.

The only problem with JMS is that it is a Java technology and leaves all your applications written in C++ out of the picture. Some providers offer prorpietary product extensions that allow more or less (usually less) complete access to the messaging infrastructure from C++. The problem with these vendor extensions is that they provide the ultimate lock-in. Once you've taken advantage of the vendor's proprietary C++ interface, you cannot simply switch out your JMS provider for another one without disabling your C++ application or necessitating a costly rewrite.


JMS C++ architecture

As the image on the right shows, you have a messaging backbone to which a Java publisher and a listener are connected. This is the traditional picture for JMS-based applications.

The new factor in this design is the C++ participant in the top left corner of the picture. This application is written entirely in C++, using JunC++ion-generated proxy types for the JMS API types. The C++ developer implements a MessageListener in C++ by extending a special callback proxy type for the JMS MessageListener interface.

Under the hood, completely hidden from the C++ developer, the proxy types and the Codemesh runtime load a JVM into the C++ process and delegate (purple connectors) to the underlying Java objects and, in this callback case, from the JVM back into the C++ process. All threading-related issues are totally transparent to the C++ developer because the JMS implementation takes care of kicking off the required housekeeping threads for the management of the backbone connection.

  1. The developer is writing C++ code that happens to look a lot like Java code, but is otherwise blissfully unaware of the fact that there is any Java involved.
  2. The backbone is totally unaware that there is a C++ client connected to it. As far as it is concerned, it is communicating with a Java client, which happens to be "hosted" by a C++ application.
  3. You do not need any particular JMS provider features for this to work.

This kind of integration is just about as invisible and non-intrusive as possible.

Development process

By the time you're looking at Codemesh products, you typically already have a JMS provider in place, be it a stand-alone implementation or one bundled with an application server. Occasionally though, we have customers who have the luxury of not only picking our products for the C++ integration but also the JMS provider for the actual messaging. Regardless, whatever JMS provider you pick, it typically comes with a bundled jms.jar file containing the types described by the JMS specification. These are the only (core) types we need to expose. We're actively uninterested in vendor-specific JMS implementation types because using those types would tie us to the particular vendor's implementation.

You import the jms.jar file into the code generator and generate the proxy types. You will wish to enable several support types like InitialContext, some reflection API types, some collection types, and the primitive wrapper types to ensure maximum usability of the proxy API.

Once the C++ bindings have been generated (as source files), you can either build them into a library and use that library or you can add them directly to your C++ project, it's totally up to you. Regardless, you can now write C++ code such as this (the lookup portions might differ for your JMS provider):

int main( int argc, char * argv[] )
    String                  queueName = null;
    Context                 jndiContext = null;
    QueueConnectionFactory  queueConnectionFactory = null;
    QueueConnection         queueConnection = null;
    QueueSession            queueSession = null;
    Queue                   queue = null;
    QueueSender             queueSender = null;
    TextMessage             message = null;
    int                     NUM_MSGS;
    if ( (argc < 2) || (argc > 3) ) 
        System::out.println("Usage: SimpleQueueSender <queue-name>"
" [<number-of-messages>]"); exit(1); } queueName = argv[ 1 ]; printf( "Queue name is %s\n" + argv[ 1 ] ); if( argc == 3 ) NUM_MSGS = Integer( argv[ 2 ] )).intValue(); else NUM_MSGS = 1; /* * Create a JNDI API InitialContext object if none exists * yet. */ try { jndiContext = InitialContext( _use_java_ctor ); } catch( NamingException & e ) { printf( "Could not create JNDI API context: \n",
e.toString().to_chars()); exit(1); } /* * Look up connection factory and queue. If either does * not exist, exit. */ try { queueConnectionFactory = QueueConnectionFactory::dyna_cast( jndiContext.lookup( "QueueConnectionFactory" ) ); queue = Queue::dyna_cast( jndiContext.lookup( queueName ) ); } catch( NamingException & ne ) { printf("JNDI API lookup failed: %s\n", e.toString().to_chars() ); exit(1); } /* * Create connection. * Create session from connection; false means session is * not transacted. * Create sender and text message. * Send messages, varying text slightly. * Send end-of-messages message. * Finally, close connection. */ try { queueConnection = queueConnectionFactory.createQueueConnection(); queueSession = queueConnection.createQueueSession( false, Session::AUTO_ACKNOWLEDGE); queueSender = queueSession.createSender( queue ); message = queueSession.createTextMessage(); for( int i = 0; i < NUM_MSGS; i++ ) { char buffer[ 64 ]; sprintf( buffer, "This is message %d", (i + 1) ); message.setText( buffer ); printf( "Sending message: %s\n" , buffer ); queueSender.send( message ); } /* * Send a non-text control message indicating end of * messages. */ queueSender.send( queueSession.createMessage() ); } catch( JMSException & je ) { printf( "Exception occurred: %s\n", e.toString().to_chars() ); } if( queueConnection != null ) { try { queueConnection.close(); } catch( JMSException & je) { } } }

If you know the Java original, you will recognize how similar that C++ code is to it. There are just a few C++'isms that you have to get used to, otherwise it looks immediately understandable and it is certainly highly maintainable.


Your C++ application will require the Codemesh runtime library to be present and it will require a Java Runtime Environment (JRE). You can bundle a so-called "private" JRE with your application, or you can rely on the presence of a JRE on the client host. The latter alternative might be perfectly acceptable in well-controlled intranet deployment scenarios.

There are no configuration changes required to accommodate the backbone communications (assuming you already have things set up for Java backbone clients).


At first, it sounds strange to use in-process integration for as explicitly an out-of-process use case as messaging, but it has some huge advantages when compared with competing integration approaches. It has better performance, better security, easier deployment, and great maintainability. On top of that, you have JMS vendor independence. All of these factors combine for an excellent cost/benefit picture.

Copyright 2006-2011 by Codemesh, Inc., ALL RIGHTS RESERVED

jms c++
home products support customers partners newsroom about us contact us