W3C home > Mailing lists > Public > public-soap-jms@w3.org > September 2008

Notes about URI scheme

From: Eric Johnson <eric@tibco.com>
Date: Tue, 16 Sep 2008 09:18:40 -0700
Message-ID: <48CFDC60.6070700@tibco.com>
To: "SOAP/JMS (list)" <public-soap-jms@w3.org>

As it happens, I also have a question of significant substance about the 
proposal as it stands.

Specifically, we currently have the two variants: "jndi" & "context".  
I'm wondering whether we should add two additional variants: "queue", 
and "topic"?

This comes from observing that the JMS specification has a Session 
object with two methods, "createQueue", and "createTopic" - each takes a 
String.  Mind you, these methods are badly named, in that they don't 
create the underlying transport object, just the JMS representation of 
them.  Likewise, given a Queue or a Topic, you can call getQueueName(), 
or getTopicName() respectively on a queue or a topic.  As a consequence, 
you can take a queue, get its name, and then look up the same queue from 
some other location.

JMS notes that these names are specifically not vendor independent.  So 
this approach for identifying queues and topics is of somewhat more 
limited value.  The question is - how limited?  Should we bother to put 
some authority behind them?

Anyway, the specifics of the proposal boil down to this - assuming one 
has a Connection, one can then get a Session, and provided one has both:

    * A String naming a Destination
    * A flag indicating that the aforementioned String is a queue or a topic

You can then get a destination object.  The cleanest way I've come up 
with to consider this approach, based on discussions internally, is to 
do the following:

    * jms:queue:<some queue name>
    * jms:topic:<some topic name>

Now, if you happen to need a JMS Session, with this proposal, I suggest 
we would allow the use of the parameters jndiURL, 
jndiInitialContextFactory, and jndiConnectionFactoryName to obtain the 
necessary context.  Of course, the problem with that "solution" is that 
it sort of begs the question - if you have JNDI information to get you 
as far as the ConnectionFactory, why wouldn't you have the JNDI 
information for the destination itself?

Does it make sense to add the two proposed variants to the "jms" URI?

Received on Tuesday, 16 September 2008 16:19:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:19 UTC