AMQP in 10 mins : Part2 - Achieving Interoperability And Avoiding Vendor Lock -in

Background
One of the key issues with any software is non-interoperability and vendor lock in. Most messaging systems prior to AMQP did not interoperate with each other. For example messages from Tibco's Rendezvous couldn't be routed through IBM's MQSeries. If two messaging systems need to be connected, there are two options.

• Using a message bridge you could convert from one format to the other. However a bridge would be slow as the conversion adds latency. Also you would need to understand the wire format of each of those systems.
  
• Replacing one system with the other, which is costly and risky. Downtime can have a severe impact on the company's revenue model.
  

Therefore once a messaging system is chosen, users are reluctant to change and locked in with the same vendor while spending large sums of money as licensing costs.

What if we have messaging systems(from different vendors) that can understand each other? If so connecting two messaging systems or replacing one system with the other can be done with minimum costs and risk. Since the semantics (behaviour) are the same the chance of something going wrong is relatively low. This is a key goal for the AMQP protocol.

So what does it take to achieve interoperability and avoid vendor lock-in?

• All brokers need to behave the same way
  
• All clients need to behave the same way
• Use a standard for commands on the wire
• Use a language neutral type System
• Use open standards and permit royalty free usage of such a protocol.
  

AMQP satisfies the above requirements by

• Defining a network wire-level protocol
• A defined set of messaging capabilities (The AMQP Model)
• A simple language neutral type system
• Using open, existing, unencumbered, widely implemented standards
• Providing royalty free usage of the protocol
  

Broker semantics are defined explicitly. One can partially imply the semantics from the wire-protocol. However we need to define the semantics explicitly in order to guarantee exact behaviour in each broker/client implementation. So the protocol defines a set of commands to manipulate state in a peer. These commands are grouped by functionality into classes. For example the Queue class has various methods to manipulate state within a broker.
Ex. queueDeclare, queueBind, queuePurge, queueDelete & queueQuerry

More details on the wire protocol will be discussed later on. The next few posts will focus on discussing the semantic model.

Next Part : Part3 - Flexible Routing Model

Prev Part : Part1 - Introduction