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

I'm not here to praise WS-Transfer, but would like to comment on
the validity of one of the use-cases:

Mark wrote:
>>
>> * 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.

We do have a large number of SOAP messages which flow over multiple,
sometimes very convoluted message paths, especially to systems
which aren't reliably online but have Email or MQ, and to legacy systems
which for various reasons have no HTTP support but have MQ or CPIC/SNA
channels. 

In such cases SOAP is seen as providing a useful envelope for
packaging messages as they hop from one message path to another. 

>> * 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?

That's true, but I personally can't get excited about WS-Transfer since the
use-cases don't typically fit in the controlled world of legacy integration
and I'm not hearing people demand us to support it on our public
SOAP endpoints. Let's face it, they're all too busy trying to get the basic 
WS-* stuff to interoperate without adding this to the mix.

Paul

Received on Wednesday, 8 November 2006 17:03:50 UTC