- From: Mark Baker <distobj@acm.org>
- Date: Wed, 28 May 2003 16:34:54 -0400
- To: www-ws@w3.org
I'll try and keep this as brief as possible, and present things slightly differently than I have been. On Tue, May 27, 2003 at 08:08:13PM -0400, Christopher B Ferris wrote: > There's an abundance of "visibility" of > the RFC2616 > defined HTTP header fields, Agreed. > but the extension headers? No "visibility" > there I'm afraid: Agreed. > I would actually go as far as to suggest that SOAP is MORE visible than > HTTP But above you just said there's an abundance of visibility into RFC 2616 headers, which I agree with. As an apples-to-apples comparison then, SOAP has no standardized headers, and therefore a generic SOAP intermediary has less visibility with respect to headers; sure, there's the wonderful role/mU stuff that's added, and while that does most definitely help SOAP visibility, I suggest that it is rather a minor contribution. In addition, since you agree that HTTP's standardized methods improve visibility, I'd also expect that you'd agree that it's standardized application methods improve visibility too, no? SOAP has no methods either. SOAP is more a framework (or at least it's used that way). HTTP is something that one builds on top of a framework, filling in application headers and methods, etc.. > because a) there is a well defined process model Yes, but HTTP has a well defined processing model too. SOAP's is richer in an important way though, and that does help with visibility as I said above, regarding role/mU. > and b) you don't have to > concern > yourself of having name collision because SOAP headers are namespace > qualified. True, but for the generic case, this isn't an issue since there are no extensions. Do you realize that what I mean by a "generic intermediary" is one that we could code today, deploy, and then never change again? As Walden described, how well would a generic SOAP intermediary do in understanding the interaction between some SOAP application produced in the future? How well would a generic HTTP intermediary do? I'll cut it off there, if that's ok. Thanks. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis Actively seeking contract work or employment
Received on Wednesday, 28 May 2003 16:45:54 UTC