I guess my confusion is how can we require both types of messaging and yet
aim to disable the domain specific interfaces? I don't know that they are
required to be separate concepts, but they feel similar.
John
On Fri, Sep 16, 2011 at 9:11 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> On 19/08/2011 16:14, Nigel Deakin wrote:
>
>> On 19/08/2011 16:03, Nigel Deakin wrote:
>>
>>> I have logged this JIRA issue, which I hope is self-explanatory:
>>> http://java.net/jira/browse/**JMS_SPEC-50<http://java.net/jira/browse/JMS_SPEC-50>
>>>
>>
>> I forgot to mention that this change was proposed by Tom.
>>
>> > Any objections?
>>
>
> No-one has commented or objected. I'm not surprised - I suspect all vendors
> support both queues and topics these days, given that this is mandatory in
> Java EE. So I will assume with no further ado that this change has the
> support of the EG.
>
> (What this means is that the next time you'll hear about this is when you
> see it in the draft spec)
>
> Nigel
>
>
>
> In the JMS Specification 1.1, Chapter 1.3 "What Is Required by JMS" says:
>>>
>>> "Providers of JMS point-to-point functionality are not required to
>>> provide publish/subscribe functionality and vice
>>> versa."
>>>
>>> However Java EE 6 in Section EE.2.7.8 "Java™ Message Service (JMS)" says
>>>
>>> "The Java Message Service is a standard API for messaging that supports
>>> reliable point-to-point messaging as well as the
>>> publish-subscribe model. This specification requires a JMS provider that
>>> implements both point-to-point messaging as
>>> well as publish-subscribe messaging."
>>>
>>> It is proposed to change the JMS specification to bring it in to line
>>> with Java EE, and make it mandatory for a
>>> standalone JMS provider to implement both point-to-point messaging
>>> (Queues) and publish-subscribe messaging (Topics).
>>>
>>>