requirements for business quality messaging

["Rik Drummond" <drummond@onramp.net>]

these were developed by ibm and microsoft and others. they are implemented
in the mqseries and the messaging queue products from ibm and microsoft
respectively.  we should compare them to our list to ensure we have not
forgotten anything.... best regards, rik

 functional.htm

Title: About BQM

	Mission Statement Fact Sheet White Papers Specifications Functional Publish & Subscribe Commerical Internet Service

Specifications: Functional Overview The Business Quality Messaging (BQM) Special Interest Group (SIG) is a group of software vendors, hardware vendors, industry analysts and end user companies that seek to accelerate the adoption of 'business-quality' messaging technologies within legacy, customized, and purchased application software. Based on the initial meetings of the BQM SIG, the SIG has agreed that: Messaging products must be able to provide a wide range of 'business-quality' services (e.g., guaranteed message delivery, failure notification and message journaling) in order to be useful in business-critical environments Not all messaging products are able to meet the requirements of business-quality messaging Adoption of business-quality messaging will be slowed without a concise definition of the requirements that individual messaging products must meet in order to be considered by the BQM SIG as capable of providing business-quality messaging services The members of the BQM SIG are unlikely to agree in the short term on a 'protocol-level definition' of business-quality messaging compliance There is value to messaging product developers and end-user companies if one of the initial deliverables of the BQM SIG is a functional-level definition of business-quality messaging requirements Therefore, the BQM SIG has created this 'functional specification' document that outlines in a conceptual way (as opposed to 'wire-level' protocols) the minimum set of attributes and behaviors that messaging products must support in order to be considered by the BQM SIG as 'BQM Compliant.' Ownership and Intellectual Property This document is developed and maintained by the BQM SIG. However, the BQM SIG claims no intellectual property rights over the content of this document. The BQM SIG actively encourages all SIG members to contribute to this document and make free use of its contents. Definitions BQM Providers - products from software vendors that that provide (at least) the attributes and behaviors listed in the Functional Specification section below. BQM Enabled Applications - applications that are designed to: Use BQM Providers for intra-application communication (and/or) Expose inter-application interfaces that are compatible with BQM Providers. Functional Specification General BQM Providers must be based on asynchronous, connectionless messaging technology. BQM Providers must enable communication between senders and receivers via 'messages'. Messages 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). BQM Providers must support any message content that can be represented as a series of 8-bit bytes. 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 BQM Providers must support both of the following message delivery modes: Persistent (messages survive machine failures) Non-persistent (messages do not survive machine failures) 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 sender's message (i.e. an acknowledgement of success) The sender's 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 sender's message was not received within the period of time defined by the sender. Use of acknowledgements must be optional on a message by message basis. BQM Providers should perform no actions that prevent their messages from being converted into the message formats required by other BQM Providers. Queues 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. . 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. A message queue must be uniquely identifiable (from all other queues regardless of physical location) by a name, label, or globally unique identifier. 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. 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. BQM Providers must allow a queue to be accessed by multiple applications simultaneously and must allow an application to access multiple queues simultaneously. 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. 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). 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). 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 It is the responsibility of the sending application to select the appropriate action for undeliverable messages. 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 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.' 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 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. BQM Providers must be able to restrict read, write, and administration access to authorized users on a queue-by-queue basis. BQM Providers must enable the security identity of the sender to be passed to the receiver as a property of a message. 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 QM 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