sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Re: Proposed resolution to issue BINDINGS-48
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Thu, 12 Mar 2009 12:59:27 +0000
Dave, that's not the impression I got,
however even I'm not sure that we could resolve BINDINGS-48 by replacing
JMSDeliveryMode attribute by an intent; I think that has to be a separate
issue. I don't think there's anything that forces it to be an intent, other
than that provides us with a better way of describing conflicts with other
intents (?). Mapping that to an intent that allows NON_PERSISTENT
to be required would still conflict with atLeastOnce and we'd still need
pretty much the same text to be placed somewhere...
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 - Simon_Holdsworth@uk.ibm.com
David Booz <booz@us.ibm.com>
11/03/2009 17:52
|
To
| sca-bindings@lists.oasis-open.org
|
cc
|
|
Subject
| Re: [sca-bindings] Re: Proposed resolution
to issue BINDINGS-48 |
|
Hi Simon,
You said:
>> From this I read that it ought to be OK to include SOAP in the
alwaysProvides or mayProvides of binding.ws bindingType, but that for a
specific configured instance of a binding.ws it is an error for that binding
to specify the SOAP intent along with a wsdlElement that points to a non-SOAP
binding.
@alwaysProvides and @mayProvides are different. Your statement above is
correct for @mayProvides, but not for @alwaysProvides. @alwaysProvides
does not require the application of an @alwaysProvides intent to the binding
in order to obtain the behavior.
>>Including atLeastOnce in the mayProvides of binding.jms bindingType,
but for a specific configured insitance of a binding.jms it is an error
for that binding to specify the mayProvides intent along with a @JMSDeliveryMode
of NON_PERSISTENT
I agree with this. The Policy FW rules being discussed are talking about
conflicts on binding instances.
>> If someone can point me to the policy text that says it is illegal
to have an intent in the mayProvides that can potentially conflict with
binding configuration I'd appreciate it.
I don't believe there is text of this sort....the closest is clearly about
instances (line 220 in CD02):
"If the configured instance of a binding is in conflict with the intents
and policy sets selected for that instance, the SCA runtime MUST raise
an error. [POL30001]."
I thought the point Mike was making is that we should make NON_PERSISTENT
an intent so that it's not possible for the user to hang themselves by
inadvertently creating an erroneous binding instance. He should clarify
for himself.
Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com
Simon
Holdsworth ---03/11/2009 07:49:53 AM---Folks, I was somewhat surprised
by the reaction to my proposed resolution to

From:
| 
Simon Holdsworth <simon_holdsworth@uk.ibm.com>
|

To:
| 
sca-bindings@lists.oasis-open.org
|

Date:
| 
03/11/2009 07:49 AM
|

Subject:
| 
[sca-bindings] Re: Proposed resolution to issue BINDINGS-48 |
Folks,
I was somewhat surprised by the reaction to my proposed resolution to issue
BINDINGS-48 "How are mayProvide intents on bindings satisfied "
last Thursday.
My proposal was based on the email from Mike Edwards (http://lists.oasis-open.org/archives/sca-bindings/200810/msg00041.html).
I looked at the resolution to issue POLICY-56 and POLICY-61 and neither
states that it is illegal to have an intent in mayProvides that can potentially
conflict with binding configuration. The resolution to POLICY-56 says the
following:
If the configured instance of a binding is in conflict with the intents
and policy sets selected for that instance, the SCA runtime MUST raise
an error. For example, a web service binding which requires the SOAP intent
but which points to a WSDL binding that does not specify SOAP.
It does not say that it is illegal to have SOAP in the mayProvides of binding.ws
bindingType because of this potential configuration error.
From this I read that it ought to be OK to include SOAP in the alwaysProvides
or mayProvides of binding.ws bindingType, but that for a specific configured
instance of a binding.ws it is an error for that binding to specify the
SOAP intent along with a wsdlElement that points to a non-SOAP binding.
I don't see the difference between that and:
Including atLeastOnce in the mayProvides of binding.jms bindingType, but
for a specific configured insitance of a binding.jms it is an error for
that binding to specify the mayProvides intent along with a @JMSDeliveryMode
of NON_PERSISTENT
If someone can point me to the policy text that says it is illegal to have
an intent in the mayProvides that can potentially conflict with binding
configuration I'd appreciate it.
Maybe I'm looking at this from the wrong direction. Another question is:
Can an intent require that specific binding properties are set to specific
values? and if so, can you include that intent in @mayProvides?
Perhaps we are confusing the need to set properties to particular values,
with the need to avoid setting properties to particular values...?
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 - Simon_Holdsworth@uk.ibm.com
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]