Develop Reference

Use of Apache Qpid C++ JMS client

I want to subscribe to a Java Messaging Service (JMS) publish-subscribe service using Apache Qpid. However rather than using Java, I want to use C++. My customer told me this was possible (and even said trivial). Are they correct? Can anyone point me to an example? Everywhere I've looked says that to use JMS I have to use Java. The point here is that the service is a third party service (so I can't change it to use AMQP or any other protocol other than JMS).

This depends quite a bit on what JMS Broker you are using. If the broker supports the AMQP 1.0 protocol as well as whatever native protocol it implements for its JMS client then you might be in luck.
The main thing you need besides support for AMQP 1.0 then is good cross protocol communication support such that a message send from the JMS client can get turned into something meaningful for the subscribed AMQP client or the other way round the broker needs to map incoming AMQP messages into meaningful JMS representations so that the two interoperate successfully.
A Broker like ActiveMQ does support this sort of thing along with support for other protocols as well. You need to have the AMQP support turned on in the broker and then you can use the C++ client from the Qpid project to send messages and receive messages with relative ease.

What application protocol does JMS use?

I've learned a respectable amount about networking protocols in Grad School and in professional experience and sent HTTP requests programmatically using AJAX and such.
The project on which I work professionally uses JMS to communicate and I'm curious about how it works.
When using REST (for instance) one makes an HTTP request with parameters in either the URI or the message header in order to invoke a service and further describe its needs.
A mentor of mine at work and I were discussing how JMS works and I'm struggling to understand at an application level how messages are actually sent. As far as I understand JMS in general (I realize there are many implementations of JMS) it is a specification for how to format data being sent.
Is the message itself still sent via HTTP(S)? Could it be SMTP?
Without going excruciatingly deep I would like to understand how one would, at a code level, send a JMS message from one service to another?
Am I even thinking about this correctly?
Can it be done any number of different ways?
Is there a convention that's used in the industry?
If someone could shed some light on JMS for me I would appreciate it.
Thanks!

JMS is not a protocol, it's an API specification. It's not something like TCP or HTTP protocol. Simply put the JMS specification defines signature of messaging APIs. How the APIs are internally implemented and what protocols they use to communicate with the messaging provider is vendor specific.
The vendor specific JMS implementations know how to communicate with their own messaging provider, but not with any other vendors messaging providers. For example IBM's MQ JMS implementation uses it's own protocol to communicate with IBM MQ Queue Manager, similarly Oracle JMS, Active MQ implementations with their own messaging provider.
Hope this helped.

can we use non java for consuming JMS messages

I understand Java JMS API provides the support for producing and consuming messages asynchronously.
For example, I will implement JMS producer using java and send messages to the JBOSS Message(Destination).
let say the external application say .net applicationin the distributed environment want to consume the messages by connecting to the JBOSS Message(Destination)
Is that possible?

There are several JMS message types:
BytesMessage: can be read by anybody
TextMessage: ditto
StreamMessage: can be read by anybody who can read network-ordered primitive types
ObjectMessage: these are serialized objects and can only be read by Java
MapMessage: these are essentially maps; ditto
JMS itself isn't a message broker, just an API to an existing broker.
If your Java code and the non-Java code can agree on a byte- or text-based message format, you can interchange message between them.

JMS only defines the API an application can use to send and receive messages. It doesn't define a wire format. So it depends on the messaging system you use. JBoss uses HornetQ (since JBoss 6, IIRC), and HornetQ supports other wire formats, namely STOMP and AMQP. It also allows to use REST to send and receive messages.
But, as it is so often the case with interoperability, you'll have to limit yourself for this to actually work. You can't exchange all message bodies (as EJP has elucidated) and probably not all message headers and properties.

Reading a book about it at the moment.
You will need a JMS server that can be accessed through .Net services (either directly or because your JMS can be configured to send the messages to a .Net MOM *).
In any case, it would not be part of JMS but a capability of a particular product. JMS was developed with the intention of being "generic enough" to work in this scenario, but it is up to the specific server implementation (and configuration) to support it (or not).
MOM: Message Oriented Middleware

on a technical level any message over a protocol can be read regardless of message since its all converted to 0's and 1's at some point. However, because JMS are java interfaces you technically wont be using JMS even if you read the messages that way - JMS is the java way to read those messages by using java JMS interfaces and classes that extend those interfaces

What kind of message formats are usually being exchanged in Message Queueing Systems?

I am trying to understand the basics of Message Queues. I see that there are many implementations available as libraries for MQs (ActiveMQ, RabbitMQ, ZeroMQ etc). Also J2EE enabled servers provide such support I think.
What I fail to understand about the topic, is how are these kind of constructs used by real software. I mean what kind of messages are usually being exchanged? Strings? Binary data?
If I understand correctly one can configure the transport protocol, but what is usually the application data format?
Is it a new way of communication, like e.g. SOAP WS or REST WS or RPC etc where each has a different application msg format?

Message queues usually using for application integration. In enterprise it is usually used to implement ESB, but nowadays there are smaller application systems that utilize similar patterns.
Concerning data being transmitted - usually it is XML messages, but actually depends on applications and MQ software - some of them are able to handle binary messages, some are not.
For example imagine you have two applications which require data interchange. If you integrate them using some kind of messaging software such as ActiveMQ, for example, then it will give you some benefits like routing, fault-tolerance, balancing, etc, out-of-the-box.
You may integrate your applications using MQ directly, but ESBs usually
give you ability to use web services: app just calls ws of ESB and knows nothing about underlying architecture.
Also MQs and ESBs gives you a level of abstraction: you may switch your apps in a system absolutely transparent, as long as data exchange interface is preserved.

MQs are mainly used for interprocess communication, or for inter-thread communication within the same process. They provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time. Messages placed onto the queue are stored until the recipient retrieves them.
wikipedia can be good intro to topic. http://en.wikipedia.org/wiki/Message_queue#Standards_and_protocols
Also, to understand diff between webservice and mq, read this thread: Message Queue vs. Web Services?

Java/Python communication via message broker

What is a good solution for communication via message broker that supports both (C)Python and Java/JMS applications? My particular requirements are:
open source solution
Available on Linux-based systems
No rendezvous between sender and receiver required (i.e. uses a message broker)
Multiple producers and consumers supported for a single event queue (only one consumer receives each message)
Unit of work support with two-phase commit (XA support nice to have)
Support for persistent messages (i.e. that survive a restart of the broker)
Supports JMS for Java clients
No component is "fringe", meaning at risk of falling out of maintenance due to lack of community support/interest
If there is a Python client that manages to "speak JMS" that would be awesome, but an answer including a task to write my own Python JMS layer is acceptable
I have had a surprisingly hard time finding a solution for this. Apache's ActiveMQ has no Python support out of the box. ZeroMQ requires a rendezvous. RabbitMQ does not appear to support JMS. The best candidate I have found is a combination of ActiveMQ and the pyactivemq library. But the first and last release of pyactivemq was in 2008, so it would appear that that fails my "no fringe" requirement.
The ideal answer will be the names of one or more well-supported and well-documented open source packages, that you have personally used to communicate between a Java/JMS and Python application, and that do not require a lot of integration work to get started. An answer that includes an "easy" (up to a few days of work) implementation of additional glue code to meet all the requirements above, would be acceptable. A commercial solution, in the absence of a good open source candidate, would be acceptable also.
Also, Jython is out. (If only I could...) The same Python applications will need to use modules only available in CPython.

JMS is a specification not implementation . RabbitMQ is a really option .
I have also happily used HornetQ http://www.jboss.org/hornetq from Jboss as with every thing it is more aligned with every thing Java EE but RabbitMQ would be choice espcially if you are using Spring as well

I have had a surprisingly hard time finding a solution for this.
Apache's ActiveMQ has no Python support out of the box.
ActiveMQ brokers fully support using the Stomp protocol out of the box. Stomp is a text based protocol for messaging that has clients for many platforms and languages.
ActiveMQ's documentation should contain information on how to set up a connector for stomp. In its simplest form, enabling a connector would look something like:
<transportConnectors>
<transportConnector name="stomp" uri="stomp://localhost:61613"/>
</transportConnectors>
Once enabled on the broker side, you can then use any python library that supports stomp. You can then use Stomp on the python side and JMS on the java side for communication with the broker and sending/receiving from specific destinations.

You might want to take a look at OpenAMQ and another look at RabbitMQ.
The underlying messaging technology used by RabbitMQ and OpenAMQ is AMQP. You should be able to easily find Python and Java clients that work against both of these brokers (and ostensibly any other spec-compliant broker).
If JMS is a must-have, then you might be able to find a JMS client out there implemented on top of AMQP (OpenAMQ provided such a client at one time, but I am unsure of its current status).

We had been using GlassFish Message Queue (formerly Sun Java MQ) - it is inherited from OpenMQ
It satisfies most of your requirements, if not all.
We had been using fail over-clustered brokers in Red Hat Linux (RHEL) - it is reliable for heavy usage. Though some 'quirks' lurk here and there.