What really intrigued me was Tim's last sentence:
Speaking for myself, not for Sun, I think that we ought to be pouring resources and investment into tooling and developer support around simple XML/HTTP/REST technologies. You know, the standardized ones that work today.
Tim also mentions Tango, Sun's project to ensure that the Java stack interops with our stack, WCF.
At the end of the day, both of our employers (Sun and Microsoft) need to make their customers happy, and both companies have a diverse customer base with a diverse set of needs.
In that spirit, I thought I'd try to catalog what resources MS has already committed to the XML/HTTP/REST technologies that Tim refers to. This is by no means to imply there isn't more work to do (believe me, there is), but rather to checkpoint where the only vendor I can really influence is at. I've written a
follow up that speculates on where we can and should go in this space.
As fodder for where we should go, let's first look at where we're at:
HTTP (so far)
We've done a fair amount of work building and using general HTTP infrastructure that doesn't depend on nor mandate XML, SOAP, WS-*, or REST.
- We have several programmable HTTP client stacks:
- WinInet for unmanaged code.
- WinHTTP, also for unmanaged code but built to handle server-side use.
- XmlHttpRequest, which makes the former two stacks available to scripters. Apparently the folks at Google really like this one.
- System.Net for managed code that runs either on the client or the server.
- We built HTTP.SYS, which put a server-side HTTP protocol stack into the base OS, including kernel-mode URI-based dispatch to allow multiple processes to use a common TCP port (typically but not always 80).
- We built IIS, a programmable HTTP server on top of HTTP.SYS that is used by a lot of people and Microsoft products.
- We built ASP.NET, which allows you to write HTTP handlers by implementing a two-method interface (IHttpHandler) or using a templatized ASPX markup file.
- We built ASMX, which (independent from its SOAP support) allows you to declaratively map incoming HTTP requests to methods, including mapping URI components to method parameters.
- We built WCF (Indigo), which generalized the ASMX model and lets you do pretty much anything, including doing both straight HTTP and "dual-mode" HTTP that bonds two HTTP channels to allow arbitrary duplex messaging.
XML (so far)
We've also done a fair amount of work building and using general XML infrastructure that doesn't depend nor mandate SOAP or WS-*, although it does take advantage of our HTTP investments where appropriate.
-
We built MSXML, an unmanaged XML stack that supports XML 1.0, XML Schema, XPath 1.0, XSLT 1.0, and COM-specific implementations of SAX and DOM.
-
We built System.Xml, a managed XML stack that supports XML 1.0, XML Schema, XPath 1.0, XSLT 1.0, and a .NET-specific implementation of DOM . Rather than do SAX, we introduced a new push/pull model that the Java folks have since embraced.
-
We're building deep support for XML in our languages, both in terms of LINQ and VB9's upcoming XML literal support.
- We built BizTalk Server, which is a giant XML transformation engine.
-
We added native support for XML 1.0, XML Schema, and XQuery to SQL Server to help people store and manipulate XML.
-
We added support for XML 1.0 and XSLT to Internet Explorer.
-
We built Infopath, an end-user tool that makes it pretty easy to create UI over XML with or without an XSD (it can also use SOAP and WSDL if you want it to). The blog editor I'm using right now is an Infopath form.
-
We added XML data binding to our UI frameworks so our developer users could make XML pretty for people to look at.
-
We (finally) got a great textual XML editing experience in Visual Studio, including support for snippets and Intellisense.
-
The Visual Studio debugger now supports XSLT debugging so that XSLT users no longer need to channel the inner Prolog programmer to figure out why their XSLTs don't work.
-
The Office team did a significant amount of work in Word and Excel to both make their own formats accessible as schematized XML data as well as to embrace the schemas that users already have.
-
Most if not all Microsoft web properties expose (and sometimes consume) XML information, often in the form of RSS.
REST (so far)
This one is a bit tougher to catalog, because REST is a fairly subjective (and sometimes divisive) term. To get a more accurate picture of what we've done so far, I'll break this category in two: Lo-Rest, which is the use of HTTP GET (or equiv) for information retrieval/query, and Hi-Rest, which is characterized by the use of HTTP PUT and DELETE (or equiv) for doing update.
Hi-Rest:
- Our HTTP stacks support all of the HTTP methods, not just GET and POST.
- IIS supports WebDAV (arguably the poster boy application of Hi-Rest).
- Windows Explorer supports WebDAV.
- Most Office client apps support WebDAV.
- Sharepoint supports WebDAV.
- Exchange supports WebDAV.
Lo-Rest:
-
Our HTTP stacks support HTTP GET, including support for resource caching, content negotiation, etc.
-
Our XML stacks integrate with our HTTP stacks to allow you to consume XML using HTTP GET.
-
We built Internet Explorer, a generic tool that lets users make HTTP GET requests.
-
Most if not all Office apps let you insert URI and navigate/retrieve using HTTP GET.
-
SQL Server lets you map HTTP GET requests to database queries.
-
All Microsoft web properties (including MSN, MSDN, and Live) are built on HTTP GET (even our APIs have Lo-Restful URLs thanks to Tim Ewald and friends).
-
With the exception of our DAV support (listed above), most Microsoft technologies that update stores over HTTP tunnel server-specific update requests through HTTP INVOKEPOST the way the rest of the apps on the web do. Hence the need to distinguish between Hi-Rest and Lo-Rest
Posted
Mar 18 2006, 03:24 PM
by
don-box