[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Issue 126: proposal to add support for ws-addr(v1)
Eric, As far as 'feature creep' goes, I agree. But the big feature here is ws-policy. Compared to that, ws-addressing support is trivial, more importantly most (all?) recent stacks already support it, and you can't do any interesting interactions other than sync req-res over HTTP req-res. FWIW, in retrospect, I think ws-addressing should have been baked into SOAP. -Anish -- On 5/5/2010 5:56 PM, Eric Johnson wrote: > I've not looked at the specific proposal yet, but my skepticism persists. > > Just because we're unable to to test a proposal to mandate something, > we've gone down the path of: > > * Mandating support for WS-Addressing > * Mandating support for EPR where we used to just suggest it. > * Mandating support for the WS-Policy indication that flags the use > of WS-Addressing > * Mandating support of the protocol assertion for the protocol when > support is there > > ... all around an issue where we all seem to agree that the use cases > are unclear. My design instincts are screaming "feature creep!" All of > this nets out to an implementation needing to recognize the > WS-Addressing assertion in a concrete referenced WSDL, and then using > the support that we've now mandated. It doesn't actually reveal much > about actual support for the underlying concern - WS-Policy. The above > set of mandates does reveal the ability to recognize XML elements in a > particular scenario and not barf them up, but that's about it. > > WS-Policy is a particular XML-based expression of a model for policies - > a "platform dependent model" (PDM) in UML terms. SCA intents come close > to being a "platform independent model" for policy requirements as I've > seen. > > Without a mandate to use WS-Policy, implementers can happily punt on > correlating between the two, and hopefully avoid complexity for > themselves and their customers by always generating one (the PDM) from > the other (PIM). In fact, the way to generate the PDM from the PIM is > to define the mechanism that does the one-way translation. In mandating > WS-Policy, we might make it necessary for implementations to think about > having a bi-directional model between the two, where (a) it might not > make sense, and (b) it may actually be more confusing to the end-user > than simply giving an implementation the freedom to say "I don't > understand how to do what you're asking me." > > Does anyone actually have implementation experience that suggests that > this particular mandate works? If so, I will happily hear the details > and how they work, and be quiet. Otherwise, I think we're going to far > with 126. > > -Eric > > On 05/05/2010 01:09 PM, Anish Karmarkar wrote: >> Attached. >> >> The proposal uses cd03-rev4 as the basis (with changes accepted). The >> relevant changes are confined to section 2.10 (new section) and >> section 6.4. Do note that Mike & I had taken a joint AI to produce a >> complete proposal for issue 126. The attached doc adds support for >> ws-addr but not for ws-policy. >> >> I have made one change that was not discussed on previous calls or on >> the ML: when the callback protocol is supported I had made changes >> that require the runtime to support the callback protocol policy >> assertion. Since this proposal is about requiring ws-policy, I thought >> it made a lot of sense to mandate support for the protocol assertion >> when the protocol is supported. >> >> If this (or something like this) is accepted, I think we should make >> the endpointReference element mandatory (currently it is a SHOULD). >> Especially, since the UPA issue resolution means that it would be the >> same element defined in ws-address. But on the last call, someone >> expressed preference to deal with this separately. I'll raise an issue >> related to that if/when 126 is resolved. >> >> Mike: I know this proposal doesn't give you a lot of time to add >> ws-policy support before the bindings call. Please let me know if you >> don't have time and I can try and add that later this evening/tonight >> (my time). >> >> Thanks. >> >> -Anish >> -- >> >> >> --------------------------------------------------------------------- >> 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]