We Keep Coding

Are websocket subprotocols like WAMP, STOMP, etc. compatible with each other?

I am looking to leverage WebSockets. I will expose the WebSockets and different client applications will be able to listen to notifications via these WebSockets.
I am planning to use STOMP, but my clients have different preferences as their applications are already using different sub-protocols. I was wondering if there is any cross support available from one subprotocol to another?

In short, no. WAMP and STOMP are not compatible with each other.
The STOMP specification has no "cross support" for anything else. In fact, I've never heard of any widely-used messaging protocol with "cross support" for anything else.
That said, many message brokers support multiple messaging protocols (e.g. ActiveMQ supports STOMP, AMQP, MQTT - all of which can be used over WebSockets) so you can send messages with one protocol and consume them with another protocol. However, I don't know of any widely-used message brokers which support WAMP.

Which protocol does JMS use to send and receive messages?

I want to know if JMS API uses any protocol to transfer messages or if uses its own. If the former, which protocol?
I have read many articles over the net but I couldn't find an answer for this.

The standard JMS API is merely a set of interfaces; JMS providers (such as WebSphere MQ) provide their own implementations for these interfaces.
The only thing that you can say for sure about all JMS implementations is that they all adhere to the JMS API; other than that, a JMS implementation may use any protocol whatsoever in order to fulfill the JMS API contracts.
Now, when you're asking specifically about "protocols", you should also define which "layer" in the communication you are referring to (have a look at the OSI Model, for example). When your JMS client has to talk to a JMS server that is located on another machine on the network (a typical case), the protocol used between the client and the server will be based, in one way or another, on TCP/IP. Over the wire, you'll be able to see TCP/IP packets being exchanged back and forth.
At the higher level, there are no guarantees; you are likely to find proprietary protocols varying between different implementors. Remember that, with JMS, performance is often crucial; JMS vendors put a lot of efforts into ensuring that their protocols ("above" TCP/IP) perform well. HTTP, for example, won't do.

There is no protocol as such that is mentioned in the JMS specs. It is purely dependent on the JMS provider and his approach to offer efficiency and security.One thing that er can be sure of is that whatever protocol provider uses to communicate between server and client will be built upon the TCP/IP protocol(Transport layer). You may have HTTP which is an application layer protocol or if the provider provides it you may have SSL which is a Presentation layer protocol.
For example ActiveMQ supports following protocols
AMQP
List item
MQTT
OpenWire
REST
RSS and Atom
Stomp
WSIF
WS Notification
XMPP
More details here.

It uses AMQP protocol. You can use JMS to do 1-to-1 communication using Message Queue provided by Middleware. If you want to send 1-to-many using JMS, the middleware provides Topic. Both of them use binary format in a bit stream at least in IBM MQ.

AMQP or XMPP for Client Notifications

I'm designing a replacement for a custom messaging system that is currently used to notify a JavaScript web application about changed content from the server side (Java). This legacy messaging system works through Flash XMLSocket by use of custom text based protocol and plain Java sockets.
The replacement will be used not only by the web application (through web sockets instead of Flash) but by an additional desktop client application written in C# too.
My requirements are:
user authentication
transport encryption (SSL/TLS)
bidirectional message exchange
some sort of (automatic) publish/subscribe so that users get only the messages they are allowed to receive
message exchange based on an established protocol (so that we may use existing libraries where possible)
cluster-able server components
At this time the messaging system will only be used to publish updates down to the clients. The clients will react to these messages and acquire further information directly from the server (not via the messaging system). If this new messaging system is established successfully it may be used for more advanced use cases in the future. Some possibilities may include users chatting, file exchange and remote control of the server components.
I did a little research about viable technology to implement these requirements and I think my choices boil down to either using ejabberd (XMPP) or RabbitMQ (AMQP). What are the main pros and cons of these two systems regarding my requirements? We already use RabbitMQ for other parts of our system infrastructure so it was my natural choice. I'm just not sure if it would be a good idea to have client applications connect directly to such an critical main component. This may be mitigated though by just using a different RabbitMQ installation for the client notifications.

Well you could use both protocols to fulfill your needs, xmpp is an extensible protocol so no doubt the things that you're looking for does allready exist as a plugin or whatever is the correct term for a protocol. However some, me included, might actually see this as a downside, and they add extra complexity to the protocol. Another thing to keep in mind is that xmpp was primarily designed to be a instant messaging protocol. For example publish/subscribe is an extension of xmpp and not part of the protocol itself.
That being said xmpp is backed by organisations such as Google, which means that there are some major players using this protocol, so no doubt some of the extensions are really good and well written/thought out.
On the other hand you have AMQP, a protocol almost specifically designed for what you're after. It is backed by such organisations as JP Morgan, Cisco, Credit Suisse etc. so no doubt AMQP is a protocol to be counted on, even though early versions of it has been critized
When it comes to using RabbitMQ there seem to be some issues with memory, however I cannot speak much of that since I was only notified about this issue, and never really got into actually fix it or even understand it. However there seem to be quite a few people experiencing this on different versions of RMQ.
But for me RabbitMQ has never crashed (hey if erlang is known for one thing, it's stability), it has been a joy to setup and it is really easy to setup in a cluster, and you can have your queues easily mirrored on several instances of RMQ and you can have an extra layer of security by having one or more instances write messages to disk.
So I'd say go with RabbitMQ and AMQP, I believe it's a protocol well suited for your needs, but having said that xmpp could probably do the work just fine aswell.
I've read this book, which is a nice introduction to AMQP and RabbitMQ but I find it lacking in the technical aspect, it's basically a good tutorial.
PS: I feel I should be honest and say that I'm not really sure what bidirectional message exchange entails, but if it means sending and receiving messages, you're in the clear on that point also with AMQP. :)
I hope this helped shed some light on which protocol to choose.
Edit
RabbitMQ has something called virtual hosts which acts like an own instance of RabbitMQ so you don't have to start with setting up a cluster just to handle separate responsibilities. Depending on how you set up your queues and exchanges I don't see a problem with clients connecting to the RabbitMQ server, but clustering is without a doubt a good idea. It also seems that setting up RabbitMQ with HAProxy is very easy, but yet again that is something I have no experience of.

C++ JMS client or C++/C SOAP Client

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

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 :
Mule
ServiceMix
Fuse
Apache Camel
Spring Integration
JBoss ESB
EDIT:
Given the clarification I will refine my answer:
You need a common message broker that is accessible to C++ and Java such as ActiveMQ.
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)

The SonicMQ site seems to indicate that they support C++.
It would appear that this is suitable.

There are C++ libraries for SonicMQ. The main constraint is that you have to be using the same build (ie. STL libraries, etc) that Sonic used to compile the libraries.
http://web.progress.com/en/sonic/sonicmq-clients.html
Of course you asked this question over half a year ago, so this information is probably a bit late. :-)

Best Java supported server/client protocol?

I'm in the process of writing a client/server application which should work message based. I would like re-use as much as possible instead of writing another implementation and curious what others are using.
Features the library should offer:
client and server side functionality
should work message based
support multi-threading
should work behind load balancer / firewalls
I did several tests with HTTPCore, but the bottom line is that one has to implement both client and server, only the transport layer would be covered. RMI is not an option either due to the network related requirements.
Any ideas are highly appreciated.
Details
My idea is to implement a client/server wrapper which handles the client communication (including user/password validation) and writes incoming requests to a JMS queue:
#1 User --> Wrapper (Check for user/password) --> JMS --> "Server"
#2 User polls Wrapper which polls JMS
Separate processes will handle the requests and can reply via wrapper to the clients. I'd like to use JMS because:
it handles persistence quite well
load balancing - it's easy to handle peaks by adding additional servers as consumer
JMSTimeToLive comes in handy too
Unfortunately I don't see a way to use JMS on it's own, because clients should only have access to their messages and the setup of different users on JMS side doesn't sound feasible either.

Well, HTTP is probably the best supported in terms of client and server code implementing it - but it may well be completely inappropriate based on your requirements. We'll need to actually see some requirements (or at least a vague idea of what the application is like) before we can really advise you properly.

RMI works nicely for us. There are limitations, such as not being able to call back to the client unless you can connect directly to that computer (does not work if client is behind a firewall). You can also easily wrap your communication in SSL or tunnel it over HTTP which can be wrapped in SSL.
If you do end up using this remember to always set the serial version of a class that is distributed to the client. You can set it to 1L when you create it, or if the client already has the class use serialver.exe to discover the existing class's serial. Otherwise as soon as you change or add a public method or variable compatibility with existing clients will break.
static final long serialVersionUID = 1L
EDIT: Each RMI request that comes into the server gets its own thread. You don't have to handle this yourself.
EDIT: I think some details were added later in the question. You can tunnel RMI over HTTP, then you could use a load balancer with it.
I've recently started playing with Hessian and it shows a lot of promise. It natively uses HTTP which makes it simpler than RMI over HTTP and it's a binary protocol which means it's faster than all the XML-based protocols. It's very easy to get Hessian going. I recently did this by embedding Jetty in our app, configuring the Hessian Servlet and making it implement our API interface. The great thing about Hessian is it's simplicity... nothing like JMS or RMI over HTTP. There are also libraries for Hessian in other languages.

I'd say the best-supported, if not best-implemented, client/server communications package for Java is Sun's RMI (Remote Method Invocation). It's included with the standard Java class library, and gets the job done, even if it's not the fastest option out there. And, of course, it's supported by Sun. I implemented a turn-based gaming framework with it several years ago, and it was quite stable.

It is difficult to make a suggestion based on the information given but possibly the use of TemporaryQueues e.g. dynamically created PTP destinations on a per client basis might fit the problem?
Here is a reasonable overview.

Did you tried RMI or CORBA? With both of them you can distribute your logic and create Sessions

Use Spring....Then pick and choose the protocol.

We're standardizing on Adobe's AMF as we're using Adobe Flex/AIR in the client-tier and Java6/Tomcat6/BlazeDS/Spring-Framework2.5/iBATIS2.3.4/ActiveMQ-JMS5.2 in our middle-tier stack (Oracle 10g back-end).
Because we're standardizing on Flex client-side development, AMF and BlazeDS (now better coupled to Spring thanks to Adobe and SpringSource cooperating on the integration), are the most efficient and convenient means we can employ to interact with the server-side.
We also heavily build on JMS messaging in the data center - BlazeDS enables us to bridge our Flex clients as JMS topic subscribers. That is extremely powerful and effective.
Our Flex .swf and Java .class code is bundled into the same .jar file for deployment. That way the correct version of the client code will be deployed to interact with the corresponding middle-tier java code that will process client service calls (or messaging operations). That has always been a bane of client-server computing - making sure the correct versions of the respective tiers are hooked up to each other. We've effectively solved that age-old problem with our particular approach to packaging and deployment.
All of our client-server interactions work over HTTP/HTTPS ports 80 and 443. Even the server-side messaging push we do with BlazeDS bridged to our ActiveMQ JMS message broker.