Re: When is a Fault a Fault?

 Mark,
 you admit that it's easy to think that the web architecture is
only good for "serving web pages", and therefore not applicable
to bigger "e-business" tasks (or indeed, any distributed task or
computation); that's almost exactly what I think. 
 You say that the current web architecture is a big leap, and I
don't oppose this, it's just that not many people have made the
leap yet. Like myself.
 I think it will be helpful if you describe on a real scenario 
(say reservation and payment of plane tickets) how you'd do it 
using SOAP _and_ the current web architecture. 
 As I see it, either we want SOAP as it stands (as a messaging
protocol), in which case we either tunnel through HTTP (and any
other application protocol) or we ditch the so called application
protocol bindings altogether; or we want the web architecture as
it stands, in which case we'll probably need to redefine SOAP and
maybe tie it to HTTP completely.
 I'm not opposed to being enlightened, but sometimes I do need to 
see a real scenario in the new paradigm before I see that the 
paradigm can be used in such class of scenarios.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 5 Mar 2002, Mark Baker wrote:

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

Received on Tuesday, 5 March 2002 15:26:51 UTC