Axis2/C AMQP Transport - Part I

Table of Contents

1. Introduction
2. Who Should Read This Article?
3. The AMQP Protocol
    3.1. Why the AMQP?
    3.2. The AMQP Model
    3.3. The AMQP Wire-level Protocol
4. Requirement for AMQP Transport in Axis2/C
5. Conclusion

1. Introduction
   
    To explain the AMQP transport in Axis2/C, it is helpful to start with the foundational concept of the AMQP protocol [1].  This article will introduce the AMQP protocol, and the second article in the series, Using Axis2/C AMQP Transport - Part II, will explore the AMQP Transport in greater detail.

    AMQP is an application layer protocol for interoperable messaging systems. As the specification states, this protocol mainly targets business messaging systems where there is likely to be an economic impact if a message is lost, delayed, or improperly processed. In other words, AMQP is all about reliable, fast, platform-agnostic and interoperable enterprise messaging.
   

2. Who Should Read This Article?
   
    This article will mainly focus on the AMQP protocol in general, but occasionally will explore the connection with Axis2/C transport-specific bits. It is recommended reading for anyone interested in knowing the core concepts of the protocol, its semantics and the wire-level protocol. At the end of this article, the argument for why an AMQP transport for Axis2/C is needed, and how it adds value to Axis2/C Web services framework.  For those readers already familiar with the AMQP protocol, you may wish to and jump directly to section 4.

3. The AMQP Protocol

     The Advanced Message Queuing Protocol (or AMQP) is an open standard application layer protocol for Business Messaging. The main objective of this particular messaging protocol is the interoperability of different industrial messaging systems. To achieve this objective, the AMQP specification clearly defines both the wire-level protocol and the semantics of the broker services. Therefore any two messaging systems adhering to the server semantics and the wire-level protocols defined in the AMQP specification can communicate with each other seamlessly.  The AMQP is best described as an open, application-layer protocol for interoperable message-oriented middleware.

3.1. Why the AMQP?

    To explain the reasons for the introduction of the AMQP, it is first necessary to briefly review the history of message-oriented middleware and enterprise messaging concepts.

    A remarkable trend can be observed in the financial services industry: each company is trying to build its own messaging middleware.  Within this industry, enterprise IT infrastructures must process a high volume of transactions nearly instantly, with very demanding requirements for guaranteed delivery and publish-subscribe. Many financial services companies have found the capabilities of currently available middleware implementations do not meet their unique needs, and have been forced to build their own middleware.  Financial institutions have collaborated to create open technical standards for these new financial industry-specific messaging technologies, including the FIX (Financial Information Exchange) protocol, FAST (FIX Adapted for Streaming), FpML (Financial products Markup Language), and SWIFT (Society for Worldwide Interbank Financial Telecommunication). AMQP is the latest addition to this list.

    According to John O' Hara, the Chairman of the AMQP Working Group, the defining features of AMQP are: message orientation, queuing, routing, reliability and security. (Many of these features are similar to those of JMS, a previous attempt that closely resembles the AMQP model but ultimately failed to support interoperability.)  It should be noted that WSO2 has been contributing to AMQP as a member of the AMQP Working Group [2] since 2008.

3.2. The AMQP Model

    The AMQP model defines the semantics of a message broker. This model consists of a set of components that accept, store and route the messages within the broker and rules for wiring these components together. There are three main types of components: exchange, message queue and binding.

    1. Exchange - An exchange receives messages from a publisher and routes them to one or more message queues based on the binding rule.
    2. Message Queue - A message queue accepts messages from one or more exchanges and keeps them until a consuming application pops them out.
    3. Binding - A binding defines the relationship between an exchange and a message queue. This may be a hard-wiring between an exchange and a queue or based on message properties or content.

    According to the AMQP specification, there are different types of exchange, but the Direct exchange, the Fanout exchange and the Topic exchange are considered most important.

    1. Direct Exchange

       

        This exchange routes messages to one or more queues based on an exact match between a routing key in the message and a binding key used to bind queues to the exchange. This is the ideal exchange to be used to support point-to-point communication model. This is the exchange which is used in Axis2/C AMQP transport to support request/response message flows.

    2. Fanout Exchange

                 

        This is particularly useful in message broadcasting. A message received by a fanout exchange will be sent to all the queues that are bound to the exchange. This exchange never makes use of a routing key defined in messages. This type of exchange is not really useful for a framework like Axis2/C simply because it does not support two-way communication using an exchange that sends a message to multiple destinations.

    3. Topic Exchange

        This is similar to a direct exchange but the messages are routed based on a pattern match between the binding key and the routing key. This is actually a slimmed-down version of a regular expression match. In messaging middleware paradigm, an exchange of this nature is said to possess a publisher-subscriber model. In a pub-sub model there will be a publisher who will keep publishing messages to a topic and one or more subscribers listening on that topic showing interest on a particular set of messages will receive them. One classic example for such applications is a market data server that will keep publishing market data to a topic and one or more stock brokers subscribed to that topic who will ultimately receive the market data.

    These are the most commonly used AMQP exchange types. Apart from these common types there are other exchanges types such as Header exchanges, System exchanges and of course custom exchange types. For more details about these additional exchange types, refer to the AMQP specification [3].

3.3. The AMQP Wire-level Protocol

    The AMQP protocol is a binary protocol. It is multi-channel, negotiated, asynchronous and efficient. The AMQP wire-level protocol is split into two layers: the functional layer and the transport layer.

    The functional layer defines a set of commands that the application can use. The transport layer handles channel multiplexing, framing, content encoding, heart-beating, data representation, and error handling.

4. Requirement for AMQP Transport in Axis2/C

    Axis2/C is known to be one of the most powerful Web services frameworks for SOA development at the moment. It has been the choice of application developers for a long time simply because its rich set of features and above all its high performance [4] [5]. The concept of event-driven messaging systems is becoming more and more popular in today's business world due to the fact that event-driven middleware has proven to be quite useful in handling most of the complex business messaging scenarios. Axis2/C used in conjunction with a simple, light-weight pub-sub eventing model would be the choice of any system architect who is looking for the perfect MOM for an SOA application. At the moment, Savan/C [6] serves better in terms of providing a pub-sub model, but at times it can be considered too heavy. This is where the AMQP transport is most useful, as it provides a simple and easy-to-use pub-sub model at the transport level.

    On the other hand, when it comes to financial applications, AMQP is slowly but gradually becoming the de-facto standard for messaging.
   
    Therefore, from a financial messaging point of view, as well as from an event-driven messaging middleware point of view, Axis2/C without support for AMQP and also for pub-sub model would not be considered a viable option. So, having an AMQP transport for Axis2/C would be considered a huge value addition.
   
    Another important aspect is that with the AMQP transport, Axis2/C can now talk to Axis2/Java through its JMS transport. This is possible, because AMQP is JMS compliant.

5. Conclusion

    This article is a prelude for the next article on the Axis2/C AMQP transport, and acts as a general introduction to the basics of the AMQP.

Author
    Danushka Menikkumbura, Technical Lead, WSO2 Inc. danushka at wso2 dot com

References

[1] - AMQP Home Page
[2] - AMQP Working Group
[3] - AMQP 0-10 Specification
[4] - Apache Axis2/C Performance: Round 1

[5] - Apache Axis2/C Performance: Round 2

[6] - Apache Savan/C