Re: When is a Fault a Fault?

>  Mark,
>  do you think it possible to use HTTP as a one-way transport for 
> SOAP?

Sure, just as I can use MIME to carry IP;

http://www.ietf.org/internet-drafts/draft-eastlake-ip-mime-06.txt

Just because you can though, doesn't mean you should.  The Web succeeded
for many reasons, most of which are being disregarded if you chose to
tunnel over HTTP;

- interfaces are specific, not generic
- state and behaviour are hidden, and visibility is much lower,
resulting in poorer security characteristics
- state change is hidden and appears arbitrary; hypermedia is no longer
the engine of state change
- interactions are typically stateful, not stateless, yielding
scalability and visibility/security issues

I know that because the Web carries porn and sites like hamsterdance.com
are everywhere, that it's easy to discount the value of the architecture
underlying it all.  It's also easy to think that it is only good for
"serving web pages", and therefore not applicable to bigger "e-business"
tasks (or indeed, any distributed task or computation).  The truth is
that the Web is gigantic leap forward in distributed systems
development, and it behooves us to be able to use SOAP in this context.

> If so, I don't think you will argue that it cannot be used 
> as part of a request/response pattern built of two one-way 
> interactions.

Nope, I won't argue that.  But I will argue that it cannot be used
this way *and* have its existing architecture preserved.

> But how do you want to send a fault, if that is the 
> response, in an HTTP request?
>  I have yet to see a compelling reason for the chameleon view.

Web architecture isn't compelling?! 8-)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Tuesday, 5 March 2002 12:17:24 UTC