[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Issue 124 proposal version 2 - a comment
On 3/26/2010 5:05 PM, Eric Johnson wrote: > Hi Mike, > > Was their discussion of your point during the conference call? > My recollection is that there was a general consensus (rather, no one objected) to open a new issue. > What are the cases here? > > * service, @wsdlElement references port - BWS20007 states that you > must somehow interpret policy from the WSDL, and that that policy > must match.... > * service, @wsdlElement references binding - BWS20011 - ditto. > * reference, @wsdlElement references port - BWS20009 - ditto > * reference, @wsdlElement references binding - BWS20013 - ditto. > * reference, @wsdlElement references service - oops, looks like we > missed this case. I believe this addresses a different issue. The above talks about SCA Policy and not WS-Policy. There is no requirement to support WS-Policy in SCA Policy. > > So my interpretation is that if you reference a WSDL directly, if you > don't understand some policy language, then you'll be forced to reject > scenarios that the customer expects you to accept. Yet, if I'm reading > SCA-Policy correctly, a conforming runtime will already support > WS-Policy. I don't think this is a requirement. A conforming runtime, I believe, is allowed to reject a composite that uses WS-Policy. > So the scenario is that it could somehow feign ignorance of > WS-Policy when it encounters it in WSDL when used by binding.ws, but > support it in other circumstances? > One factor to consider when WS-Policy is used in WSDL is whether wsdl:required='true'. If not, it is ok to ignore the WS-Policy. > I agree that there's a gap here, but it is a really small one. > > Here's a question: If I refer to a WSDL port, is it legitimate for an > implementation to *add* policy implementation on top of a bare port > declaration - that is one that doesn't have WS-Policy statements? For > example: > > * Can an implementation satisfy a policy intent with the use of > mutual SSL authentication, even if there's nothing about that > stated in the WSDL port that the @wsdlElement references (although > presumably it uses an "https" URL scheme)? I believe this is possible. In any case, as a general issue, I think it is hard to figure out whether a particular intent was actually implemented. > * Likewise, can an implementation decide to use WS-RM even if the > referenced WSDL port doesn't state that in the WSDL? > I believe it is possible. The WSDL would set the minimum bar, you can always do more. Especially, for things like WS-RM where there is a handshake that takes place. Now, of course, if WS-RM is *required* and it is not stated in WSDL, you have no chance of interop. > The port form of @wsdlElement, then, becomes a way to specify mapping of > SOAP constructs to the XML payload, and not necessarily other constraints. > > Are we over-specifying this? > > On the WSDL generation side, do we want to mandate that a WSDL MUST be > generated with WS-Policy statements? Should we add something to section > 2.4? My quick take is that we should not mandate it. > > -Eric. > > On 03/25/2010 04:42 AM, Mike Edwards wrote: >> >> Folks, >> >> I'd like to pick up on something Eric mentions in his email below: >> >> " In the context of SCA, if someone uses the @wsdlElement form, then >> they'd be forced to support the WS-Policy spec" >> >> >> I find it surprising that the SCA binding.ws specification does not >> REQUIRE support of the WS-Policy specification. >> >> This is particularly the case given that the spec defines a WS-Policy >> policy. >> >> >> So: Should we raise an issue to add a conformance requirement that a >> binding.ws implementation MUST support the WS-Policy >> specification (although not any specific policy assertions other than >> the one defined within the binding.ws spec).? >> >> >> 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: mike_edwards@uk.ibm.com >> >> >> From: Eric Johnson <eric@tibco.com> >> To: Anish Karmarkar <Anish.Karmarkar@oracle.com> >> Cc: sca-bindings@lists.oasis-open.org >> Date: 25/03/2010 05:59 >> Subject: Re: [sca-bindings] Issue 124 proposal version 2 >> >> >> ------------------------------------------------------------------------ >> >> >> >> Hi Anish, >> >> On 03/24/2010 02:51 PM, Anish Karmarkar wrote: >> Version 2 based on feedback from last week's call is attached. >> >> * Fixed editorial bugs pointed out by EricJ in section 6. >> >> * I did some due diligence on the question of whether creating >> independent conformance points for WSCB service/client results in a >> problem (as pointed out by EricJ), since the other non-section5 >> conformance items are no longer applicable to WSCB service/client. I >> found 5 assertions that are somewhat related (noted below). The others >> are about binding.ws syntactic elements/attributes or something similar. >> >> Thanks for spending the time to do that. I've been hoping to find the >> time to get to that all week, and didn't, so I'm glad you did. >> >> >> a) there is MUST for SOAP 1.1 and a SHOULD for SOAP 1.2. Section 5 >> also talks in several places about SOAP header blocks. Strictly >> speaking there is no necessity to require SOAP (1.1 or 1.2) for this >> protocol. It could depend only on WS-Addressing. But that is a >> separate issue. To fix this, I have changed the intro to 5.1 to state >> that this is a soap/ws-addressing based protocol. I didn't see a >> reason to introduce assertions for requiring SOAP/WS-A. It is required >> by definition. But if ppl feel strongly we can introduce new >> conformance items. >> >> Seems sort of ironic, though, if we define this stand-alone protocol, >> and then it is possible to implement it in a way that is conformant, >> and yet not compatible with an SCA runtime. Seems to me that we should >> require the equivalent level of SOAP support, and therefore have the >> MUST and SHOULD requirements around SOAP. >> >> Maybe this is an equivalent nit, but we should likewise require >> support for HTTP & HTTPS. >> >> BWS50010 is sort of tricky. In the context of SCA, if someone uses the >> @wsdlElement form, then they'd be forced to support the WS-Policy >> spec, as well as this requirement to recognize this policy assertion >> when it appears in WSDL. Yet if we step away from that, to this >> stand-alone definition, what's the conformance target for saying "if >> your WSCB supports WSDL, then you must support this policy assertion?" >> >> Likewise for BWS50013 & 50014. >> >> >> b) There is a requirement for conforming to SCA assembly and policy. I >> don't think this is needed (it would defeat the purpose of the issue >> itself). >> >> c) There is a SHOULD for http endpoints to provide a wsdl description >> when queried with ?wsdl and a SHOULD for non http endpoints to provide >> some way to obtain the WSDL descriptions. I didn't see a need to have >> this requirement on WSCB service/client endpoints. I see this as a SCA >> runtime requirement not a protocol requirement. >> >> * wrt Dave's comment about BWS5005/7, I'm not sure what needs to >> change. I added a sentence at the beginning of section 5.1 that says >> that WSCB service implements the forward interface and the WSCB client >> implements the callback interface. >> >> Comments? >> >> Miscellaneous nit - Sections 6.2 & 6.3 reference Appendix B for >> "Conformance items related to WSCB...", but that shows up as Appendix C. >> >> And in section C, I don't see that you've separated out the >> conformance requirements for WSCB client and server into a separate >> section. >> >> Two minor editorial nits that I noticed, which Anish's proposal didn't >> change, per-se: >> "There are four categories of artifacts for which... SCA WS Binding >> XML Document ... SCA Runtime" >> >> Shouldn't this be (to match the plural form): >> "There are four categories of artifacts for which... SCA WS Binding >> XML Documents ... SCA Runtimes" >> >> I also don't like the use of "artifact" here, because I associate the >> word with something less operational than an "SCA Runtime". Can't we >> just use the phrase: >> "This specification defines four targets for conformance:" >> >> -Eric >> >> >> -Anish >> -- >> >> On 3/18/2010 9:01 AM, Anish Karmarkar wrote: >> Proposal for issue 124 as outlined in [1] is attached. >> >> -Anish >> -- >> >> [1] >> _http://lists.oasis-open.org/archives/sca-bindings/201003/msg00000.html_ >> >> >> >> --------------------------------------------------------------------- >> 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_ >> >> >> >> >> ------------------------------------------------------------------------ >> >> / >> / >> >> /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]