JMS Administered Objects

Question

Why are "ConnectionFactory" and "Destination" administered objects?
What does the spec mean by saying that they are administered objects?
What are the advantages of having them as administered objects? (and not any other objects in the spec)?
What are the difficulties in maintaining them programatically? Why should some one admin them? What does the admin do?
Besides the above, I have another Question:
What makes anyone use multiple Sessions in one Connection, instead of using a Single Session to send messages? Why is there a Concept of a Session? Can't it just be Connection?
Can someone throw light on (any of) these?
Thanks,
Kalyan.

Answer 1

hi.
all applications that have a JMS Connection in order to send and receive messages, should have their Connection objects hook to the same server (the JMS provider). It is therefore appropriate that they all use a ConnectionFactory that has the same characteristics and metadata. The easiest way to do it, is to register the ConnectionFactory somewhere in the system that's well-known - e.g. a JNDI service. It doesn't make sense to have all clients configured individually. This is why you administer a ConnectionFactory.
Destination objects are also common to all clients. everyone who uses your JMS provider should have access to the correct list of destinations. again - it just doesn't make sense to configure each client separately, so you register all public Destination objects in the same service (again - JNDI is a good choice).
All other objects are application-specific. a Connection/Session/MessageConsumer (and so on) object is valid only for the application that created it. there's no need to register it elsewhere, because no one else should have access to those objects. Basically, you could say, that only objects that every client should access - are to be administered.
Multiple Session objects on a Connection are used when you want to separate parts of the application. a Session means that you are serializing the delivery of messages. if you have multiple threads in your app, you might want to give each sending thread a different Session object, because otherwise - they will all block on the communal Session.
additionally - you should not use one Session object for both consuming and producing of messages, so -if your app wishes to do both, it should have at least two Session objects.
moreover - when consuming messages, you do not use the same Session object for synchronous and a-synchronous consuming. so - if you need a consumer to block until it gets a message, and you need another consumer to wake up as a listener when a message arrives - you will need two Session objects.
Last but not least, suppose you have two producers in your application. one of them needs to use a transacted Session, and the other one does not - (or you need different acknowledge modes) - you must use multiple Session objects.
hope that helps.
Nimo.