60 JMS does not define the format of the messages that are exchanged, so JMS
systems are not or hardly interoperable.
To conclude on AMQP, here are the main features of interest, along with the principal and potentially critical downside of this protocol, and of MOM in general:
Advantages: Asynchronous delivery
Routing requestreply - publishsubscribe especially AMQP Supporting implementation on a lot of API JMS C C++,
PHP, ... Disadvantages:
The main disadvantage of message oriented middleware systems is that they require an extra component in the architecture, the message transfer agent message broker. As
with any system, adding another component can lead to reductions in performance and reliability, and can also make the system as a whole more difficult and expensive
to maintain.
11.4.2 Headers
After stating the actual advantages and drawbacks of those protocol from a general perspective, it is now interesting to compare the headers of the different options. Indeed,
in an environment where the bandwidth is limited, and the number of message exchange can be very important, the volume created headers of each message can become
significant.
All the protocol considered here are functioning on top of TCPIP, therefore it is considered that the overhead induced by the lower layer protocols are constant and do not
vary from a application protocol to the other.
Regarding HTTP, the protocol also always includes a set of headers that send metadata during transfers. FTP does not send such headers. When sending small files, the headers
can be a significant part of the amount of actual data transferred. HTTP headers contain info about things such as last modified date, character encoding, server name and version
and more. It is then left to decide whether this metadata is of use for the data exchange. If not, the additional headers inherent to HTTP may become a source of unnecessary
volume of data transmitted. Additionally, HTTP, as a stateless protocol, has to reopen a connection every time data has to be exchanged, which also represents additional volume
of data to be exchanged, compared to FTP for instance.
AMQP also include headers, to define properties such as priority. However, those headers are not very numerous and their format is quite simple boolean, int, ....
61 Moreover, it is possible to define default values for those headers so that they can be
omitted, as long as the receiver of the message and the sender have agreed on those default values at session opening.
SMTP probably is the protocol with fewest header volumes, but its inability to transmit anything but text makes this advantage insufficient compared to the other protocols.
First conclusions that can be drawn from this analysis is that comparing the classical applications directly operating over TCPIP that is HTTP, FTP and SMPT, HTTP
remains the most appropriate for the operation of web services, given its advanced capabilities for message exchange compared to SMTP and FTP message encryption,
various formats, database querying.
FTP can be a good candidate if security is not a primary concern. It is also appropriate for data exchange over TCPIP, and offers possibility to exchange data in binary format. The
main advantage of FTP would be that it is slightly faster that HTTP. However the compression and pipelining ability to ask for the next data before the previous one
ended functionalities of HTTP can palliate this difference.
AMQP could be an interesting option for web services, since it has the same capabilities than HTTP, namely its capacity to support various models SOAP, WS-Transactions, ...
over TCPIP, and brings new features that could be very interesting in an SOA, such as asynchronous messaging and reliability not covered by HTTP. As it has been shown,
being a MOM protocol, AMQP comes with the drawback that message brokers need to be included to the architecture, which could lead to additional developing and operating
costs.
11.5 Lessons Learned
It was interesting to investigate alternatives for the omnipotent protocol HTTP for the operation of web services on TCPIP networks. Being generally used by a wide majority
of the network applications and web services, HTTP’s legitimacy is rarely questioned. A short analysis showed that this choice is justified both by legacy usage of the protocol for
information exchanges over the Internet and by the fact that service architectures developed with the together with HTTP, therefore adapting to its available features, while
HTTP was evolving to best serve those architecture in return.
From a documentation perspective, the wide usage of HTTP comes with very complete documentation associated, previous studies and strength and weaknesses analyses
performed. Regarding the other protocols, FTP and SNMP have very closed field of usage, and considering them as potential alternatives of HTTP is quickly proven
complicated, given the technology gaps that exists. AMQP appears as the only serious competition, offering features comparable and sometimes more thorough than HTTP.
However, AMQP still needs to be proven has a serious competition, for structure of its architecture implies gap that need to be filled to reach the level of deployability and
interoperability of HTTP, especially regarding the need of the intermediate message broker in the architecture.
