Administered Objects

A JMS application is bootstrapped using the administered objects. There are two types of JMS administered objects:

The administered objects are normally published and accessed using JNDI. Alternatively, the JMS server's administered objects can be instantiated directly by using the classes in the com.sssw.jms.api package:

The JMS server implements a CORBA COS namespace, which is accessible via the JNDI/CosNaming driver. This namespace contains the connection factories, as well as all the destinations served by the JMS server. The graph below shows the JMS server's namespace:


                                     |
               +---------------------+---------------------+
               |                                           |
             queue                                       topic
               |                                           |
       +-------+-----+------+ ...                  +-------+-----+------+ ... 
       |             |      |                      |             |      |
connectionFactory  queue0 queue1 ...        connectionFactory  topic0  topic1 ...

When the server starts for the first time, the initial system namespace depicted above is created. It has a connection factory each for creating the queue and the topic connections, and four built-in destinations (queue0, queue1, topic0, and topic1) that are used by the sample programs.

When a destination is created, the namespace automatically gets the corresponding queue or topic object populated. The name space is accessible via the JNDI/COS provider. The namespace is read-only; any attempt to update the namespace directly results in a security exception.

Destination Configuration

Destinations are queues and topics residing inside a JMS server. The Novell exteNd Messaging Platform JMS server supports several destination properties that can be configured to optimize and customize the destination. Most administrators will want to set destination properties to ensure proper operation of the server at all times.

Destination Property Name
Description
destination.acl
ACL name protecting the destination
destination.maxMessageSize
Maximum size (in bytes) of the Message that can be produced to this destination. The default value for this property is Integer.MAX_VALUE.
destination.messageExpiration
The default expiration assigned to messages on this destination. This will override any expiration value set in the message header. The default value is zero, meaning that the expiration value of incoming messages will not be changed.
destination.maxConsumerNum
Maximum number of consumers that can be concurrently connected to this destination. The default value for this property is Integer.MAX_VALUE.
destination.durableAllowed
Does the destination allow durable subscribers. This property is ignored for Queues. The default value for this property is "true".
destination.sendEnabled
This property determines if producer applications are allowed to send new messages to a destination. The default value is "true" which means the destination will accept new messages. When set to false, producer applications will receive an exception when trying to send to the destination.
destination.receiveEnabled
This property determines if consumer applications are allowed to receive messages from a destination. The default value is "true" which means consumers can receive messages from the destination. When set to false, consumer applications will get an exception when trying to receive from the destination.
destination.maxUnconsumedMsgNum
Maximum number of unconsumed messages. The default value for this property is Integer.MAX_VALUE.
destination.maxUnconsumedMsgBytes
Maximum unconsumed message bytes. The default value for this property is Integer.MAX_VALUE.

Destinations can be created with the jmqutil and jmqconfig commands. The first create or deletes destination with default properties, which the latter can be used to create a set of destination based on an XML configuration file.

Typically, administrators will set at least the maxUnconsumedMsgNum or maxUnconsumedMsgBytes property. This property effectively ensures that the JMS server does not exhaust system resources when consumer application are not receiving messages as fast as producer applications are sending them.

The JMS server applies flow control when either of these properties are set, i.e. the message producers will be slowed down according the the speed at which consumers are acknowledging messages.



Copyright © 2003, 2004 Novell, Inc. All rights reserved. Copyright © 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved.