- From: Eric Johnson <eric@tibco.com>
- Date: Tue, 16 Sep 2008 09:18:40 -0700
- 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?
-Eric.
Received on Tuesday, 16 September 2008 16:19:18 UTC