High Level Design - Infrastructure -- Features

August 21, 1996

We support the following messaging features. We describe them one by one, with the definition first. When going through each of the features, please keep the model in mind.

Messaging Mode

We support asynchronous and synchronous messaging, with different wait options. Depending on the messaging model (message queuing verse message passing), the combination of the two has different meaning.

In synchronous messaging, the execution of the sender is blocked until the message has been retrieved by a recipient. This only applies to the messsage passing model.

For retrieving messages, both the message passing model and the message queuing model works similarly. On the receive API, there is a wait option which a caller may specify whether to wait for a message that meets the selection criteria to become available.

The following table describes the meaning of possible combinations for message sending:

Message Passing Model

Asynchronous
Send a message and have control return immediately to the application. The message delivery status is completely unknown when returning from the send operation. However, the sender can find out message delivery status through receipt of ACK messages requested via various notice options.

Synchronous, blocking
Send a message and have control return to the application after the message has been retrieved from the recipient.

Messaging Queuing Model

Asynchronous, No wait
Send a message and have control return immediately to the application. The message delivery status is completely unknown when returning from the send operation. However, the sender can find out message delivery status through receipt of ACK messages requested via various notice options.

Asynchronous, Wait for enqueue
Send a message and have control return to the application after the messaging system takes control of the message. At this point, the message has been enqueued, but the "dequeue" delivery status is unknown. However, the sender can find out message delivery status through receipt of ACK messages requested via various notice options.

Asynchronous, Wait for dequeue
Send a message and have control return to the application after the message has been dequeued from the messaging system.

Data marshalling

We support typed messages. A message can have arbitrarily complex data structure, not just a stream of bytes. We use DCE's IDL encoding service to achieve the data marshalling and unmarshalling.

Specifically, the user defines a data structure for a message in the interface definition file, with a unique identification called data type identification. The user also supplies a function name (with a well known function prototype) as the conversion routine for this data type. The code for this conversion function is generated by the IDL compiler.

Before sending or receiving a message, the user calls a supplied API to register a conversion function with a specific data type identification into the messaging runtime. The user can register more than one type. This is especially important for a recipient who wants to receive multiple types of messages from the same queue.

Once the registration is done, the runtime knows how to encode a typed message for sending. The runtime also knows how to decode an incoming message with encoded data.

Group Communication

A group send operation sends a message to multiple destinations. These destinations can exist on different queue managers, running on different hosts. Some products call this feature "broadcasting".

We support this feature by employing DCE NSI group naming approach to configure multiple destinations under one group name.

Quality of services

Messaging applications can specify aspects of the quality of service that will be employed when making certain operations. The term quality of service is used to characterize the reliability and timeless of message delivery.

End-to-end Protection Level

We support end-to-end protection. A sender can specify an end-to-end protection level he wants for a message. The possible levels are: A receiver, upon retrieving a message, also specifies a protection level. If the level specified by the receiver is lower than the one specified by the sender, the receive API will automatically negotiate the right level and use it to retrieve the message. If the protection level specified by the receiver is higher than the one specified by the sender, an error will be returned.

Priority

The sender can specify a priority numerical value which is interpreted as the message urgency. The lower the value is, the more important the message is.

Acknowledgment

We support message acknowledgments. A messaging application can request an acknowledgment for a message that it sends out. The sending application should specify a queue (reply-to queue) where the acknowledgment can be sent back to. The application can later go to this reply-to queue to receive acknowledgments.

The following is the type of acknowledgments that a sender can request:

Null
No acknowledgment. Default.

On Message Expiration
An acknowledgment is sent when the message expires.

On Message Enqueued
An acknowledgment is sent when the message is enqueued.

On Message Retrieved
acknowledgment is sent when the message is actually received by a recipient.

On Error
An acknowledgment is sent when an error or an exception happens during any operation on this message before it is retrieved.

Persistent and volatile messages

For a persistent message, the message should be saved to the persistent storage for the queue when the message is enqueued. This way, if the queue manager host crashes, the message can be restored.

Note, we don't guarantee any atomic file operation, which means that file saving may fail in the case of disk crash or machine panic.

For a volatile message, a message is only required to be kept in the queue manager's virtual memory. If the queue manager crashes, this message is lost.

Expiration

A message can have an expiration time. This specifies the amount of time that a message can remain outstanding in the queuing system.

When a message expires (i.e., its expiration time arrives), the queue manager discards it from the queue. For a synchronous sending operation, it also causes the operation to abort. If an "On Message Expiration" acknowledgment is requested for the message, the queue manager is responsible to send an expiration acknowledgment back to the sender.

There is a default expiration value for each message. Unless otherwise set, default expiration is 24 hours.

This feature is also called "time-to-live".

Time to receive messages

A message can have a "time to receive (TTR)" time specified. This time instructs the queue manager to enqueue the message to the proper queue, but only to make it available for retrieving when this time has arrived.

Before this time arrives, the message should be unavailable to any potential recipients. Through an administration interface, all TTR messages on a queue can be viewed.

Selection criteria for receiving

Apart from always receiving from the top of the queue, we support message receiving based on certain selection criteria. A mask can be specified to indicate which criteria are in effect.

Message Sender Security Identity

We make it possible for a recipients to make authorization decision by having the queue manager to save the sender's principal and group information and return it along with other message attributes to the recipient.

Other Message Attributes

Before a message can be sent, the sender must specify certain message attributes, in addition to the features that are described above.

Below is a list of attributes to be set before the send operation:

The following is a list of attributes that the send operation returns:


[ High-level Design TOC | Messaging ]