tags:

views:

40

answers:

2

I have an application in C++, but it'll need to 'talk' to Java based message-service. In the past we used WebSphere MQ and used their C++ libraries to do the 'talking'.

So I am in search of (ideally) free C++ to Java solution which doesn't hold the whole JVM in memory.

The other option I've looked into is SOAP. I've looked into Axis2-C but it gives me the whole server implementation, which I don't need. I've seen talk about gSOAP but saw mixed comments here. And again it seems to be providing me with a whole server.

I could write the code myself - but it goes against my (Java based) belief that excellent free code exists out there.

Thanks! A'z

+2  A: 

There are a couple of points here which don't make sense to me, JMS is a java specific abstraction over a generic messaging API, much the same way that JDBC is a java specific abstraction over a generic database API.
I can't imagine anyone wanting a JDBC driver for a C++ application, they would rather use an ODBC driver.

So if I assume that your objective is to send messages without using Websphere MQ from a C++ application, then I can recommend that you consider the following:

  • Do you need asynchronous messaging? i.e. store message on queue until message is consumed?
  • If yes, then web-services will not work for your application, unless you are prepared to host a web-server to receive the responses, and call back to your application.

You haven't mentioned whether the underlying java based message service is going to be JMS or WebServices.
You could consider using ActiveMQ as a messaging provider, it provides an implementation of the JMS API and also implements the STOMP protocol, which has client libraries for a number of languages including C++.

You could leave open your decision for end-point protocols while you try out various options, by implementing an integration layer using something like Mule.
You can quickly develop small integrations on Mule e.g. to accept a Message on ActiveMQ, and post it to a WebService and put the WebService response on a different ActiveMQ response queue. Or vice-versa, accept web-service call and post SOAP onto JMS queue, wait for JMS response and build SOAP response.

There are many ESB-like frameworks which can facilitate these sort of integrations to various degrees :

EDIT: Given the clarification I will refine my answer:

  1. You need a common message broker that is accessible to C++ and Java such as ActiveMQ.
  2. You need a small / lightweight integration layer such as some of those above to accept from ActiveMQ and forward to SonicMQ, and vice-versa.

2.1 From what I know of Sonic, they have an ESB stack that should be able to do this instead of using one of the containers/frameworks mentioned above, but that will open up issues of integration ownership between you and the client.

I found 3 links showing Sonic support for C and C++ :
- http://www.sonicsoftware.com/products/docs/sonicmq_app_server_ds.pdf
- http://www.sonicsoftware.com/developer/documentation/docs/sonicmq_c_v60.pdf
- http://communities.progress.com/pcom/servlet/JiveServlet/download/10809-3-10161/cclients_readme_76.htm (dodgy mime type on this link)

crowne
Right, let me clarify myself (and apologies for being unclear). The current MQ is being change to be a new message layer - SonicMQ (this is a client's change). As far as we are aware there are no C++ libraries to 'talk' to SonicMQ as there are for IBM MQ. Therefore I have both JMS and WebServices(SOAP) as possible transport layers. My C++ application can't change as it is not small at all...
aabramovich
Yes, thanks for these! Somehow a couple of us here have managed to avoid finding them. In any case... I still would like to still know what it takes to get a 'ready-made' SOAP client (as thin as possible)
aabramovich
From C++ you could take a look at the QT soap component. http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Utilities/qtsoap/ the link includes an example of how to do a google search using SOAP.
crowne
A: 

The SonicMQ site seems to indicate that they support C++.

It would appear that this is suitable.

sdg