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]
# 1

I think I've figured part of this out.

1. It would appear that you need to create a Broker (inside the Message Queue Administration Console) for every remote Broker that you wish to communicate with

2. Then for each Broker you need to create Connection Factory.

Do I have to create the seperate Borker or can I just create the Connection Factory and point it to the remote Broker?

Also how do I create the Destination in the local Object Store for the remote Broker? Since the destination properties are limited. It seems that the Destination lookup name has to be unique throughout all Brokers. Is that correct?

Preston

Preston at 2007-7-3 22:33:39 > top of Java-index,Application & Integration Servers,Sun Java System Message Queue...
# 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

isahashim at 2007-7-3 22:33:39 > top of Java-index,Application & Integration Servers,Sun Java System Message Queue...
# 3
Interesting how the forum puts smiley faces in the middleof my broker address.I meant to type (with no spaces in between):host1 : port1host2 : port2
isahashim at 2007-7-3 22:33:39 > top of Java-index,Application & Integration Servers,Sun Java System Message Queue...
# 4

OK. everything you said makes sense.

However, I'm still not clear on one thing. How do I perform a JNDI lookup on a remote queue? According to the Developer's Guide for Java Clients to perform a lookup of a destination object you shyould use the same initial context used in performing the ConnectionFactory loookup.

How would my local object store know about a remote queue, unless I configure every queue in every object store.

Thanks for the help,

Preston

Preston at 2007-7-3 22:33:39 > top of Java-index,Application & Integration Servers,Sun Java System Message Queue...
# 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

isahashim at 2007-7-3 22:33:39 > top of Java-index,Application & Integration Servers,Sun Java System Message Queue...