Message Queuing

Summary of indirect communication styles

The model of message queue is simple The model of message queue is simple. It offers communication through queues. Producer send messages to queue and consumer receive messages. Three styles of receive are • Blocking receive, block until message is available; • Non-blocking receive (polling), check status of queue and return if available, or not available indication; • Notify, issue an notification when message is available.

The message queue paradigm

Number of processes can send messages, Number of receivers can remove messages. Queuing policy is FIFO, Most implementations support priority, Consumer can select messages from queue based on properties of message. Message consists: destination (unique ID designating the destination), Metadata of message, fields such priority and delivery mode, Body of message, is opaque and untouched by queue system.

Content is serialized using standard approaches described (marshalled data types, object serialization or XML) Message sizes are configurable, very large (100 Mbytes Given the fact that message bodies are opaque), Message selection is expressed through predicates defined over the metadata. Oracle AQ (Message Queuing with Oracle Database) introduces an interesting twist on this basic idea to achieve better integration with databases; In Oracle AQ, messages are rows in database table, and queues are database tables can be queried using query language.

One crucial property of message queue is messages are persistent, queues store the messages indefinitely (until they are consumed) and commit messages to disk to reliable delivery. Definition of reliable communication, any message is eventually received (validity) and the message received is correct, and no messages are delivered twice (integrity). Queue systems guarantee messages delivered and once, but cannot say about time of delivery.

Message systems can support additional functionality: Most commercially systems support for sending or receiving of message to be contained within transaction. Goal is that all steps in transaction are completed, or has no effect at all. Number of systems support message transformation, arbitrary transformation can performed on arriving message. Most application of this concept is to transform messages between formats to deal with heterogeneity in underlying data representations. …

… This can as transforming from one byte order to another or more complex, transformation from external data representation to another (SOAP to IIOP). Some systems allow programmers to develop their own transformation. Message transformation is important in heterogeneity and achieving Enterprise Application Integration. The message broker is used responsible for transformation. Some queue implementations provide support for security. WebSphere MQ supports for confidential transmission using Secure Sockets Layer (SSL) together with authentication and access control.

Final word: is helpful to compare style of programming with other communication paradigms. Message queues are similar in many ways to the message-passing systems. Difference: message-passing systems have implicit queues associated with senders and receivers(MPI), message queuing systems have explicit queues that are third-party entities, separate from the sender and the receiver. Key difference: message queues an indirect communication with the crucial properties of space and time uncoupling.

Implementation issues: Key implementation issue: is choice centralized and distributed. Some implementations are centralized, with one or more message queues managed by a queue manager located at a node. Advantage is simplicity, but such managers can become heavyweight and become bottleneck. More distributed implementations have been proposed. To illustrate distributed architectures, consider approach adopted in WebSphere MQ as representative of state-of-the-art.

Case study: WebSphere MQ WebSphere MQ (WMQ) is middleware developed by IBM based on message queues, offering indirection between senders and receivers of messages. Queues in WebSphere MQ are managed by queue managers which host and manage queues and allow applications to access queues through Message Queue Interface (MQI). MQI is interface allowing applications do operations such connecting/disconnecting to queue (MQCONN and MQDISC) or sending/receiving messages (MQPUT and MQGET). Multiple queue managers can reside on a physical server.

Case study: WebSphere MQ Client applications accessing queue manager: may reside on same physical server, or on different machines. Must communicate with the queue through client channel. Client channels adopt concept of proxy, MQI commands are issued on proxy and sent to queue manager for execution using RPC. An example is shown in next Slide. A client application is sending messages to remote queue manager are then consuming the incoming messages.

A simple networked topology in WebSphere MQ

MQ introduces concept of message channel as unidirectional connection between two queue managers, to forward messages from one queue to another. Note terminology here: message channel is connection between two queue managers, client channel is connection between client and queue manager. A message channel is managed by message channel agent(MCA). Two agents are responsible for channel, including an initial negotiation to agree on properties of channel(including security). Routing tables are in queue manager, and together with channels allows arbitrary topologies to be created.

The hub-and-spoke approach: One queue manager is designated as hub and hosts range of services. Clients not connect to hub but connect through queue managers designated as spokes. Spokes relay messages to message queue of hub for processing by various services. Spokes are placed around network to support clients. Hub is placed in network, on node with sufficient resources to deal with volume of traffic. Most applications and services are located on the hub, it is possible to have some more local services on spokes.

Bus, point-to-point, Hub-and-Spoke

Case study: The Java Messaging Service (JMS) Java Messaging Service(JMS) is specification of standardized way for distributed Java programs to communicate indirectly. Specification unifies the publish-subscribe and message queue paradigms by supporting topics and queues as alternative destinations of messages. Wide variety of implementations of the common specification are available, including Joram, Sun’s Open MQ, Apache ActiveMQ and OpenJMS. Platforms, including WebSphere MQ, provide a JMS interface on their underlying infrastructure.

JMS distinguishes following key roles: JMS client: Java program that produces or consumes messages, JMS producer creates messages and JMS consumer receives. JMS provider: any of multiple systems that implement the JMS specification. JMS message: an object that is used to communicate information between JMS clients. JMS destination: object supporting indirect communication in JMS. It is JMS topic or JMS queue.