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

What's always kind of been amusing to me is how backwards most of this 
thread has been.
As a resource constrained device owner I would push for a little 
specialized code as possible - and want to reuse as much as possible. This 
means that having two different ways of expressing the same thing 
(NotifyTo vs EndTo/ReplyTo/FaultTo) would be a concern to me.  From a 
coding perspective there is no difference between sending a notification 
and sending the SubscriptionEnd or Reply or Fault.  So having the same 
piece of code do all of them would be a benefit.  And yet some of those 
small device guys seem to be advocating for more code.  I have to admit, 
it makes no sense to me.

On the MC thing.  If (and that's "if") we keep Mode, I could live with a 
MCPull mode URI if that would make people happy. However, in deference to 
Wu's concerns expressed at the f2f I tried to minimize the amount of hard 
references to MC.  But if other people are ok with it then that's fine.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Antoine Mensch <antoine.mensch@odonata.fr> 
Sent by: public-ws-resource-access-request@w3.org
04/14/2009 08:08 AM
Please respond to
antoine.mensch@odonata.fr


To
public-ws-resource-access@w3.org
cc

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






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.

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.

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.


Cheers

Antoine Mensch