Re: WS-Transfer and HTTP, re TAG Issues whenToUseGet-7 & endPointRefs-47

Hi,

I wanted to wait for others to chime in, but as nobody has yet, I'll bite. 8-)

I think WS-Transfer is actively harmful to the Web and that the TAG
should recommend against its use.

Of course, that's not very helpful advice on its own, as it leaves
those who might be considering using it without an alternative.  So
I'd also recommend that you address the real or perceived shortcomings
with HTTP that motivated WS-Transfer's development.  I note that
you've outlined what appears(?) to be best guesses at the motivation
for it's development, but I think it would be useful to hear from each
of the companies that were involved in its development (if you haven't
already).

Some comments while I'm here ..

On 10/24/06, Tim Berners-Lee <timbl@w3.org> wrote:
> We infer that WS-Transfer is intended for
> situations where:
>
> * HTTP functionality is required but over some
>    message-passing system which does not support TCP

Ignoring the fact that HTTP has no dependency upon TCP, I've yet to
see Web services which weren't built upon TCP (I've seen Microsoft's
SOAP-over-UDP spec[1], but haven't heard t being used in practice,
only in the WS-Discovery spec[2]).  So I really wonder how much of a
motivation that is.

> * There is a requirement for Web Services
>    capabilities, but no API is available to
>    access the HTTP protocol layer

That sounds a little far fetched to me, but supposing it's the case,
why not tunnel HTTP itself through HTTP POST?  HTTP is far more
feature-rich, higher performing, and generally mature than
WS-Transfer.  Why a new protocol with essentially no advantage over
HTTP (save for mandatory extensions in the processing model), but many
drawbacks?

> * There is a requirement for some Web Service
>    capability that HTTP does not provide

If that's the case, I'd like to hear some specific examples.  The only
capability that comes to mind that SOAP has (in practice) that HTTP
doesn't, is mandatory extensions.  But one can use SOAP & mandatory
extensions in a manner compatible with Web architecture; WS-Transfer
chose not to, for some reason that we need to find out.

> The design of WS-Transfer raises a number of issues, several of which
> are
> mentioned in the W3C's staff comment on the submission [3].  These
> issues
> include:
>
> * Does WS-Transfer's use of Web Services Addressing
>    End Point References (EPRs) instead of URIs
>    damage the Web?

I would say so, both because EPRs support non-URI identification, but
also - as mentioned earlier - a WS-Addressing+SOAP based stack atop
HTTP doesn't populate the HTTP Request-URI field of the would-be
message.

> * When WS-Transfer is carried over HTTP, can it make
>    proper use of HTTP as an application level-protocol?

I can't see any way in which this would be possible, no, because all
WS-Transfer messages have the effective operation within the POST
body.

WS-Transfer doesn't even have the semantic equivalent of a POST
operation so that one could say that they were doing "POST over POST".

>    Should a default HTTP binding be specified to promote
>    proper use of the WS-Transfer/SOAP/HTTP combination?

I don't think that would be very useful, for the same reason that SOAP
support for GET was (in practice) a waste of time, as was
WS-Addressing's pseudo-warning against using reference properties.
Web services implementors don't seem to care about TAG advice because
(AFAICT) they have their own views of how things should be, and don't
yet appreciate that the Web offers a better way forward for most of
what they're trying to accomplish.  So let's show them.

Thanks.

 [1] http://msdn.microsoft.com/ws/2004/09/soap-over-udp/
 [2] http://msdn.microsoft.com/library/en-us/dnglobspec/html/WS-Discovery.pdf

Mark.

Received on Thursday, 2 November 2006 19:03:28 UTC