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.comReceived on Friday, 15 March 2002 00:00:31 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:31 UTC