Develop Reference

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.

Automating ActiveMQ to enqueue when RESTful API is hit

I'd like to expose a public RESTful API and either configure our ActiveMQ instance (is possible) to listen at that API and automatically enqueue a JSON or XML version of those API calls, or configure/write software to translate the API call into a message and enqueue the message to an ActiveMQ queue/topic.
So, in other words:
A third party sends an HTTP request (GET/POST/PUT/whatever) to http://myserver.com/api/enqueue
Either:
ActiveMQ is somehow listening at http://myserver.com/api/enqueue and automatically enqueues a toProcess queue/topic with the API call's body; or
I have some kind of servlet listening at that URL and then pass the request on to some software (either open source Java library or something homegrown) that can extract the HttpServletRequest's body and enqueue it to a queue/topic on the ActiveMQ server
So I ask: does ActiveMQ come with this capability out of the box (initial research indicates it doesn't), or are there any open source libraries that would do this for me, or some part of it for me? Or, am I stuck with a custom homegrown solution? Thanks in advance.

In a simple way, ActiveMQ actually does support HTTP/REST-ish interaction with queues out of the box.
As you did ask for Camel, yes, it does support creating more advanced REST API:s and works very well with ActiveMQ (actually, the Camel Core and JMS modulels is part of ActiveMQ distribution).
My favourite way to create REST APIs with Camel is through restlets.
As Brian Roach said, this should be very straight forward to do in plain java code as well with some helper libs, so don't feel bad about a home grown thing here.

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.

Standalone Java JMS Client for WebSphere MQ

Can I use just WebSphere's jar files with standard JMS to send messages to a WebSphere MQ server, or do I need to download their WebSphere MQ Client?

You can use just the jar files for both JMS and the native Java MQ API but the question is whether you really want to. The full client install includes sample programs in source and object form, utilities, tracing and more. When you open a trouble ticket with IBM they may ask for information that you would use these tools to gather. If you do not have the full install you may not be able to provide the requested diagnostic information. For this reason, IBM supports the full client installation. If you are just trying to learn JMS and writing a toy application this is probably OK. If the application is going into Production and you may want to get support on it someday, install the client.
The WMQ client install is free and available as SupportPac MQC7. It is a good is a to develop on the V7 client since it is compatible with the V6 QMgr. This saves you some testing when V6 goes out of service in September 2012.
Note that the JMS Thin Client referred to in another response is described in the Infocenter as "a Java service integration bus JMS client designed to run as an embeddable client in Java SE applications under the IBM®, Sun and HP Java run-time environments (JREs). The client supports no transaction and local transaction models." As noted there it is an SI Bus client not an MQ client, has limited platform support and lacks even single-phase commit. The actual WMQ client is specific to WebSphere MQ, has broad platform support and provides single-phase commit transactionality.
UPDATE:
As of April 24th 2012, there is no longer a charge for the Extended Transactional Client for any version of WMQ on any platform. I've removed the portion of the answer that explained the previous license terms.

You need the appropriate jars for creating what is called a JMS thin client. This will allow you to use standard JMS to talk to MQ. You do not need one of the specific clients unless you want access to the specific MQ API instead of JMS.

Ive seen app-teams do this on countless occasions.
Almost every time they will run into an issue at some point down the line and will then request support/help from their local support.
Diagnosing an issue on an environment that none of the standard mq tools/logging/tracing is virtually impossible. You cant even find out what version of MQ it is (dspmqver)
Different jars from different installations get mixed up, emailed around etc...
I can never understand why people dont just install the client and be done with it. Is it that big a deal to lose however many hundred meg the install takes ?

To send or manage message of Websphere MQ, you can use jms client like HermesJMS + the mq series libs, check it tutorial:
http://www.hermesjms.com/confluence/display/HJMS/WebSphereMQ
Check the demo here: http://www.hermesjms.com/demos/demo_mq.html

How do I get a java application to subscribe to an NServiceBus publisher?

I've asked Google and searched through the NServiceBus website and forums, but I can't seem to find any prescriptive guidance on how I would write a Java application to subscribe to a publisher. Does anyone have any such link or experience?

This scenario is not well supported out of the box - you'll need to do some infrastructure munging yourself. In general, look at how the proxy is built, and add some gateway-style HTTP communication in the mix, or expose that with a standard .NET webservice.

You could manually send the subscribe message to the publisher over MSMQ, the publisher would then send any relevant messages to your java subscribers input queue. But you would need to receive those manually also.
I guess you're then committed to using MSMQ as your transport layer for your entire bus also.