- From: Antoine Mensch <antoine.mensch@odonata.fr>
- Date: Thu, 16 Apr 2009 11:31:23 +0200
- To: Gilbert Pilz <gilbert.pilz@oracle.com>
- CC: public-ws-resource-access@w3.org
Gil, see comments inline Cheers Antoine Gilbert Pilz a écrit : > Antoine, > > I'm not sure I understand what you mean by "having two ways to do the > same thing does not really solve the problem". By "two" were referring > to "one way for WS-Eventing 200603 and another for WS-Eventing 1.0"? I > thought the whole point was to (a) acknowledge that there will be some > differences between WS-Eventing 200603 and 1.0 but (b) attempt to > minimize those differences to enable a shared code base between > implementations of the two? What I meant is if the "modest proposal" (i.e. use of a Delivery extension element) is optional (i.e. not supported by all servers), then a client that wants to work with both WS-E 2000603 and WS-E 1.0 will need to support (1) the WS-E 200603 syntax, (2) the "modest proposal" extension element, and (3) the new WS-E 1.0 approach (presumably using the new Format element in your use case). This is not a huge progress compared to implementing (1) and (3) only. However, what I also said is that in the case of DPWS devices, we could make (2) mandatory (and maybe profile out option (3)), which would leave us with supporting (1) and (2) only in DPWS clients. > > Let's look at side-by-side examples to see what were talking about. > The following is a WS-E 200603 Subscribe message with WS-Man 1.0 > batching extensions: > <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" > xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" > xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing" > xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd"> > <s:Header> > <wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe</wsa:Action> > <wsa:MessageID>uuid:d7c5726b-de29-4313-b4d4-b3425b200839</wsa:MessageID> > <wsa:ReplyTo> > <wsa:Address>http://www.example.com/MyEventSink</wsa:Address> > </wsa:ReplyTo> > <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To> > </s:Header> > <s:Body> > <wse:Subscribe> > <wse:Delivery Mode="*http://schemas.dmtf.org/wbem/wsman/1/wsman/Events*"> > <wse:NotifyTo> > <wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address> > </wse:NotifyTo> > *<wsman:MaxElements>6</wsman:MaxElements> > <wsman:MaxTime>PT10M</wsman:MaxTime>* > </wse:Delivery> > </wse:Subscribe> > </s:Body> > </s:Envelope> > > A literal translation of this using the "modest proposal" would look > like the following (note the use of the WS-Eventing 200603 namespace > for the Delivery element): > <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" > xmlns:wsa="http://www.w3.org/2005/08/addressing" > xmlns:wse="http://www.w3.org/2009/02/ws-evt" > xmlns:wse06="http://schemas.xmlsoap.org/ws/2004/08/eventing" > xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/2/wsman.xsd"> > <s:Header> > <wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe</wsa:Action> > <wsa:MessageID>uuid:d7c5726b-de29-4313-b4d4-b3425b200839</wsa:MessageID> > <wsa:ReplyTo> > <wsa:Address>http://www.example.com/MyEventSink</wsa:Address> > </wsa:ReplyTo> > <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To> > *<wse06:UseDelivery mustUnderstand="1"/>* > </s:Header> > <s:Body> > <wse:Subscribe> > <wse:NotifyTo> > <wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address> > </wse:NotifyTo> > * <wse06:Delivery Mode="http://schemas.dmtf.org/wbem/wsman/1/wsman/Events"> > <wsman:MaxElements>6</wsman:MaxElements> > <wsman:MaxTime>PT10M</wsman:MaxTime> > </wse06:Delivery> > * </wse:Subscribe> > </s:Body> > </s:Envelope> > In all honesty, I don't think it would be too difficult to write some > fairly efficient code that could handle either of the above. Do you > disagree? I agree it is probably manageable (I am not sure about the reuse of the namespace, though, especially if you add new elements in the namespace). > > - gp > > Antoine Mensch wrote: >> 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 Thursday, 16 April 2009 09:32:03 UTC