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



The following steps must be followed to configure the message service.

  1. With a text editor, edit the file $JAGUAR/Repository/Component/CtsComponents/MessageService.props.
  2. If using a cluster, copy the modified file to the other cluster members.
  3. Add "CtsComponents/MessageService" to the "" server property, using the All Properties tab page in Jaguar Manager's Server Properties dialog.
  4. If using a cluster, synchronize the cluster.
  5. Restart the server(s).

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

When a thread pool is specified for getMessageQueue, the MessageQueue object is implemented with a specialized server IIOP handler that avoids the use of large numbers of waiting threads to handle blocking receive calls, and thereby avoids waking large numbers of threads for client notification.

Since clients also use operations of the MessageService interface, whose implementation is managed by an ordinary IIOP handler that assigns one thread per concurrent client connection, it is advisable for clients to use the IdleConnectionTimeout ORB initialization property so that a server can handle a large number of concurrent clients without allocating a large number of threads.

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 EAServer 5.0