Re: WebDAV effeciancy

B. Shadgar wrote:

>[...] many functionality of the WebDAV can be implemented by HTTP POST method, Soap and so on ( as you
>mentioned like Microsoft FrontPage). So if the security is the same and if the speed may be low (not sure), why would the user choose WebDAV rather HTTP?
>
I'm actually implementing a SOAP-WebDAV proxy service that provides 
WebDAV functionality to clients that do not speak WebDAV, yet have a 
HTTP stack and can do XML processing (and, hence, SOAP as well). I'll be 
running some performance tests and can send them to you when they're 
available if you're still interested. Ignoring the performance issue 
momentarily, however, there are several reasons one should use WebDAV 
over HTTP POST, SOAP, and cetera. Without digressing into a full 
discussion of architectural styles and ideals not appropriate for this 
forum, I'll summarize what I feel is the main consideration.

One of the reasons that the web has been so successful is that, at the 
protocol level, there is a standardized interface for interacting with 
web resources. WebDAV has extended the HTTP protocol to provide 
functionality necessary for distributed and collaborative authoring. 
SOAP breaks this genericity of interface by allowing arbitrary methods 
with arbitrary functionality to be exposed as a web service. So, while 
it is possible to provide WebDAV-like functionality using SOAP, there is 
no guarantee of interoperability between clients and servers taking this 
approach. Another, somewhat lesser, concern has to do with the opacity 
of URLs. A SOAP based web service that provides WebDAV functionality is 
essentially manipulating web resources indirectly; behind the scenes, as 
it were, so the resource you would address a PROPPATCH to isn't the same 
resource that you would address a GET to, even though you are intending 
them to be the same...

Regarding performance, I have stong suspicions that straight WebDAV 
would be faster than any SOAP-based service due to the overhead in 
marshalling/demarshalling the request and response bodies. Again, I'll 
be testing this empirically in the next couple of months. That being 
said, there are compelling reasons why such a service might be 
desirable. As I mentioned above, some classes of devices don't support 
WebDAV, but can do SOAP over HTTP and it may be desireable to provide 
WebDAV functionality to these devices until their protocol stack is 
enhanced. Further, it allows one to insert extra processing (such as 
transactional support, for example) into the mix. This home grown 
solution is somewhat half-baked though, since it only allows for the 
client to interoperate with a single server/service implementation.

Hope this has shed a little light on your questions...

Cheers,
Elias

Received on Tuesday, 17 June 2003 17:06:17 UTC