Re: too many extension points (was Re: [Bug 6692] New: Remove Mode from the specification)

Gil,

some additional comments to your answers:
> There is a specification that describes how to attach policies to 
> EPRs. It is called, strangely enough, Web Services Policy Attachment 
> for Endpoint Reference (WS-PAEPR) 
> <http://www.w3.org/Submission/WS-PAEPR/>. It is not a "standard". Like 
> WS-Eventing, WS-Transfer, WS-MEX, and WS-Enumeration it is only a W3C 
> Member Submission. It's a very small spec because it expresses a very 
> simple idea; add either wsp:Policy or wsp:PolicyReference elements to 
> the wsa:Metadata element of the EPR. As you point out, attaching 
> policies to EPRs solves a number of problems across the WS-RA spec 
> set. I think we should consider incorporating this spec into WS-MEX.
I know this proposal, and I agree it's interesting, but my understanding 
is that it is not currently making progress and was not particularly 
well received by related WGs (one issue I've seen mentioned relates to 
the possible conflicts between policies embedded in EPR and policies 
derived from WSDL/other more static documents). In any cases, if this 
group can find an efficient solution to relate EPRs and policies at 
runtime, I think it could be a great addition to existing discovery and 
metadata exchange mechanisms. Maybe this is worth a "new issue" for the 
MEX spec?
> Thank you Antoine, for stating this concern so plainly and clearly. I 
> understand how the costs of multi-version support could be a burden 
> for small systems. What did you think of Bob's "modest proposal" to 
> preserve /xxx:Delivery/xxx:Mode as a deprecated extension to 
> wse:Subscribe? Do you think it would help to minimize the 
> multi-version support problem?
Well, yes and no.
In principle, I would say no, as having two ways to do the same thing 
does not really solve the problem: either you make the two ways 
mandatory and then the servers (we also have small embedded servers) 
will have to support the burden of the additional code, or you make them 
optional and we are back to step one, as the clients will have to 
support both ways to be interoperable.
In the particular case of DPWS, it could actually work, as DPWS could 
profile the WS-Eventing spec and retain only the "backward-compatible" 
version (note that this is a personal opinion, which has not been 
discussed in the OASIS WS-DD TC). Interoperability with enterprise 
systems using only the "new" approach would still be a problem though.

Cheers,

Antoine

Gilbert Pilz a écrit :
> Comments inline . . .
>
> - gp
>
> Antoine Mensch wrote:
>> Hi,
>>
>> This is the feedback of a WS-Eventing implementer on the proposed 
>> changes regarding delivery specification. We implement WS-Eventing as 
>> part of DPWS, and most of our concerns with the current proposals 
>> come from the fact that we target small platforms (typically running 
>> with 512Kbytes of Flash and 96Kbytes of RAM).
>>
>> We are very interested in solving the issue of non-addressable event 
>> sinks, and by the proposed use of WS-MakeConnection. However, this 
>> seems to have led to proposals for altogether removing the Mode 
>> attribute or even the Delivery element from the submission version of 
>> the spec (the one we implement as part of DPWS). Although the 
>> rationale for the proposals is clear (trying to replace the 
>> WS-Eventing extensibility mechanisms with existing WS-Addressing, 
>> SOAP or XML extensibility mechanisms), it raises the following concerns:
>>
>> 1) Required use of WS-Policy at runtime to ascertain support for 
>> WS-MakeConnection
>>
>> DPWS clients use WS-Discovery, WS-Transfer and WS-MetadataExchange to 
>> retrieve service endpoint information at runtime. This means that a 
>> client generally only knows "abstract" WSDL information (portTypes, 
>> operations and messages) at development time, and retrieves service 
>> EPRs based on portTypes QNames. Because there is no standard way to 
>> directly attach policies to EPRs (as far as I understand the current 
>> official position), it means that the client will need to retrieve 
>> the policies through an external means, probably looking into the 
>> WSDL document (unless this group can come up with an easier means to 
>> relate EPRs with policies through WS-MetadataExchange). This can be a 
>> tough assignment for a small embedded client.
> There is a specification that describes how to attach policies to 
> EPRs. It is called, strangely enough, Web Services Policy Attachment 
> for Endpoint Reference (WS-PAEPR) 
> <http://www.w3.org/Submission/WS-PAEPR/>. It is not a "standard". Like 
> WS-Eventing, WS-Transfer, WS-MEX, and WS-Enumeration it is only a W3C 
> Member Submission. It's a very small spec because it expresses a very 
> simple idea; add either wsp:Policy or wsp:PolicyReference elements to 
> the wsa:Metadata element of the EPR. As you point out, attaching 
> policies to EPRs solves a number of problems across the WS-RA spec 
> set. I think we should consider incorporating this spec into WS-MEX.
>> 2) Lack of a standard negociation mechanism
>>
>> If a client cannot know in advance that a service supports WS-MC (see 
>> above discussion), then it should be able to discover that at 
>> subscription time (otherwise the WSMC URI would be considered as any 
>> valid http URL and the subscription will silently never deliver 
>> notifications, except perhaps to the OASIS Web site). Such a 
>> negociation mechanism could be easily supported by the existing 
>> WS-Eventing delivery mode mechanism (using for instance a "useMC" 
>> delivery mode, to avoid entering into the Push/Pull debate). I have 
>> seen proposals to support an equivalent, more general, mechanism 
>> using a specific SOAP header block with the mustUnderstand attribute 
>> set to "true" (e.g. <wsmc:useMC mustUndersand="true"/>), however it 
>> seems that WS-MC does not define such a standard header block. So it 
>> means that WS-Eventing would need to define its own WSMC-related 
>> header block to support negociation, which does not go a long way 
>> towards reuse in other specs.
> Just because WS-MC doesn't define a "useMC" header doesn't mean WS-RA 
> can't define one in WS-MEX that can be used by other specs.
>> 3) Lack of "backward similarity"
>>
>> We understand that the W3C spec will not be wire-compatible with the 
>> submission version, at least because the namespaces used in the SOAP 
>> messages will change. However, we have concerns about the amount of 
>> proposed changes, not because of the quantity of work we will have to 
>> perform to update our implementation, but because of the quantity of 
>> code we will need to embed in our systems to support both the 
>> submission and W3C versions of the spec. Indeed, we do not expect 
>> existing implementations of DPWS (or WS-Management) running in 
>> deployed devices to suddenly upgrade themselves to the W3C version of 
>> the spec, so our Web Services clients will have to support both 
>> versions for a number of years. Obviously, limiting the amount of 
>> changes to the strictly mandatory would help us in this respect.
> Thank you Antoine, for stating this concern so plainly and clearly. I 
> understand how the costs of multi-version support could be a burden 
> for small systems. What did you think of Bob's "modest proposal" to 
> preserve /xxx:Delivery/xxx:Mode as a deprecated extension to 
> wse:Subscribe? Do you think it would help to minimize the 
> multi-version support problem?
>>
>>
>>
>> Cheers
>>
>> Antoine Mensch
>>
>>
>>

Received on Wednesday, 15 April 2009 12:37:44 UTC