RE: ISSUE 5: JMS bindingType and atLeastOne intent overlaps with settingJMSDeliveryMode

Mike,

I'm OK with this, and would be happy
to accept the original proposed resolution, which was to document the error
cases that occur between this setting and existing intents.

If there is a desire to introduce additional
standard intents that would affect the persistence of JMS messages, I'd
be happy to have that as a new issue, but in the absence of that we do
need to fix the existing behaviour.

Regards, Simon

Simon Holdsworth

STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair

MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK

Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898

Internet - 

Mike Edwards/UK/IBM@IBMGB

11-01-08 09:49

To

"OASIS Bindings" <>

cc

Subject

RE: [sca-bindings] ISSUE 5: JMS bindingType
and atLeastOne intent overlaps with setting JMSDeliveryMode

Folks, 

Thinking about this some more, I feel that we should keep the JMSDeliveryMode
in the schema. 

If folks used to JMS are used to setting this then it does not seem wise
to invent something new 

and strange for those folks. 

The fact that there will be an error if the delivery mode is non-persistent
and one or more of the 

reliable messaging intents is used is not a problem, in my opinion.  At
least they will be aware of a 

problem. 

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.

Co Chair OASIS SCA Assembly TC.

IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.

Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  

Email:   

"Peshev, Peter"
<> 

10/01/2008 17:58

To

"Michael Rowley"
<>, <>

cc

Subject

RE: [sca-bindings] ISSUE 5: JMS bindingType
and atLeastOne intent overlaps with setting JMSDeliveryMode

Hi Michael,

In today's binding call we discussed the issue, and there was an idea to

resolve that issue by the original proposal (dropping the

JMSDeliveryMode from the schema) and relying entirely on intents.

(Probably new intent for non-persistent messages)

It seems that you preferred earlier (as in the mail below) to keep the

binding configuration possibilities, and define the conflict as an

error.

Would you agree to such a suggestion -- drop the JMSDeliveryMode ?

Best Regards

Peter 

-----Original Message-----

From: Michael Rowley [mailto:] 

Sent: Monday, 8. October 2007 18:22

To: 

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:] 

Sent: Friday, October 05, 2007 12:36 PM

To: 

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

>

>

>

>   

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  You may a link to this group and all your TCs
in OASIS

at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU 

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU