- 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