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:
- None. No protection.
- Authentication. Proper authentication is done to guarantee that the
sender's identity is identified to the receiver.
- Authentication with integrity. Apart from the guaranteed authentication,
the message is guaranteed for its integrity.
- Authentication with privacy. Apart from authentication and integrity,
the message is further guaranteed for its confidentiality.
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 identification
- Message type
- Message priority
- Message data type
- Sender
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:
- Message type. One of the following:
- Data. Default
- Notice (acknowledgment)
- Message data type
- Message's reply-to queue if acknowledgment is requested
The following is a list of attributes that the send operation returns:
- Message identification (generated by the API on the client side)
- Message sent time stamp (generate by the queue manager. For
multicasting send, this is the last message's sent time stamp)
[
High-level Design TOC |
Messaging
]