more about the wonderful world of mq

In this entry, I'm going to write a tiny bit about the high level architecture of the system and talk about the client runtime to broker communication.

So, what does someone really want to know about the high level architecture of the Messge Queue product ? I have no idea, but I'll start by laying out the basics of how the system is set up and over time (and more blogs) we'll add more data.

Today, we'll just cover the basic high level pieces - the server, the client, etc.

Message Queue is composed of three main components - the broker, the client runtime and administration.

Broker: The broker is the server component of the system. It runs as a standalone component (outside of the client applications) either on its own or as part of a cluster, and handles taking messages from one application and doing the following steps:

  • routing it - deciding who is interested in the message
  • storing it - putting the message into the persistent store
  • delivering the message - writing the message out to clients who are interested in the message
  • acknowledging it - tracking who has seen a message to make sure that anyone who received the message has completed viewing it before the message is deleted
  • cleaning up throwing away the message way once its complete

Client Runtime: Implements the JMS Specification. This is the piece that handles converting calls made by the client using JMS into protocol which is used to communicate with the server.

Administration: Provides the clients used to monitor and administer the broker, administered objects and the persistence store. Clients may be commandline tools, an admin gui or an admin (JMX-based) api.

Communication between the Broker and the client:

All communication between the client runtime and the broker happens through Packets. This is a ReadOnlyPacket and ReadWritePacket on the client and a Packet on the broker. The client runtime and the broker side use different implementations because the newer packet class is set up to use ByteBuffers (from the java.nio package) and we didn't want to make the client dependent on a new JDK if we had another option.

The format of the Packets passed between the client and runtime (whether ReadOnlyPacket, ReadWritePacket or Packet) is outline by the Packet specification. Every packet has the following areas - a header (which indicates things like the size of the packet and information such as flags which are constants), a variable length set of properties, and a body. The body is passed - untouched - by the broker.

The contents of the packet sent between the client and the broker is defined by the Protocol Specification. A standard interaction (in this case the client sends two Non-Persistent Text Messages and the exits)

  1. Client Runtime -> Broker HELLO - initialize Connection
  2. Broker -> Client Runtime HELLO_REPLY - return ID for the connection
  3. Broker -> Client Runtime AUTHENTICATE_REQUEST - requestion authentication
  4. Client Runtime -> Broker AUTHENTICATE - send password information
  5. Broker -> Client Runtime AUTHENTICATE_REPLY - reply with results of authentication
  6. Client Runtime -> Broker CREATE_DESTINATION - create a destination
  7. Broker -> Client Runtime CREATE_DESTINATION_REPLY -reply if the creation was successful
  8. Client Runtime -> Broker ADD_PRODUCER - add a producer
  9. Broker -> Client Runtime ADD_PRODUCER_REPLY - reply if the addition of a new producer was sucessful
  10. Client Runtime -> Broker TEXT_MESSAGE - send a message
  11. Client Runtime -> Broker TEXT_MESSAGE - send a message
  12. Client Runtime -> Broker GOODBYE - close the connection

Next blog: the basics of clustering


Just curious. What software did you use to create the cool diagram in the above post? Thanks.

Posted by Kishor Gurtu on January 16, 2007 at 09:48 PM GMT #

The software I used to create the first draft of the graphic shown was Visio -- a very excellent graphics package for technical illustrations. However, the picture you are looking at was further smoothed by the Graphics/Art dept, and I don't know what they used. I can ask if you like.

Posted by joanna bujes on January 17, 2007 at 10:09 AM GMT #


Posted by Kishor Gurtu on January 18, 2007 at 01:14 AM GMT #

Can authentication use ssl certificates rather than user/password?

Posted by Toby on January 21, 2007 at 07:26 AM GMT #

Post a Comment:
Comments are closed for this entry.

A blog for Open Message Queue, the JMS provider in GlassFish Server, Open Source Edition


Top Tags
« February 2015