Marshaling data to unlike platforms has always been a problem. In the past, vendors could not even agree on a marshaling format, let alone a common type system. Microsoft used COM (component object model) for its distributed object model and marshaling format; it did not support CORBA (common object request broker architecture). Processor differences such as endianness (byte ordering), floating-point representation, and character set were considered in both these models. Marshaling between systems required a "readermake right" approachthat is, the receiver of a message had to determine the format and convert it to something understandable to his processor. In addition, the distributed programming models were plagued by the requirement to have a specific naming model or security system. As an example, porting COM to the Solaris platform required installing the equivalent of a Windows Registry and an NTLM security service. But the biggest problems were network protocol and access to specific ports on network servers. COM not only used a proprietary protocol and network ports when run over TCP/IP, but also required opening port 135 for the naming service to operate correctlysomething that few systems administrators would permit for security reasons. By contrast, most systems administrators gladly opened port 80 and allowed the HTTP protocol, even setting up special proxy servers rather than deny internal users access to the World Wide Web. Systems such as DCOM over HTTP and Java RMI over HTTP were the first steps away from a proprietary distributed programming system.

Vendors such as Microsoft, IBM, Oracle, and Sun are moving toward supporting distributed computing over HTTP using a framing protocol known as SOAP and using XML as a marshaling format. SOAP itself uses XML to frame XML-based payloads; elements and attributes used in SOAP are defined in two XSD schemas. SOAP also defines a portable way of representing parameters to remote procedure calls (RPCs), but since the completion and adaptation of XML schemas, a schema-centric format has been used. Using XML as a marshaling format, framed by SOAP, possibly over HTTP, is known as Web Services.

The popularity of XML and Web Services, like the popularity of SQL, is fairly easy to explain. Managers of computer systems have learned over time to shy away from proprietary solutions, mostly because companies often change hardware and operating system (and other) software over time. In addition, a company may have to communicate with other companies that use an unlike architecture. Therefore, protocols like HTTP; formats like XML and CSV (comma-separated value) files; and languages like SQL, XPath, XSLT, and XQuery tend to be used for a single reason: They are available on every hardware and software platform.

Consider as an example the RDS (remote data services) architecture used by Microsoft to marshal resultsets (known as recordsets) over HTTP in a compact binary format, as opposed to XML, a rather verbose text-based format. Because Microsoft invented the RDS marshaling format (known as Advanced Data Tablegrams, or ADTG), other vendors (such as Netscape) refused to support it. This is known as NIH (not invented here) syndrome. On the other hand, visit any large software or hardware manufacturer on the planet, and ask, "Who invented XML?" The answer is always the same: "We did." Because XML (or SQL, to expand the analogy) cannot possibly be perceived as "a Microsoft thing" or "an Oracle thing," support is almost universal.

SQL Server 2005 supports creating Web Services and storing data to be used in Web Services at a few different levels. The XML data type and XQuery support mentioned previously are a good start. Data can be stored in XML format inside SQL Server and used directly with XQuery to produce or consume Web Services. With the addition of direct support in SQL Server for HTTP, we could think of SQL Server 2005 as a "Web Services server." This reduces the three-tier architecture usually required to support Web Services (database, middle tier, and client) to a two-tier architecture, with stored procedures or XQuery/XSLT programs being used as a middle tier.