Rajith’s Column

Danushka Menikkumbura has got AMQP support going for Axis2/C via the Apache Qpid project.
This will only work on Linux as the Qpid c++ client so far has only a Linux implementation. Currently there is ongoing work from two contributors trying to port the code base to support Windows and Solaris. This is scoped for the M3 release.

Watch the WSO2 blog space or the Axis2/C website for a tutorial/blog post from Danushka.

I have tested the following with Axis2 1.4 release and the up comming Synapse 1.2 release.

Documentation is broken into two sections.
It is important to read and understand the pros and cons for each option.

If you have any questions/suggestions please post on qpid-users@incubator.apache.org
And/Or open a JIRA at http://issues.apache.org/jira/browse/qpid
Your feedback is most welcomed.

1. Configuring the JMS transport using Apache Qpid M2.1 release.
   • This version is the latest stable release and supports the 0-9 version of the AMQP protocol.
   • You can download it from here
   • It is recomended that you use the Java broker.
   • This is the recomended production version.
2. Configuring the JMS transport using Apache Qpid trunk. (with the usual caveat that it is a less stable and a moving target).
   • The trunk supports the 0-10 version of the AMQP protocol and the next release is M3.
   • You can build it from source. https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid
   • Has the following enchancements in the JMS client over M2.1
     1. You can specify multiple binding keys per destination. i.e you could bind a queue to a particular exchange using several binding keys there by allowing you to listen from multiple sources.
     2. You can bind your queue to any exchange type using the binding URL.
     3. You can set the following options per JMS connection.
        • maxprefetch - The maximum number of pre-fetched messages per destination
        • sync_persistence - When true, a sync command is sent after every persistent message to guarantee that it has been received by the broker.
     4. A new blocking transport (as an alternative to MINA) that gives much better latency, memory and increased throughput in many cases.
     5. Currently only the c++ broker supports the 0-10 version and only works on linux.
     6. In the pipeline
        • Java Broker - expected to be in M3 release. Currently being refactored
        • C++ broker - solaris and windows port are in progress (likely to be in M3 release)

1.0 Configuring the JMS transport using Apache Qpid M2.1 release

• 1.1 Qpid provides a convinient properties file based JNDI mechanism.
  • For provider URL please specify the location of the jndi.properties file.
  • The following link provides documentation for the jndi.properties file. JNDI How To
  • The connection URL format is given here. Connection URL format

  
<parameter name="myTopicConnectionFactory">
<parameter name="java.naming.factory.initial">org.apache.qpid.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="java.naming.provider.url">file:///opt/workspace/sandbox/axis2-1.4</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName">TopicConnectionFactory</parameter>
</parameter>


• 1.2 If you didn’t specify a custom destination for your service via the “transport.jms.Destination” parameter then the JMS transport will create a queue with the service name as its name. In AMQP world the above translates as follows. A queue will be created with service name as its name and will be bound to the amq.direct exchange with service name as the routing key
• 1.3 If you specify a custom destination name via transport.jms.Destination in your services.xml then Qpid will look that up in the jndi.properties file and create queue based on the definition given in the file.
  The binding URL format is given here. Binding URL format

2.0 Configuring the JMS transport using Apache Qpid trunk
In addition to whats described above you can do the following.

• 2.1 Specifing multiple binding keys per destination
  
  destination.wetherServiceQueue=topic://amq.topic/WeatherQueue?bindingkey='weather.us.*'&bindingkey='weather.ca.*'
  
  The above will create a queue named WeatherQueue and will bind it to amq.topic with ‘weather.us.*’ and ‘weather.ca.*’ as the binding keys. The broker will then route any messages that matches the above patterns into WeatherQueue.
• 2.2 Binding your queue to any exchange type the broker supports by using the binding URL.
  
For example if you want to bind your queue to a fanout exchange
destination.top10StockQueue=fanout://amq.fanout/WeatherQueue

  
• 2.3 Setting prefetch limit and sync_persistence per JMS connection
  
  amqp://username:password@clientid/test?brokerlist='tcp://localhost:5672'&maxprefetch=2000&sync_persistence=true

  
• 2.4 Using the new transport
  
  Set -Dtransport=io when starting Axis2 or Synapse.

Read the rest of this entry »

AMQP defines four standard exchange types (routing algorithms) that covers most of the common messaging use cases. All AMQP brokers are required to support each of these exchange types and pre declare an instance of it identified by a standard name. The idea is to provide a simple out-of-the-box solution to most users. Users are free to create more instances of these exchange types with their own names. Also as mentioned in the previous post, users can create different exchange types and instances of them.

It is important to note that with any exchange type, a message can be matched with more than one queue if two or more queues are bound with the same routing criteria.

Direct Exchange
The exchange does a direct match between the routing key provided in the message and the routing criteria used when a queue is bound to this exchange.

(Click on image)

The most common use case is to bind the queue to the exchange using the queue name. However it is important to note that you could use any value for the binding.

A broker is required to provide an instance of this exchange named “amq.direct“. The Nameless Exchange is a special instance of the above exchange type where all queues are bound to this exchange automatically using the queue name as the routing criteria. This exchange instance has no public name, hence messages sent without specifying an exchange name are directed to this exchange.

Topic Exchange
The exchange does a wildcard match between the routing key and the routing pattern specified in the binding. The routing key is treated as zero or more more words, delimited by ‘.’ and supports special wildcard characters. “*” matches a single word and ‘#’ matches zero or more words.

(Click on image)

A broker is required to provide an instance of this exchange named “amq.topic“.

Fanout Exchange
Queues are bound to this exchange with no arguments. Hence any message sent to this exchange will be forwarded to all queues bound to this exchange.

(Click on image)

• One use case, is to use exchange chaining in a tree like hierarchy that can be used to push messages to a large number of subscribers.
• Another use case is where a direct exchange or a topic exchange can do the initial filtering which then forwards the message to a fannout exchange which will push the messages to all it’s queues.

A broker is required to provide an instance of this exchange named “amq.fanout“.

Headers Exchange
Queues are bound to this exchange with a table of arguments containing headers and values (optional). A special argument named “x-match” determines the matching algorithm, where “all” implies an AND (all pairs must match) and “any” implies OR (at least one pair must match).

(Click on image)

A broker is required to provide an instance of this exchange named “amq.match“.

How AMQP Supports Common Messaging Use Cases

The most common messaging use cases are point-to-point (or store and forward) and publisher/subscriber models. These models can be easily built on top of AMQP.

Point-to-Point
routing_key == queue_name

Pub/Sub
routing_key == topic_heirarchy_value

Next Part : Part5 - Lets look at some code - Python examples

Prev Part : Part3 - Flexible Routing Model

Background
Most pre-AMQP models had several issues with their routing models.

• Opaque routing models that were not explicitly defined.
• Since the semantics are not visible or explicit manipulating the routing model through the protocol was difficult.
• Rigid monolithic routing engines that had limited or no extensibility or compose-ability.

The AMQP Routing Model
One of AMQP ’s primary goals was to define a flexible, extensible and transparent routing model where the semantics are explicitly defined. This permits the definition of management commands to manipulate the routing model. The AMQP model consists of three components

• Exchange
• Queue
• Binding

AMQP defines a set of rules on how to compose these components in to processing chains. The routing model is analogues to how email works. The following diagram illustrates the routing model from a publisher and consumer’s point of view.

(Click on image)

This is analogues to a Mail Transfer Agent. Queues (or other exchanges) are bound to an exchange using a ‘Binding’. A publisher sends a message to an exchange. The exchange will accept the message and routes it to one or more queues (or another exchange) based on the bindings. An exchange completely decouples a publisher from queues and the consumers that consumes from those queues.

An exchange type defines a routing algorithm to match the bindings with a given message. Hence an exchange type represents a class of routing algorithm. An instance of an exchange type can be thought if as an instance of a routing algorithm. A broker can have multiple instances of an exchange type which are identified by there name. An exchange instance can have the following properties.

• Durable/Temporary
• Auto-Delete

Queue
This is analogues to a mail box. A queue will store the messages in memory or disk and deliver them to consumers. A queue binds itself to an exchange using a ‘Binding’ which describes the criteria for the type of messages it is interested in. Queues can have the following properties,

• Durable/Temporary
• Shared/Private (exclusive)
• Auto-Delete

Binding
This is analogues to a Routing Table. A binding defines the relationship between an exchange and a queue. In other words it defines the routing criteria. The most simple case is where the binding equals the queue name. A binding decouples a queue from an exchange. The same queue can be bound to any number of exchanges using the same criteria or different criteria. Different queues can be bound to the same exchange using the same routing criteria as well.

Routing Key
Is a special field (Header) present in the Message Delivery Properties. It can be thought of as a virtual address, analogues to a ‘To’ field in an email. An exchange may use this field to route a message. The standard exchange types defined in AMQP use the routing key in different ways to route messages.

Standard Exchange Types
AMQP defines several standard exchange types that are described in detail in the next blog entry.

Extending The Routing Model
One can define new exchange types with arbitrary routing criteria (routing algorithms). For example one can define an exchange that routes messages based on content (content based routing). Thus AMQP provides a standard way of extending the routing model without impacting interoperability.

Next Part : Part4 - Standard Exchange Types And Supporting Common Messaging Use Cases

Prev Part : 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

Advanced Message Queing Protocol is a an open standard with royalty free use. It has a strong focus on the financial services industry and provides the performance and reliability required by the said industry.

AMQP Working Group
The AMQP working group is responsible for defining and maintaining the sepcification. The website www.amqp.org provides details on licensing, FAQ, JIRA and a list contributors and a download page.

Version Numbering
The AMQP Version Numbering scheme consists of a major and minor revision number. Ex: 0-10.
Major versions > 0 will provide backward compatibility between minor versions. The current version of the protocol is 0-9. The AMQP WG is expected to release the 0-10 version shortly. Currently the specification is in a rapid growth stage.

Interoperability
AMQP provides complete interoperability via

• A network wire-level protocol
• A defined set of messaging capabilities a.k.a AMQP model

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 implementation.

Reliability
The 0-10 (in-progress) version has provided functionality to ensure Guaranteed Delivery to satisfy the level of reliability required by the financial services industry. I will cover this topic in detail in a future blog post as part of the AMQP in 10 mins series.

Full Transaction Support
The 0-10 spec also provides protocol level functionality for distributed transactions. This topic will also be covered in detail in a future blog post.

Security
Security is the main focus for 0-11 version of the protocol. Currently there is only rudimentary support provided via TLS. Planned features include but not limited to partial encryption and payload signing.

Known Implementations
AMQP is platform agnostic and language neutral. Currently we have implementations from a wide variety of languages from procedural to object oriented to functional.

The Apache Qpid project has broker implementations in java and c++ and client implementations in java, c++, python, ruby and .NET.

RabbitMQ provides a broker implementation in Erlang and a client implementation in java

Open AMQ provides broker and client implementations in C.

What about JMS?
JMS can be implemented on top of AMQP. The AMQP WG is also working on standardising the AMQP-JMS mapping and is scoped for 0-11 version of the protocol. This will enable two different JMS over AMQP implementations to behave exactly the same way.
The Apache Qpid project provides an implementation of JMS over AMQP.

Next Part : Part2 - Achieving Interoperability And Avoiding Vendor Lock-in

Prev Part : Part0

From time to time people ask me what is AMQP? and how it is different from JMS? or why do we need another standard ..etc On the other hand the AMQP spec groups is finalizing it’s work on the 0-10 version.

So I decided to write a series of blog posts titled “AMQP in 10 mins”, where each part can be read and understood in 10 mins. I hope to write a part every working day, or more depending on my mood. Comments and criticisms are equally encouraged.

Next Part, Part1 - Introduction.