Not going to spend a lot of time on this as there are a bunch of other resources out there that can provide a much deeper perspective on this than I can. But, I do think its worthwhile to at least touch on why from my point of view.
When evaluating messaging systems, I consistently come across vendor specific implementations that aren't very portable. One of my core philosophies is that nothing lasts for ever so you have to design for change. Even if that change is 30 years down the road and some other schmuck is going to have to deal with it, its your responsibility as architect to at least think about how the transition will work and impact the business. Hopefully, you do much more than that and actually design and plan for it. Wishful thinking I know but we can all dream.
As I was looking at a new messaging architecture, the aforementioned philosophy was forefront in my mind. Not delving into the dirty details but this hadn't been a focus for previous revisions of our messaging systems so I as the new guy I was not going to repeat the sins of the past. More importantly, my role is to drive both technology and cultural changes so I must hold myself accountable to make decisions as I would expect others to make. If not, credibility is out the window.
So, prefer open source, must be portable and must be extensible. The choices just got really small really quick; DDS, OpenWire, Stomp and AMQP.
DDS
Data Distribution Service is a relatively new standard that is designed to address the distribution of data for real time systems. DDS describes the protocol, message structure and component behavior. Its not just a wire protocol. It is built around the concept that systems publish data and other systems may have interest in that data. Once an entity is published subscribers to that entity are notified of changes to that entity. For event or state driven architectures that model fits very well. If you were designing system from scratch, you could model your system to fit these constructs. However, many of us aren't that lucky. Secondly, there are very few implementations, although this isn't really a limiting factor. The big issue is that with this architecture there really isn't a clear path forward to change it in the future.
OpenWire
OpenWire is not really "open". Its ActiveMQ's proprietary protocol that only works with ActiveMQ. With that in mind, it wasn't a viable choice.
STOMP
Simple Text Oriented Messaging Protocol that used to provide a common protocol for non-heterorgenous messaging systems & clients to interact. STOMP is client/server based protocol. Clients can only be clients and servers can only be servers. Its also a wrapper to a native API provided to the broker. What this means is that there is no guarantee of behavioral characteristics of the broker itself. Lastly, STOMP is not a standardized or ratified standard through a recognized body like OASIS or OMG, etc.
AMQP
Advanced Message Queueing Protocol is both wire level protocol and an interaction standard. AMQP is a binary protocol that is designed to be ubiquitous like HTTP, FTP, SSH etc. In the AMQP model, there is no client or server but set of well defined interactions. It defines the interaction between systems through routes and links. Such that different AMQP providers could be linked together. Lastly, AMQP is a ratified standard by the OAIS group so there is some level of governance over the standard. with input into leading technology and private sector companies.
Why AMQP?
It really boils down to a couple things. From an implementation perspective, I work for a public company so at some point you need to have support. AMQP has implementations supported by both RedHat and VMWare. The other options were limited to either niche providers or small startups that don't have the breadth and influence. AMQP is designed for high volume low latency financial systems, hmm... sound familiar. AMQP is not a wrapper to something else or an add on like STOMP as such its a first class citizen in the architecture. The specification outlines both the message protocol but how things are supposed to behave which is important developing a portable solution. Lastly, the AMQP implementations out there are wickedly fast in comparison to everything else in the list but DDS. There are host of other reasons but these were the biggies that drove my increased interest and many of the topics forthcoming.
So picked a standard now an implementation...
RabbitMQ versus Apache Qpid (RedHat MRG)
This was actually a pretty trivial selection, I know should have spent more time looking at the actual code. Patterns in the brokers, clients, how systems details are implemented, etc. Frankly, the bullets just didn't justify the extra work. Might have been fun but we all have deadlines. So, the basics were this. RabbitMQ has very limited support C++ which is one of the core decision points, it was a conversation around we will support you on a custom basis, etc. Custom but not comforting while Qpid is written in C++. RabbitMQ has extended AMQP quite significantly whereas the C++ (there is a Java version as well) conforms much closer to the spec. The implementation base in financial services had a much deeper penetration, so I wasn't treading new ground. Qpid had a much larger community of developers and RedHat is a key member of the AMQP working group. Lastly, we already had it as it is part of the RHEL distro or at least most of it. So, the path to adoption by the operational folks is much easier.
So, off I go into the R&D on how does this stuff work. More to come.
