On 22/06/2011 15:18, Adrian Johnson wrote:
> Adam,
>
> On 6/21/11 5:33 AM, Adam Bien wrote:
>>> o Removal of Queue and Topic specific interfaces in favor of general ones
>> +1 Interesting idea. It means - the client does not know whether it is PTP or PubSub?
>
> It's not that it doesn't *know* whether it is PtP or PubSub, it's more that why should that matter when it comes to
> creating Connections and Sessions?
Essentially, this is about competing the unification of domains what was started with JMS 1.1. The JMS 1.1 spec, section
1.5 "What is New in JMS 1.1?" says:
"In previous versions of JMS, client programming for the Point-to-Point and Pub/Sub domains was done using similar but
separate class hierarchies. In JMS 1.1, there is now a domain-independent approach to programming the client
application. This provides several benefits:
"• For the client programmer, a simpler programming model
"• The ability to engage queues and topics in the same transaction, now that
they can be created in the same session
"• For the JMS provider, increased opportunity to optimize implementations by pooling thread management
"To take advantage of these features, the developer of JMS clients needs to use the domain-independent or “common” APIs.
In the future, some of the domain-specific APIs may be deprecated.
"In JMS 1.1, all of the classes and methods from JMS 1.0.2b are retained to provide backward compatibility. The
semantics of the two messaging domains are retained; the expected behavior of a Point-to-Point domain and a Pub/Sub
domain remain the same, as described in Chapter 5, “JMS Point-to-Point Model,” and Chapter 6, “JMS Publish/Subscribe
Model.”"
I think what Adrian is suggesting is that we go ahead and deprecate the "domain-specific APIs" as was suggested in the
1.1 spec. This means deprecating QueueConnectionFactory. QueueConnection, QueueSession, TopicConnectionFactory,
TopicConnection and TopicSession, and their XA equivalents. It would also mean deprecating QueueReceiver.
However I note that Connection.createDurableSubscriber() returns a TopicSubscriber, not a MessageConsumer, which looks
to me like a mistake, so we might need to tidy this and no doubt other things up at the same time.
Nigel