DCE Messaging Project Description

DCE Messaging Team
Open Software Foundation
June 17, 1996

Target Audience

This document is meant for people who are interested in project management. For example, the project managers from sponsors and OSF.

1. Project High Level Goals

High Level Goal

2. Prototype Development Goals

The following are the goals for the prototype.

2.1 Provide an infrastructure for a message queuing system (MQS) where messages are stored and possibly forwarded among queue managers.

2.2 Supply a set of APIs that let a user send an arbitrarily complex data structure to be to a destination.

We support both message passing and message queuing.

2.3 Support both synchronous and asynchronous messaging.

2.4 Support DCE naming

We integrate DCE naming into the DCE messaging to provide location independent feature.

We support messaging naming APIs that the application can use.

2.5 Support DCE security

We use DCE security to provide a trusted message passing chain, along with support for authorization (ACL) checking.

2.6 Support various scale platforms

Not only do we support the normal "server" platforms, including up to large scale mainframes, but we also want to support small scale platforms, the lightweight machines. These lightweight client machines usually do not run DCE application servers. Windows-based machines fall into this category.

2.7 Support load balancing

2.8 Support various communication semantics

2.9 Support messaging quality of service

The following qualities of service are provided by the system. They can be set for a message at the time it is sent out.

2.9.1 Priority

A message can have a priority. Depending on the queue characteristics, a message can be dequeued based on message priorities. In other words, a queue can be configured to ignore the priority.

2.9.2 Acknowledgments

We support message acknowledgments. A messaging application can request an acknowledgment (ACK or NACK) for a message that it sends out, and it can go back to the specified receiving queue to get the ACK message after the send.

2.9.3 Persistent and volatile messages

For a persistent message, the queue manager saves it to the per queue specific persistent storage when the message arrives at the queue manager. This way if the queue manager crashes, the message can be restored.

For a volatile message, it is be kept in the queue manager's memory, no persistent saving. If the queue manager crashes, this message is lost.

2.9.4 Message expiration (Time to live, TTL)

The sender can specify a time (relative or absolute) at which time the message should be discarded if it has not been received.

2.9.5 Timed delivery (Time to receive, TTR)

The sender can specify a time (relative or absolute) after which time the message becomes available to the recipient for retrieving. Before that time, the message is not visible in the queue to the applications that use the normal dequeue interface to retrieve from the queue.

2.10 Support multiple queues on a queue manager.

Each queue manager is able to support multiple queues.

A queue can be shared for enqueue and dequeue by a sender and a recipient, or a sender and multiple recipients, multiple senders and a recipient, or multiple senders and multiple recipients.

A queue can be created by an administrator or by an application programmatically.

2.11 Support dynamically configurable queues

A queue has certain attributes. We allow them to be set at the creation time and be modified at later time.

2.11.1 Queue ordering

Queues store messages based on messages' priorities and their arrival time. The order is first determined by the priority. Within the same priority, the order is determined by the arrival time: FIFO.

2.11.2 Queue size

A queue has a size that is set at the creation time and can be changed programmatically later. When the queue is full, an error will be returned.

2.12 Support Group Communication

We support sending a message to multiple destinations.

2.13 Use serviceability facility for logging

Queue managers should log important events using serviceability facility from DCE.

2.14 Support administration of Queue managers

We supply additional commands for dcecp so that a user or an administrator can use dcecp to operate on queues and on messages in certain queues.

Sample queue operations include queue creation, queue deletion, queue move, showing attributes of a queue.

Sample message operations include listing messages in a queue, search specific messages from a queue, show a message's attributes, redirecting a message from one queue to another.

3. Non-goals

The following are non goals for this prototype work due to the limited time and resources.

Even though they are non goals, we have made steps in our design to enable implementation of these in the future.

3.1 Replication

We don't support replication for a queue manager.

Our design does distribute messages among different queue managers, hence greatly reducing the chance of single point of failure.

3.2 Transaction capability

We don't support transaction semantics.

3.3 Any prevention against data-loss due to disk crashing or machine panic

This is beyond this prototype. The possible solution is either to save files to a log volume that can be recovered, or use disk-mirroring technology.

3.4 Message broadcast

We define message broadcasting as the queue manager actively sending a message to multiple recipients.

Note: some messaging products claim they support broadcasting, but what they really support is multiple recipients share the same queue. We do support this feature.

3.5 Message status inquiry.

We provide acknowledgment instead. Time permitting, we will add APIs which will check the acknowledgments for the caller.

3.6 Message auditing

Using DCE's audit service to audit the message receiving, routing and sending can be a future goal.

3.7 Store and Forward Among Queue Managers

We don't support automatic interactions among queue managers. However, the administrative interface does allow one to relocate a queue from one queue manager to another, and allow one to redirect a message from one queue to another.

In the future, we may add forwarding functionality to queue managers.

4. Project Deliverables

The outcome of the project consists of four major parts.

4.1 MQS Infrastructure

We develop an infrastructure for a message queuing system (MQS) where messages are stored and possibly forwarded among queue managers.

The MQS is responsible to maintain queues and messages sent to queues. Once a message enters the MQS, the sender can continue to do whatever it has to do. The message stays in the MQS until a recipient retrieves it. At the time, the message leaves the MQS.

The infrastructure, the MQS, is responsible to maintain all the messages that enter into the system. The MQS is responsible for making sure that proper authentication happens, and for checking authorization before any operation is carried out. It is responsible to provide persistent storage for keeping persistent messages. It is responsible to keep track of those TTR messages and insert the ones that become active into the proper queues. It is responsible to check for message expiration. it is also responsible to send out acknowledgments at the necessary time if requested.

Through administration interface, the MQS is also responsible to redirect a message, to move a queue, to enable and disable a queue.

4.2 A set of APIs

We provide a set of APIs that allows an application to send an arbitrarily complex typed message to be sent to a destination securely, with naming support.

We support two API hierarchies. At a higher level, a small set of APIs are provided for quick, easy application programming. At a lower level, more APIs are provided for application programmer to deal with naming issues, to set/get various attributes, etc.

In general, we provide the following categories of functions:

4.3 An Administration Interface

We supply a set of administration commands, in the dcecp terms, which users and administrators can use to operate on queues and messages.

We support the following categories of operations:

4.4 A Proof-Of-Concept Implementation of a distributed application

We will identify a distributed application to be implemented or re-implemented using the DCE messaging prototype as a proof of concept.

5. Schedules and Milestones

6. Reference Documentation

6.1 High level goal description

High level goal description

6.2 High Level Design

High Level Design

6.3 Detailed Design

Detailed Design


[ Messaging | Main OSF ]