Also, command sequnces are easily mailed. I can imagine gluing together an MQ
for a SABRE-like CLI reasonably enough.
Is that all we really need to take over this market?
3270://host/screenserialnumber/cursorrange urls? CGI-bins which are actually
just ptty login servers?
[Aside from the manageable request queue thing, that is...]
Seriously: take-home question is: how can these products be expressed in terms
of HTTP/1.x messages? In terms of (proposed, experimental) NG/ILU like
commands?
Rohit Khare
Business Quality Messaging Special Interest Group
Functional Specification
1) BQM Providers must be based on asynchronous, connectionless messaging
technology.
2) BQM Providers must enable communication between senders and receivers via
messages.
Messages
3) BQM Provider messages must support both:
* Message content that is opaque (i.e., not interpreted in any way by the
BQM Provider).
* Message properties/attributes that are used by the BQM Provider and
(optionally) applications (e.g. name of the desired response queue).
4) BQM Providers must support any message content that can be represented as
a series of 8-bit bytes.
5) BQM Providers must include support for all of the following message
properties (BQM Providers may define any number of additional message
properties):
* A message identifier that is globally unique from all other messages
* An application-definable message type indicator
* A maximum lifetime indicator that specifies that maximum amount of
time that a message should be considered alive after it is sent.
Messages die when they are not received (for any reason) by an
application within their maximum lifetime. BQM Providers must not
deliver messages that have died
* The name of a response queue; actual use of this property by sending
and receiving applications is optional
* The priority of the message
* The desired message delivery mode (see below)
* The desired message acknowledgement mode (see below)
* The length of the message
* The name of an administration queue for acknowledgement messages
* The security identity (if any) associated with the sending application
6) BQM Providers must support both of the following message delivery modes:
* Persistent (messages survive machine failures)
* Non-persistent (messages do not survive machine failures)
7) BQM Providers must support all of the following message acknowledgement
modes:
* None - no acknowledgement messages are provided to the sender of the
message.
* Positive - the BQM Provider automatically sends an acknowledgement
message to the original sender confirming that either:
* An application has successfully retrieved the senders message (i.e. an
acknowledgement of success)
* The senders message was not received within the period of time defined
by the sender (i.e. an acknowledgement of failure).
* Negative - the BQM Provider automatically sends an acknowledgement
message to the original sender confirming that the senders message was
not received within the period of time defined by the sender.
8) Use of acknowledgements must be optional on a message by message basis.
9) BQM Providers should perform no actions that prevent their messages from
being converted into the message formats required by other BQM Providers.
Queues
10) BQM Providers must be able to store messages in queues until receivers
choose to retrieve messages. There should be no predefined limit to how long
messages can remain in queues before they must be retrieved.
11) BQM Providers must support both destructive and non-destructive receipt
of messages by applications. Destructive receipt will remove a message from
a queue. Non-destructive receipt will not remove the message from a queue;
the receiving application is given a copy of the message.
12) A message queue must be uniquely identifiable (from all other queues
regardless of physical location) by a name, label, or globally unique
identifier.
13) BQM Provider message queue identifiers must not require the inclusion of
physical location information as a part of the name. Moving a message queue
from one machine to another should not require the identifier of the queue
to change.
14) BQM Providers must be able to accept messages from sending applications
even if receiving applications are not reachable at the time of sending
(e.g., the network may be unavailable or the receiver may not be running).
Note that accepting messages from sending applications does not imply
receipt by receiving applications.
15) BQM Providers must allow a queue to be accessed by multiple applications
simultaneously and must allow an application to access multiple queues
simultaneously.
16) BQM Providers must support applications that send messages that are
destined for message queues physically residing on the same machine, or a
different machine, than the sending application. Applications must be able
to receive messages that originated on the same machine or a different
machine.
17) BQM Providers must support the ability to deliver messages in the order
that they were sent from a given machine (i.e. message ordering must be
preserved by sending machine, not among all sending machines).
18) BQM Providers must be able to ensure that a given message is eventually
received by an application and that the same message is not received more
than one time. If a message cannot be delivered to the destination queue
(e.g., the destination queue name is invalid) or is not received
successfully by some application (e.g., the maximum lifetime value set by
the sending application expires before the message reaches the destination
queue), the BQM Provider must be able to provide an indication to the sender
that message delivery failed (see next).
19) When a BQM Provider cannot deliver messages successfully (e.g., the
target message queue does not exist, the target message queue is full, or
the maximum time the sender allows for a message to be received has expired)
the BQM Provider must support all of the following actions:
* The message may be placed in a dead letter queue
* The message may be returned to the sending application
* A acknowledgement message indicating delivery failure may be returned
to the sending application
20) It is the responsibility of the sending application to select the
appropriate action for undeliverable messages.
21) BQM Providers must support message journaling on receiving machines
(i.e., the BQM Provider must provide the option to automatically put copies
of all successfully delivered messaged into a journal queue.) Processing of
messages within journal queues is not the responsibility of the BQM
Provider.
Transactions
22) BQM Providers must provide support for integrating message manipulation
operations (such as sending or receiving) within transactional units of
work. Use of this support by applications must be optional on a
message-by-message basis. When transactional support is used, all message
manipulation operations that cause messages to change in any way (e.g., to
be created, deleted, sent or received) must be:
* Isolated from all other users of the messaging system. Being
isolated implies that once a message is manipulated within a
transactional unit of work, only the application that began the
transaction can manipulate that message until the transaction either
commits or aborts (i.e. all messages become locked when they are
manipulated within transactions; messages are unlocked when
transactions commit or abort)
* Made durable and visible to other users of the messaging system
when the containing transaction commits. Making the operations
durable implies that subsequent failures of the messaging system will
not result in the loss of any messaging data or state information that
has been successfully committed. Making the operations visible
implies that other users of the messaging system will be able to see
the results of the operations (e.g., in the case of a send operation,
visible means that the sent message appears in the appropriate
destination queue and can be received by an application that is reading
from the queue).
* Rolled back to the last durable state in the event that the containing
transaction aborts. No operations that were made to messages or the
messaging system within transactions that aborted should ever become
visible to other users of the messaging system. For example, messages
that are created within transactions that eventually abort are
discarded and never made visible to any receiver; messages that are
received within a transaction that eventually aborts must be returned
to the queue that they came from and made visible for subsequent
re-receipt.
23) BQM Providers must support external transaction coordination. To
support external transaction coordination implies that BQM Providers must
provide a mechanism (e.g., XA support) for being controlled by an
external transaction manager that is not part of the BQM Provider product.
Security
24) BQM Providers must enable all of the following security services:
* Message privacy protection (e.g., encryption) during transit between
senders and receivers
* Message integrity protection (e.g., a mechanism that provides an
indication to receivers when message content changes (intentionally or
unintentionally) during transit between sender and receiver.
25) BQM Providers must be able to restrict read, write, and administration
access to authorized users on a queue-by-queue basis.
26) BQM Providers must enable the security identity of the sender to be
passed to the receiver as a property of a message.
27) BQM Providers are not required to provide security services directly.
BQM providers can satisfy security requirements by providing an exit or
plug-in mechanism that enables external security providers to fulfill the
required functions. BQM Providers are not required to provide external
security provider support.
Embedding
28) BQM Providers must be embeddable into new and existing applications
such that the end user of a BQM enabled application does not need to take
explicit actions regarding any of the following:
* Installation of the BQM Provider
* System definition of the BQM Provider
* Operation of the BQM Provider
----------------------------------------------------------------------------
Functional Specification 1.0 -- Sept. 25, 1997