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.

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

sending message from xmpp server vysper in java

I have set up simple server and client, but i don't no how to send message from xmpp server to client. Please give me some help. If possible then suggest me some links.

This is a question which surprisingly often comes up for Vysper. There are several reasons for even asking the question, one particular reason I think is that a HTTP web server in fact works in such a way that it creates and sends content (HTML, CSS etc.) to the agent a.k.a. web browser.
In message-based protocols like email and chat this is a bit different.
Emails are created and consumed by the agents a.k.a. the email clients. Servers mostly only act as Message Brokers (http://en.wikipedia.org/wiki/Message_broker), including aspects like authentication, filtering, storing etc. Rarely do they produce their own email messages out of themselves. Often, a few central accounts (e.g. order#acme.com, support#acme.com) create most of the emails, meaning that the actual messages are produced by an email client and delivered by the server on behalf of the client. (Additionally, email/SMTP has the specialty that clients send out email directly to the receiver's email server which is a nightmare going by the name of /spam/.)
In general, XMPP is no difference here. XMPP chat clients connect and send out and receive messages. The XMPP server brokers the messages. So, to answer your question, in most cases it is sufficient and suggested to have a central account communicating with all the other accounts. It's the simplest and best solution.
However, XMPP offers a little bit more than chat. It has extensions for wizzard-like workflows based on forms, publish/subscribe and administation/commands.
You can add your own extension, if you really need to:
For example, have a look at the VCard extension here: http://svn.apache.org/viewvc/mina/vysper/trunk/server/core/src/main/java/org/apache/vysper/xmpp/modules/extension/xep0054_vcardtemp/
Foremost, I'd recommend to subclass org.apache.vysper.xmpp.modules.core.base.handler.DefaultIQHandler This is like implementing your own Servlet by subclassing DefaultServlet. It contains the XMPP stanza logic you want to provide.
Additionally, you need to plug your handler into the server. This is best done by following the example in VcardTempModule, which
provides a Handler instance and registers it
initializes persistence (or any other backend connection you might need)
makes your extension's namespace known and announces your IQ stuff in the Service Discovery
If you need persistence, have a look at the VcardTempPersistenceManager.
What remains to be done is to make your Module known to the server. If you use Spring, add one line to the Spring configuration. If you use an embedded approach, you'd need to call the equivalent to server.addModule(new VcardTempModule()); like it is done in org.apache.vysper.xmpp.server.ServerMain
Now, if you'd want to emit new Stanzas (messages) which are not a reaction to other Stanzas going through the server, you'd also need to start off your own Thread which is able to create and send Stanzas.
But again, the preferred way is to have the clients create all messages.

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.

Using JMS or ThreadPool to send email messages

I will like to know:
I have a scenario. If a user adds a product to the system (I'm developing), there's a listener that sends a notification to the user's client base notifying of a new product added by the user.
I've read this thread and (seeing I've never used JMS nor ThreadPool before) I was wondering whether I should use JMS or ThreadPooling.
I am using Tomcat 5.5 and higher and JBoss 5 and higher (depending on company last resort) to deploy my web application.
If I use JMS, do I use Apache ActiveMQ or JBoss Messaging? Are they both compatible to run on both platforms (Tomcat and JBoss)?
Thanks in advance.

For communicating between applications, JMS is a very good solution, especially for events and notifications. JMS allows for such notifications to be sent and received using what is known as asynchronous messaging whereby the sender and receiver have no knowledge of one another and no requirement to be available at the same time.
ActiveMQ is a very widely used message broker that provides client APIs for Java, C/C++, C#, Perl, PHP, Python, Ruby and more. This allows the use of JMS with applications written in Java and other languages.
I have implemented JMS messaging many, many times for a large variety of business situations to handle events and notifications. The vast majority of these times, I have recommended and/or used Spring JMS no matter what message broker is being used. Spring JMS is incredibly easy to use, extremely robust and highly scalable. Spring JMS removes the complexity of creating your own message producers and message consumers, which can save you a tremendous amount of time.
To see how easy it is to send messages using Spring JMS, check out a blog post I wrote recently titled Using the Spring JmsTemplate to Send JMS Messages. I'm also working on a blog post about receiving messages using Spring JMS.
If you have any further questions, let me know.
Bruce

I had a similar requirement once, and we used JMS. Then main problem was how to deal with errors because SMTP is indeed not transactional:
is it ok if some email are lost?
is it ok if some email are sent twice?
We decided it was better to send the message twice, and here is more or less the design we had:
We relied on container managed transaction and if for some reason the email can not be sent, we decided to rollback the JMS transaction; the message would be redelivered later by JMS and an new attempt to send the message was done.
If the JMS message delivery transaction failed after the email was sent (e.g. because of a problem with JMS), the transaction would be rolled back automatically and the message was redelivered later. In this case, the email was sent twice because STMP is not transactional.
Even if the email can be sent (from point of view of code), the SMTP server can still have problem later. In this case, the JMS have been delivered and consumed, so we had no way to know which email had been processed and how to re-send them manually.
But we were already using JMS. I would not introduce JMS just for that given that the main argument is that JMS is transactional, but SMTP isn't anyway.
I would go for something lighter -- possibly with a ThreadPool -- and store the state in a database to know which email need to be sent or has been sent. If there are some problem, you can look at the database and take the ad-hoc decisions.

I know that this reply is very late to this dicsussion, but I hope it will still be valuable for folks seeking info on integrating ActiveMQ and Tomcat.
I've had many people ask me for help with issues they have had integrating ActiveMQ and Tomcat so I decided to write some articles about it. Not only is this topic covered in ActiveMQ in Action (see chapter 8), but I also published a series of articles on it titled ActiveMQ and Tomcat: Perfect Partners. Hopefully people will find this helpful.

I would go for a persistent JMS (I have used only WLS JMS and Websphere MQ so can't compare AQ vs JBoss, whichever offers a better guarantee for delivery). Also, I would seriously consider making the email engine a completely separate application, depending on how much you expect the traffic to grow.