Topic Management

As mentioned earlier, a topic has to be set up initially on the messaging server by an administrator before it can be used for any coding. Having downloaded and set up all the required software when we went though Chapter 4, we are now ready to jump into JMS development with Pub/Sub messaging.

The first step as usual, is to create a topic connection factory and the topic that we can use while developing our JMS code samples. Invoke your JMS messaging server's administrative console. Log on to your messaging server's administrative console as the administrator.

Create a topic connection factory called retailbrokerage:tcf. The figure below shows the FioranoMQ's administrative console. The Topic CFs tab shows that we have created the retailbrokerage:tcf topic connection factory on the messaging server successfully. A Topic Connection Factory object is now created and associated with the name retailbrokerage:tcf and is attached to the JNDI tree. This object can now be accessed by all the other messaging client applications through JNDI:

click to expand

Create topics called Consumer:Check, Equity:Trade, and Trade:Price. The figure below shows the FioranoMQ's administrative console. The Topics tab shows that we have created topics called Consumer:Check, Equity:Trade, and Trade:Price on the messaging server successfully:

Topic Name

Description

Consumer:check

This checks risk, compliance, and credit of the stock buyer

equity:trade

This is used to buy or sell stock

trade:price

This is used to inform accounting of the price paid to trade the stock

Topic objects are now created and associated with the names Consumer:Check, Equity:Trade, and Trade:Price and are hung off the JNDI tree. These objects can be accessed by all the other messaging client applications through JNDI:

click to expand

Create the users Athul and Gopalan, with passwords Raj. The figure below shows FioranoMQ's administrative console. The Users tab shows that we have created Athul and Gopalan as users on the messaging server successfully:

click to expand

Physical Destinations

Physical destinations are provider-specific entities. Message-Orientated Middleware (MOM) vendors may identify a destination using terminology other than topic or queue. The terms topic and queue are used in JMS to represent destinations that are actually mere abstract representations of the physical destinations provided by the vendor. This is because a vendor may define different messaging behaviors for their product but also provide a JMS interface so as to allow JMS clients and users to interoperate with their MOM, software.

One typical example is IBM's MQSeries product (see Appendix A for details). The destinations created by the system administrator through the provider's administrative tool are actually the only way to create these permanent physical queues or topics on the MOM messaging server. Permanent physical destinations are expensive and are usually associated with database tables or files.

Important 

The JMS 1.0.2 specification explicitly states that the physical creation of destinations (topics and queues) is an administrative task, and is not to be performed by JMS messaging clients. A portable JMS messaging client application should therefore obtain a reference to any administrated object (connection factories and destinations) using a JNDI lookup.

Temporary Destinations

If you want to create a destination directly from a JMS client, you should use javax.jms.TopicSession.createTemporaryTopic() or javax.jms.QueueSession.createTemporaryQueue(). These temporary queues and topics have delete methods (TemporaryTopic.delete() or TemporaryQueue.delete()) and there is never a chance of creating a temporary queue or topic that already exists due to how they are specified. Temporary destinations are the only API defined by the JMS secification that can be created and deleted by JMS messaging clients in a portable fashion.

You don't have to rely on the provider to provide a temporary destination; you can define that on the JMS client-side application. These dynamically created temporary destinations are not expected to survive a sever failure. Dynamic destinations could be lightweight and reside in memory. Again, this depends on the provider's implementation. If you read between the lines of the JMS specification, temporary destinations can only be consumed by sessions of the same connection.

Use of createTopic() and createQueue()

While perusing the interfaces defined in the JMS API for sessions, it appears possible to use javax.jms.TopicSession.createTopic() or javax.jms.QueueSession.createQueue() to create physical destinations directly. Please realize that JMS defines only the interfaces, not the implementation. These methods are not for creating a physical topic or queue.

The current JMS API is specifically intended not to specify any administration APIs. It was assumed that different JMS providers would have different sets of administration requirements. The creation of a non-temporary queue or non-temporary topic was considered to be a feature provided by the JMS provider's administration facilities. But allowing creation of permanent destinations directly from a JMS client application is definitely not JMS-compliant.

This approach may work well in a small-scale environment, but definitely not in a large-scale enterprise environment. Danger looms when you blend the role of a system administrator with that of a user, for the same reason that you don't want to give DBA privileges to every database user.

Those objects created by createTopic() or createQueue() are just programming abstractions of the provider-specific destinations. The calls are intended to create identifiers to reference destinations that are maintained by the JMS provider. The physical destinations have to exist already before a JMS client can invoke the corresponding createTopic() or createQueue() methods.

The JMS 1.0.2 specification explicitly states that these methods are not expected to directly cause a destination to be created in a JMS provider. createTopic() and createQueue() are only factories to create a destination reference with a provider-specific name. If that destination doesn't already exist physically, the client will receive an InvalidDestinationException if it attempts to create a sender on that destination.



Professional JMS
Professional JMS
ISBN: 1861004931
EAN: 2147483647
Year: 2000
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net