SAS/CONNECT User's Guide

The Indirect-Messaging (Queuing) Concept

In some instances, you do not want the programs that make up your application to run at the same time or to be synchronized so that one side sends a message and waits for a reply before it can send another message. These restrictions disappear with indirect-messaging (queuing).

SAS message queuing enables programs to communicate indirectly by placing messages on queues in storage. Therefore, the pieces of your application can run independently of each other, can run at different speeds and times, and can run without a direct connection between them.

SAS message queues provide a basic and logical means of communication. Programs communicate indirectly by delivering messages to queues and by fetching from or browsing messages in queues. The programs are commonly referred to as store-and-forward applications. The message is stored on a queue by a program and forwarded to one or more programs at a later time. The message queues are administered by a collection manager and a queue manager.

The collection manager is responsible for managing "collections" of queues and starting the queue manager that processes the individual messages for each queue. A "collection" allows you to group queues together so they are managed by the same collection manager. Each queue must be uniquely associated with a collection, and your application may contain multiple collections.

The queue manager is a server process that is responsible for

allocating the queues.
maintaining access information for each of the queues.
administering the messages that belong to each queue.

For more information on the collection manager and queue manager, see The DOMAIN Server.

Queues can be predefined or dynamically created during an open operation. Predefined queues are permanent queues and will remain available until they are explicitly deleted by an administrator using PROC ADMIN. Permanent queues may also be defined to maintain message persistency. That is, a queue's messages will be stored so that they are available even if the queue manager re-starts. Dynamic queues can be opened as either permanent or temporary. A temporary queue is deleted automatically when the queue is closed.

Basic Structure of Indirect Messaging illustrates the basic structure of the SAS indirect messaging communication. In this figure,

Program1 receives messages from Queue1 and writes messages to Queue2 in Collection1 and Queue1 in Collection2.
Program2 receives messages from Queue2 and writes messages to Queue1 in Collection1.
Queue1 in Collection2 is used by other programs in the application.

Note: Collection1 and Collection2 each have a queue called Queue1; however, these are not the same queue. Each Queue1 represents a queue that is unique within its collection. Collection names must be unique within your SAS session. [cautionend]

The ellipses (...) in the figure indicate the ability to have multiple programs communicating by using multiple queues. Also, this figure shows how the programs and the DOMAIN server can each be executing on a different platform. This is only one possibility; they can also execute each on a different platform, all on the same platform, or any combination in between.

It should also be noted that multiple programs can read or write from the same queue. You do not need a separate queue for each program.

Basic Structure of Indirect Messaging

[IMAGE]

Programs can be developed to communicate in either of two modes: one-way (datagram) or two-way (reply). In a datagram mode of operation, Program1 puts a message on a queue but does not expect a reply response. This is illustrated in the figure above by Program1 and Queue1 in Collection2.

In a reply mode, Program1 puts a message on a queue and expects a reply message to be sent to a designated reply-to-queue by Program2, after Program2 receives the original message. This is illustrated in the indirect-messaging figure using Collection1 by

Program1 sending an initial message to Queue2.
Program2 fetching this message from Queue2.
Program2 sending a reply back to Queue1.
Program1 fetching the reply from Queue1.

It is important to note that Program1 and Program2 are communicating without a direct connection between them. Therefore, they are not required to run at the same time or at the same speed. The target program could be busy when a message is put in its queue. In fact, the target program may not run for hours or days after messages for it have been put on its queue. You have complete freedom to schedule the pieces of your application based on your business requirements.

The communication between programs that use the SAS message-queuing facility can be one-to-one, one-to-many, many-to-one, or any combination of these to provide you with complete flexibility in the structure of your application. These structural combinations can be used with the datagram and reply message-flow modes, as previously discussed.

In a one-to-one relationship, a client sends messages to a queue, and the receiving program retrieves the messages in a time frame that is dictated by your business needs.
In a one-to-many relationship, a single client could send messages to a queue that is serviced by the same program that runs on multiple platforms to provide load balancing. Another scenario would be for a single client to send messages to a queue that is serviced by multiple subtasks of a program that can run concurrently to provide parallel processing.
In a many-to-one relationship, you could have multiple clients that send messages to a queue that is being serviced by a single server. The clients could run independently of the server's speed and would never need a direct connection between any of the clients and the server.

With all of these relationships, the receiving program can optionally generate replies that are based on the messages that it retrieves.

A queue can be defined as permanent or temporary. Permanent queues remain until they are explicity deleted, while temporary queues are implicitly deleted when closed. Permanent queues may either contain persistent or non-persistent messages. Persistent messages are stored on disk, and therefore guaranteed to persist through queue open and close boundaries, as well as a queue server process shutdown (DOMAIN Server stop and re-start).

A message is deleted from a temporary queue after it is fetched by an application, after the queue is closed, or upon a queue server process shutdown. A message sent to a permanent, persistent queue is stored on disk for retrieval by any number of applications and remains intact in the event of a queue server re-start.

Messages in a permanent, persistent queue are deleted only when fetched from the queue. This guarantees that a message in a permanent queue will remain there for any number of applications to browse, will persist through queue open/close boundaries, and will be removed from the queue only when it is fetched from the queue.

Chapter Contents
Previous
Next
Top of Page