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:
- API control
- including init() and exit()
- Naming support
- including functions to import and export queues into CDS
- Conversation service
- including the base send() and receive() functions
- Security control
- including setting up security information to be used
- Message attribute utilities
- including reading and setting of various message
attributes.
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:
- queue operations
- including queue creation, queue deletion, queue relocation,
showing queue attributes, etc
- message operations
- including retrieving messages, searching messages, showing
message attributes, etc.
- queue manager management
- including listing all queues on a queue manager, checking
the "future" messages, etc
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
]