OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-policy] Re: [sca-bindings] Re: [sca-policy] Suggested wordingfor POLICY-83


Dave,
Thanks, this helps.  I understand your interpretation of what the
unqualified SOAP intent means now.  Let's continue this discussion
in the Bindings TC under BINDINGS-73.

   Simon

David Booz wrote:
> ...sigh...
> 
> "If the intent is attached in an unqualified form then any version of 
> SOAP is acceptable."
> 
> That statement is simply repeating the meaning of an unqualified but 
> qualifiable intent, i.e. it can always be further qualified by another 
> part of the composite. What does the SOAP intent mean to an assembler 
> that finds it on a service or reference element? It means that he must 
> find a binding that can provide SOAP. Any version of SOAP is fine 
> because the developer did not constrain it. The assembler may have to 
> add the 1_2 qualifier if that's what he wants to provide. If he says 
> nothing, the FW will handle resolving the intent to a binding (or 
> policySet) based on the default qualifier.
> 
> 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
> 
> Inactive hide details for Simon Nash ---05/14/2009 10:31:14 AM---Dave, 
> Here is an extract from the Policy spec CD02 rev1:Simon Nash 
> ---05/14/2009 10:31:14 AM---Dave, Here is an extract from the Policy 
> spec CD02 rev1:
> 
> 
> From:	
> Simon Nash <oasis@cjnash.com>
> 
> To:	
> David Booz/Poughkeepsie/IBM@IBMUS
> 
> Cc:	
> sca-bindings@lists.oasis-open.org, sca-policy@lists.oasis-open.org
> 
> Date:	
> 05/14/2009 10:31 AM
> 
> Subject:	
> Re: [sca-policy] Re: [sca-bindings] Re: [sca-policy] Suggested wording 
> for POLICY-83
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Dave,
> Here is an extract from the Policy spec CD02 rev1:
> 
> 2283 SOAP – The SOAP intent specifies that the SOAP messaging model is 
> used for delivering
> 2284 messages. It does not require the use of any specific transport 
> technology for delivering the
> 2285 messages, so for example, this intent can be supported by a binding 
> that sends SOAP
> 2286 messages over HTTP, bare TCP or even JMS. If the intent is attached 
> in an unqualified form
> 2287 then any version of SOAP is acceptable.
> 
> This text states that the unqualified SOAP intent allows either
> SOAP 1.1 or SOAP 1.2 to be used.
> 
> Here is another extract from the same spec:
> 
> 2290             When a SOAP intent is qualified with 1_1 or 1_2, then 
> SOAP version 1.2 or SOAP
> 2291 version 1.2 respectively MUST be used to deliver messages. [POL100002]
> 
> This text states that the qualified intent SOAP.1_1 allows only
> SOAP 1.1 to be used, and prohibits the use of SOAP 1.2.
> 
> Taking these two statements together, it seems clear that the 1_1
> qualifier cannot be the default for the SOAP intent.
> 
>   Simon
> 
> David Booz wrote:
>  > Simon,
>  >
>  > I don't see how you can come to that conclusion from the quoted text.
>  > The relevant part seems to be the first bullet. The MUST says 'use
>  > SOAP'. That is not inconsistent with the way that the SOAP intent is
>  > currently defined, neither is the "can" in the next line. The intent
>  > definition is going to get you SOAP 1.1 but there's nothing that would
>  > prevent a runtime from also using SOAP 1.2 (remember, only the SOAP
>  > intent was specified in the use case in question so the other two
>  > bullets in section 4.1 don't apply).
>  >
>  > However, I do agree that there could be different interpretations given
>  > the current state of the binding and policy specs. As I've said before,
>  > the Policy TC doesn't care what the definition of the SOAP intent is,
>  > the Policy TC only cares that the Policy FW is able to express the
>  > semantics needed by the various intent use cases in a way that is
>  > consistent through out all the intent use cases.
>  >
>  > What we seem to have here is a difference of opinion in how the intent
>  > FW needs to work, and this is a more serious problem. Default
>  > qualifiers, as currently spec'd by Policy, are intended to convey a
>  > default behavior for unqualified usage of the qualifiable intent (SOAP
>  > in this case). The rationale for this is that it increases portability
>  > from one runtime to another. Without this default behavior, different
>  > runtimes would be free to make different choices which would end up as
>  > subtle errors in ported applications. While intents are still abstract,
>  > the default qualifier feature further narrows the range of semantic
>  > mismatches that might occur between runtimes.
>  >
>  > My recollection of the binding TCs decision on SOAP 1.1 vs SOAP 1.2 is
>  > that we wanted SOAP 1.1 to be the default behavior (I see this embodied
>  > in section 4.2.2), but the words in section 4.1 don't quite say that, so
>  > apparently something subtle has changed and I have missed it (or maybe
>  > section 4.1 could be improved, or 4.2.2 needs fixing - I vote for the
>  > former).
>  >
>  > If the binding TC decides that we really want there to be no default
>  > qualifier for the SOAP intent then:
>  > 1) Binding TC needs to decide this and then formally communicate this to
>  > the Policy TC - If such a decision were made, I'd be happy to take the
>  > AI to inform Policy.
>  > 2) Policy TC needs to decide if can relax the default qualifier rules -
>  > Policy TC would need a sufficient justification from Binding TC and use
>  > case as this is a non-trivial change in the basic FW model. It's not
>  > impossible to change, it's just not trivial as you can see from Issue 83
>  > in policy which was aiming to simply clarify the existing FW model.
>  >
>  > 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
>  >
>  > Inactive hide details for Simon Nash ---05/12/2009 03:04:37 PM---Dave,
>  > See inline below.Simon Nash ---05/12/2009 03:04:37 PM---Dave, See inline
>  > below.
>  >
>  >
>  > From:
>  > Simon Nash <oasis@cjnash.com>
>  >
>  > To:
>  > sca-policy@lists.oasis-open.org
>  >
>  > Cc:
>  > OASIS Bindings <sca-bindings@lists.oasis-open.org>
>  >
>  > Date:
>  > 05/12/2009 03:04 PM
>  >
>  > Subject:
>  > [sca-bindings] Re: [sca-policy] Suggested wording for POLICY-83
>  >
>  > ------------------------------------------------------------------------
>  >
>  >
>  >
>  > Dave,
>  > See inline below.
>  >
>  >   Simon
>  >
>  > David Booz wrote:
>  >  > Hi Ashok,
>  >  >
>  >  > Something about this issue was bugging me last night, so I did some
>  >  > investigation in the spec this AM. Looking at CD02/PRD, line 1451 (in
>  >  > the section which normalizes attached intents into a required intent
>  >  > set), I found this statement:
>  >  > "and where any unqualified qualifiable intents are replaced with the
>  >  > default qualified form of that intent, according to the default
>  >  > qualifier in the definition of the intent."
>  >  >
>  >  > While it doesn't read quite right, the intention is clearly to replace
>  >  > unqualified intents with their default qualified form and also assumes
>  >  > that there is a default qualifier if there are any qualifiers. This
>  >  > usage of default qualifiers was a surprise to me (i.e., I forgot about
>  >  > it) as I thought that the default qualifier was only used in 
> processing
>  >  > intentMaps in policySets.
>  >  >
>  >  > I think the words you propose to resolve POLICY-83 are good.
>  >  >
>  >  > I also want to react to the last statement below:
>  >  >
>  >  >  >> In other discussions re the SOAP intents we have taken the 
> position
>  >  > that a default qualifier may not be specified. This is contrary to
>  >  > POL30004 and would require a significant change to the spec.
>  >  >
>  >  > The current SOAP intent definition has "1_1" set as the default
>  >  > qualifier. Can you help me understand what discussion you're referring
>  >  > to because I might have missed something? The web service binding
>  >  > discussions I'm aware of have not suggested changing this default. We
>  >  > have been discussing the need to declare the qualifiers to be mutually
>  >  > exclusive.
>  >  >
>  > The WS Binding spec contains normative text that is incompatible with
>  > SOAP.1_1 being the default qualifier if the unqualified SOAP intent
>  > is used.  The following is from section 4.1:
>  >
>  >  So as to narrow the range of choices for how messages are carried,
>  >  the following policy intents affect the transport binding:
>  >   • SOAP
>  >     When the SOAP intent is required, the SCA runtime MUST transmit
>  >     and receive messages using SOAP. One or more SOAP versions can
>  >     be used [BWS40001].
>  >   • SOAP.1_1
>  >     When the SOAP.1_1 intent is required, the SCA runtime MUST transmit
>  >     and receive messages using only SOAP 1.1 [BWS40002].
>  >   • SOAP.1_2
>  >     When the SOAP.1_2 intent is required, the SCA runtime MUST transmit
>  >     and receive messages using only SOAP 1.2 [BWS40003].
>  >
>  > Using 1_1 as the default qualifier for the SOAP intent would contradict
>  > the above.  This needs to be resolved between the Policy TC and the
>  > Bindings TC.
>  >
>  >   Simon
>  >
>  >  > 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
>  >  >
>  >  > Inactive hide details for ashok malhotra ---05/12/2009 08:24:55
>  >  > AM---Eric pointed out that the existing wording for conformanceashok
>  >  > malhotra ---05/12/2009 08:24:55 AM---Eric pointed out that the 
> existing
>  >  > wording for conformance statement [POL30004] states:
>  >  >
>  >  >
>  >  > From:
>  >  > ashok malhotra <ashok.malhotra@oracle.com>
>  >  >
>  >  > To:
>  >  > OASIS Policy <sca-policy@lists.oasis-open.org>
>  >  >
>  >  > Date:
>  >  > 05/12/2009 08:24 AM
>  >  >
>  >  > Subject:
>  >  > [sca-policy] Suggested wording for POLICY-83
>  >  >
>  >  > 
> ------------------------------------------------------------------------
>  >  >
>  >  >
>  >  >
>  >  > Eric pointed out that the existing wording for conformance statement
>  >  > [POL30004] states:
>  >  > "If an intent has more than one qualifier, one and only one MUST be
>  >  > declared as the default qualifier."
>  >  > and does not cover the case where a single qualifier is declared 
> for the
>  >  > intent.  See http://www.osoa.org/jira/browse/POLICY-83
>  >  >
>  >  > Suggested rewording:
>  >  > If an intent has one or more qualifiers, one and only one MUST be
>  >  > declared as the default qualifier.
>  >  >
>  >  > Note that this is an extra-Schema constraint.  The Schema provides an
>  >  > optional 'default' attribute for the
>  >  > qualifier definition in the intent so, according to the Schema, this
>  >  > attribute can be omitted for all qualifiers or
>  >  > set to 'false'.  POL30004 says that this attribute MUST be set to true
>  >  > for one and only one of the qualifiers.
>  >  >
>  >  > In other discussions re the SOAP intents we have taken the 
> position that
>  >  > a default qualifier may not be specified.
>  >  > This is contrary to POL30004 and would require a significant change to
>  >  > the spec.
>  >  >
>  >  > --
>  >  > All the best, Ashok
>  >  >
>  >  > ---------------------------------------------------------------------
>  >  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  >  > generates this mail.  Follow this link to all your TCs in OASIS at:
>  >  > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>  >  >
>  >  >
>  >  >
>  >
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  > generates this mail.  Follow this link to all your TCs in OASIS at:
>  > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>  >
>  >
>  >
> 
> 
> 
> 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]