- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Fri, 25 May 2001 14:23:31 -0700
- To: "WebDAV WG" <w3c-dist-auth@w3.org>, <mikhailfranco@netscape.net>
Can't resist... > WebDAV is ugly precisely because the HTTP and XML are horribly entangled. > It's defined as a protocol, but the stack is not layered. You could make the same claim about HTTP, that it horribly entangles RFC-822 headers in with the request line of the message, without any firm layering. The simple fact is WebDAV defines a set of methods. These methods take parameters. Some parameters are encoded in headers, others in XML. People who have written DAV implementations don't have a problem with this. > It really implies a data model, yet that data model is not rigourously > defined. This is pretty typical of IETF standards, which are concerned with on-the-wire encoding, and are less interested in the underlying data model. The result is an implied, bot not normative data model. Thus, for example, even though DAV implies a data model of a resource payload plus properties, it is possible to implement this is a number of ways (Unix files + property database, NT filesystem files, database tables, as objects only comprised of attributes where a single distinguished attribute holds the payload). > SOAP evolved from XML-RPC, which was largely invented to perform site > and content management at Userland, so the original domain and > requirements are similar to WebDAV. You're confusing a marshalling and basic transport mechanism (SOAP/XML-RPC) with a semantic-rich protocol. XML-RPC and SOAP have almost no semantics whatsoever. The marshalling decisions are not the ones we spent most of our time on -- it was deciding things like "how does a locked hierarchy interact with move" and "what are the semantics of move/copy on live properties". These are tricky, subtle issues which require a lot of time to sort out in a consensus-driven standards group that is open to input from all comers, and uses a transparent process. For example, I'll note that people in W3C working groups feel no compulsion to answer random questions from newbies questioning 4 year old design decisions. Think about it. > In much less than those 5 years, SOAP has evolved > from XML-RPC, been adopted by major corporations (Microsoft, IBM, etc.), > is reasonaly standardized and on its way through the W3C, > become the basis of all web services architectures, > acquired a complete layered stack (including WSDL and UDDI), > and is likely to be the basis of all future web-delivered functionality ! Actually, I would trace the beginning of SOAP to the failed HTTP-NG effort at the W3C, which was another attempt to define a "service-oriented" infrastructure for the Web. It is no cooincidence that Henrik Nielsen was heavy involved in HTTP-NG, then went to Microsoft, and became very heavily involved in SOAP definition. Furthermore, SOAP is not nearly as far along as WebDAV in terms of adoption. Right now, people are using WebDAV in real-world settings to get their work done. There has not yet been widespread adoption of SOAP. I have no doubt that, given the marketing push by Microsoft and IBM, this will happen. But, it's not there yet, and it will take some time yet before SOAP is at the same level of standardization and adoption as WebDAV. > In the history of computing, it has often been the case that a > general purpose solution, bound to a specific application domain, > has delivered a more versatile, powerful, and ultimately longer-lived > solution, than a bespoke specialized language or protocol. So this is why Internet-based services took off using infrastructures such as RPC, ILU, and IIOP, which were also language independent marshalling formats, right? I think it is incorrect to draw any technical lessons from the adoption of SOAP. What makes SOAP different from RPC/IIOP is that Microsoft and IBM both agree on this one. That is, it is the non-technical issue of sponsorship of the standard that far outweighs any technical properties of the solution. Yes, the use of HTTP POST and XML for marshalling undoubtedly helped Microsoft and IBM agree to use SOAP, especially given the mindshare of XML in the 1999-2000 timeframe (I'll note that the same SOAP proposal would have flopped in, say 1995-96, when XML was still tainted by the stigma of SGML). > SOAP-based web service architectures rely on a design-driven process > of data modelling/schemas, selecting an interface to publish, > followed by auto-generation of components for service discovery, > messaging, data (un)marshalling, method dispatching and invocation. Except for service discovery, this is *exactly* what you did using CORBA and RPC. You created a data model, described interfaces, compiled those interfaces into marshalling and unmarshalling stubs, with method dispatching handled automatically. So, why didn't these frameworks take off for Internet use? Claiming that they don't go through firewalls is a red herring -- if a company wants to host a service, or use a service, and have a strong business need to do so, they'll make sure packets can get through. > If WebDAV had a data model, it would be an almost trivial task to > create a web interface definition, auto-generate the communication > components and publish it as an web service ! Again, the marshalling issues were not the heart of the complexity of the WebDAV protocol, and are not the heart of the complexity of WebDAV implementations. > Who can doubt that if WebDAV was starting today, > it would be defined as a SOAP-based service ? Me. I'm going to be very glad that, when administrators tell their firewalls to not admit POST (so someone in the company doesn't set up a rogue Web service and introduce a security hole), WebDAV will not be affected. - Jim
Received on Friday, 25 May 2001 17:25:32 UTC