JMS / JNDI question
I have a client that is supposed to communicate with a remote queue (on a different machine).
If I understand it right, the following has to occur:
1. Connect client to remove Object Store
2. Query remote Object Store for queue in question
3. Complete connection to returned queue.
My question really dealls with step 1, assuming this is the right way. How do I connect the client app to a remote object store, or do I need too?
Preston
[487 byte] By [
Preston] at [2007-11-25 18:56:29]

# 2
Hi Preston,
First, an overview -
2 things are required for JMS clients to work (msg producer or
consumer):
- which broker to connect to
- which destination to send/receive msgs from
The 'which broker' above is resolved by using a
ConnectionFactory that is configured to connect to the broker
you had in mind. For MQ, most of the time this involves
configuring the 'address' of the broker e.g. something like:
myHost:7676
The 'which destination' is resolved by using a Destination
object that basically 'refers' to the queue or topic you want.
You basically choose between a Queue or Topic object
and for MQ, you also designate a destination name.
This destination name needs to be unique only for
the broker this destination will be used.
The above objects (connection factory/destination) are created
and stored by MQ admin tools like imqadmin into a JNDI based object
store like an LDAP server for example. Note that object stores and
connection factories/destination objects are client side things and
are totally separate from the broker. The object stores are only used
by JMS clients and the admin tools.
The objects are looked up using JNDI by JMS clients that proceed to
connect to the broker and send/receive msgs to the destinations.
Now, the admin console allows you to do 2 things:
- object store management
- broker management
It should be noted that while one has the impression of
'creating' object stores or brokers in the admin console,
you really are just creating references to them i.e. like
bookmarking them for later reference/management.
Coming back to your questions -
Yes, for each broker instance you have e.g. host1:port1,
host2:port2, you can create individual references to them
in the admin console.
Each broker, would require different connection factories to connect
to them (assuming they had different host and/or ports). So you can
create this in the admin console.
You don't really need to create 'separate Brokers' since it does
nothing really other than bookmarking the broker for future
administration; which you probably will do...
Destination objects can be created similar to how connection
factories are created - all part of object store management.
I include a couple of useful urls below - all pointing to
the MQ admin guide. I think they will help answer most of your
questions.
Admin Console tutorial
http://docs.sun.com/source/817-6024/tutorial.html
Managing Administered Objects
http://docs.sun.com/source/817-6024/adminobj.html
hope this helps,
-isa
http://www.sun.com/software/products/message_queue/index.xml
# 5
Looking up connection factories or destinations shouldn't be any
different. The only thing that is different is obviously their lookup
names and return types.
QueueConnectionFactoryqcf;
Queuequeue;
String qcf_lookup_name,
q_lookup_name;
/*
* qcf_lookup_name, q_lookup_name should be set to proper lookup
* names.
*/
qcf = (javax.jms.QueueConnectionFactory)ctx.lookup(qcf_lookup_name);
queue = (javax.jms.Queue)ctx.lookup(q_lookup_name);
The Queue object is just an object that identifies what destination
on the broker you want to send or receive messages to/from. FYI -
it is not associated with any specific broker. So if you have
2 queues with the same name on 2 different brokers, you can
basically use the same Destination object for accessing either
queue. But you obviously need to use different connection
factories to get to the different brokers.
Not sure I understand your comment about '...unless I configure every
queue in every object store'.
JMS clients do not know where the broker is running or what the
names of the destinations are - all this is encapsulated by
connection factory and destination objects. The only thing that
a JMS client needs to get to is the object store using JNDI,
where all the objects are stored. Sure - the broker needs to be
also network reachable but this is assumed to be true after the
administrator sets things up and is somewhat hidden from the JMS
client.
Also, you can put all the objects for all your brokers (ie connection
factories) and destinations in one object store as long as they all
have unique JNDI lookup names.
hope this helps,
-isa
http://www.sun.com/software/products/message_queue/index.xml