[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-bindings] ISSUE 5: JMS bindingType and atLeastOne intent overlaps with setting JMSDeliveryMode
I think this is a great issue. I believe that the spec should say that if there is a conflict between a required intent and the semantics associated with a binding configuration, then it should be a deployment error. In the case of the JMS specification, specific potential conflicts, such as the one described here, should be defined. Michael -----Original Message----- From: Eric Johnson [mailto:eric@tibco.com] Sent: Friday, October 05, 2007 12:36 PM To: sca-bindings@lists.oasis-open.org Subject: [sca-bindings] ISSUE 5: JMS bindingType and atLeastOne intent overlaps with setting JMSDeliveryMode Logged as http://www.osoa.org/jira/browse/BINDINGS-5 Peshev, Peter wrote: > TARGET: > JMS Binding Specification Version 1.1, Working Draft 25 September 2007 > > > DESCRIPTION: > > The current bindingType of the jms is defined as : > > <bindingType type="binding.jms" alwaysProvides="jms" > mayProvide="atLeastOnce atMostOnce ordered conversation"/> > > Not being at all policy expert and under the assumption that > "mayProvide" is supposed to indicate - ("in some scenarios when the > binding is used, this may be provided, the assembler by supplying > intents can influence the runtime behavior of the binding"), here is the > question : > > The semantics of atLeastOnce is actually having persistent messages over > a queue, and persistent messages + durable subscriptions over topic. > If that can be configured by intents by the assembler, doesn't it > overlap with the setting of JMSDeliveryMode in the schema of the JMS > binding ? Which one wins in case of conflict ? > > > PROPOSED SOLUTION > Drop JMSDeliveryMode from the schema > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]