Web architecture

Hi Krishna,

> Mark,
> 
> 	I fail to understand your issue with ebXML and BTP for that
> matter. They follow SOAP over HTTP. The points you are raising are basic
> to SOAP over HTTP rather than to BTP or ebXML.

That's true.  There are BTP and ebXML specific points, but I think it's
important that the one overriding Web-services/Web architectural mismatch
be addressed before talking about them.

> 	Also your term "web services protocol" is a little vague. Isn't
> it SOAP/HTTP ? There is no "web services protocol" per se.

Basically anything that isn't a data format. i.e. not WSDL, etc..

> 	Third, what exactly is wrong ? They use HTTP POST as a transport
> mechanism, which looks Ok to me. 

It's not ok if you want to conform to Web architecture.  POST is a
*method*, in the same way that getStockQuote() is a method.

Would you consider it ok if I did this?

getStockQuote( 'getWeatherReport( "OTTAWA" )' )

If not, then consider that when you do;

POST ( "getStockQuote()" )

that you are doing *exactly* the same thing.

> 	I will lok into the issue of BTP introdicung new application
> semantics. My first impression is "why not". But it is a WAG, I will dig
> into it and think more, in the mean time would appreciate any thoughts.

Introducing new application semantics isn't a bad thing.  But
introducing them in a Web architecture friendly way is difficult because
you're working with *existing* application semantics; those of the Web,
in this case.  These protocols I've seen all assume that they're working
with a clean slate, because they see HTTP as a transport protocol, which
it is not.

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