2. JMS AMQP
JMS is a de-facto API standard for store-and-
forward and publish/subscribe messaging in Java.
JMS does not specify the implementation or the
wire-level protocol. JMS is not technology agnostic
and only legitimately supports Java platforms under
the terms of its licensing (there will be a product
which provides a JMS interface, but a JMS-like
interface cannot legally be provided for non-Java
platforms).
AMQP provides a superset of the semantics
required to implement JMS, but also enables APIs
for C, C++, Python, C# or any other language on
Linux, Solaris, Windows, Z/OS, etc.
JMS define a standard for interoperability within the
Java Platform However not outside of Java
platform.
AMQP define a standard across platform, AMQP is
around a binary wire protocol which was designed
for interoperability between different vendors and
platforms. As long as AMQP complaint, changes at
the broker level are not needed.
3. JMS AMQP
The Java Message Service (JMS) API is a Java
Message Oriented Middleware (MOM) API for
sending messages between two or more clients.
JMS is a part of the Java Platform, Enterprise
Edition, and is defined by a specification developed
under the Java Community Process as JSR It is a
messaging standard that allows application
components based on the Java Enterprise Edition
(Java EE) to create, send, receive, and read
messages. It allows the communication between
different components of a distributed application to
be loosely coupled, reliable, synchronous and
asynchronous (From WIKI)
The Advanced Message Queuing Protocol (AMQP)
is an open standard application layer protocol for
message-oriented middleware. The defining
features of AMQP are message orientation,
queuing, routing (including point-to-point and
publish-and-subscribe), reliability and security
And the most important thing unlike JMS, which
merely defines an API, AMQP is a wire-level
protocol. A wire-level protocol is a description of
the format of the data that is sent across the
network as a stream of octets. Consequently any
tool that can create and interpret messages that
conform to this data format can interoperate with
any other compliant tool irrespective of
implementation language (From WIKI).
4. MESSAGE ROUTING
JMS AMQP
JMS uses simple message routing scheme where
both the message producer and consumer
exchange message by connecting same named
queue or topic.
Even though both the message producer and
consumer are connected to same queue the
message consumer only received message if the
message selector evaluate to true
Example state =IL
msg=receiver(1000,"state ='IL' ");
AMQP message producer sending message to
exchange along with routing key, Exchange are
bound to queue in AMQP through called binding.
A binding is a directive including what message
should be routed from an exchange to a queue.
Message consumer attached to a queue and
receive message from the queue that is bound to
an exchange.
5. MESSAGE STRUCTURE DIFFERENCE
JMS AMQP
JMS message divided into three different sections
A header section that contains immutable JMS
header properties (e.g.. JMSMessgaeId,
JMSTimestamp etc.)
A properties section that contain mutable
applications -defined name-value-pair properties
(e.g. state =IL)
A message body that contain one of the five JMS
defined message types(Object,Map<Tet<Bytes and
Stream)
AMQP also divide into same three sections
AMQP the header section of the message contains
immutable application-define properties, where the
properties section of the message contains
immutable routing and metadata properties
AMQP there is only one message body type - a
binary (bytes) messages in JMS we have five
different type messages type
6. MESSAGING MODEL
JMS AMQP
JMS support Point to Point(queue) and Publish
Subscriber(topics)
Point to point : When you end message to a queue
it will be received by only one message consumer.
Publish Subscriber: When you publish a message to
a topic it will be received by all message consumers
that subscribe to that topic
AMQP offer five different messaging models called
exchange type.
The two mandatory exchange types that must be
implemented by AMQP middleware vendors are
the Direct Exchange and Fan-out Exchange.
Optionally, a middleware vendor may choose to
implement the Topic Exchange, Headers Exchange
and System Exchange.
7. JMS AMQP
Direct Exchange closely matches the point to point
JMS models ,an exchange that is bound to the
queue required a direct match between routing key
and the binding in order to be delivered to
message to the consumer,In Direct Exchange you
can bind multiple direct queues to the exchange (
possible more then one consumer to receive the
message )
The Fan-out Exchange ,Topic Exchange the Headers
Exchange in AMQP are all essentially the same a
JMS Publish and Subscribe model, queue bind to
the exchange without a binding argument .When
message are sent to the exchange , they are
unconditionally routed to any queue bound to that
exchange(Same like message selector in JMS API).
8. JMS AMQP
Default Exchange
The default exchange is a direct exchange with no
name (empty string) pre-declared by the broker. It
has one special property that makes it very useful
for simple applications: every queue that is created
is automatically bound to it with a routing key
which is the same as the queue name.
9. JMS AMQP
Direct Exchange
A direct exchange delivers messages to queues
based on the message routing key. A direct
exchange is ideal for the unicast routing of
messages (although they can be used for multicast
routing as well). Here is how it works:
A queue binds to the exchange with a routing key K
When a new message with routing key R arrives at
the direct exchange, the exchange routes it to the
queue if K = R
Direct exchanges are often used to distribute tasks
between multiple workers (instances of the same
application) in a round robin manner. When doing
so, it is important to understand that, in AMQP 0-9-
1, messages are load balanced between consumers
and not between queues.
10. JMS AMQP
Fan-out Exchange
A fan-out exchange routes messages to all of the
queues that are bound to it and the routing key is
ignored. If N queues are bound to a fan-out
exchange, when a new message is published to that
exchange a copy of the message is delivered to all
N queues. Fan-out exchanges are ideal for the
broadcast routing of messages.
Because a fan-out exchange delivers a copy of a
message to every queue bound to it, its use cases
are quite similar:
Massively multi-player online (MMO) games can
use it for leaderboard updates or other global
events
11. JMS AMQP
Topic Exchange
Topic exchanges route messages to one or many
queues based on matching between a message
routing key and the pattern that was used to bind a
queue to an exchange. The topic exchange type is
often used to implement various publish/subscribe
pattern variations. Topic exchanges are commonly
used for the multicast routing of messages.
Topic exchanges have a very broad set of use cases.
Whenever a problem involves multiple
consumers/applications that selectively choose
which type of messages they want to receive, the
use of topic exchanges should be considered.
12. JMS AMQP
Headers Exchange
A headers exchange is designed for routing on
multiple attributes that are more easily expressed
as message headers than a routing key. Headers
exchanges ignore the routing key attribute. Instead,
the attributes used for routing are taken from the
headers attribute. A message is considered
matching if the value of the header equals the value
specified upon binding.
Headers exchanges can be looked upon as "direct
exchanges on steroids". Because they route based
on header values, they can be used as direct
exchanges where the routing key does not have to
be a string; it could be an integer or a hash
(dictionary) for example.