Interface Repository

Interface CtsComponents::MessageService

The message service provides queues for message consumers, and allows a message producers to send messages to specified queues (point-to-point messaging), or to publish messages with specified topics that may be of interest to registered consumers (publish/subscribe messaging).

Messages that are sent or published to a queue are stored in memory (transient messages) or in a database (persistent messages) until they can be delivered to the queue's consumer, which is either a client or a component. The message service provides a pull-style mechanism for client notification, and a push-style mechanism for component notification.

Once configuration is complete, the message service can be accessed by CORBA 2.0+ clients with IIOP 1.0 or IIOP 1.1 using this CORBA IDL interface.

Key Features

Operation Index

Operations

High Availability

The message service uses server clustering to provide high availability. The failure of a single server in a cluster should not make messaging services unavailable. If a CORBA COMM_FAILURE system exception occurs while a client is accessing a MessageQueue, a replacement message queue object can be obtained by calling getMessageQueue again. In that case, if the queue's previous options did not include REQUIRES_ACKNOWLEDGE, or if the queue's messages were not persistent, it is possible that some messages may have been irretrievably lost.

For maximum performance of client notification in high-throughput environments, it is better to design the client to recover from message loss than it is to use persistent messages with acknowledgement. For example, consider a client application which displays the "most recent price" for a selection of 50-100 products out of several thousand possible products, in an environment with frequent price changes. Assume that messages are used to notify clients of price changes. Upon receiving a CORBA COMM_FAILURE system exception, and assuming that some servers in the cluster are still available, the client could simply request the most recent price for each product, and then resume listening for price change messages after calling getMessageQueue again.

Load Balancing

The message service uses server clustering to provide automatic load balancing.

Message Security

The message service provides role-based security for queues and topics. There are three categories of access to a queue or topic.

Permissions for all three types of access must be assigned separately.

Reliable Delivery

The message service provides the following mechanisms for reliable message delivery:

Scalable Notification

The message service is optimized for high volume notification, not only when using a database for storage of persistent messages, but more particularly for non-persistent messages, using either point-to-point (queue) or publish/subscribe (topic) notification.

Transaction Management

The following operations can optionally be transactional. A transactional operation runs in the caller's transaction, or in a new transaction if the caller is not enlisted in a transaction.


Generated by Sybase IDL Compiler 6.0