The War is Over (WS-* vs. POX/HTTP)
For a few years now, we have seen two camps warring over the future of the Internet. On one side, we have the people who believe that WS-* specifications such as SOAP and WS-Security will eventually dominate. And on the other, we have people who believe that HTTP with plain old XML (POX) will outlast the new contender.
I am announcing that the war is now over, whether the participants realize it yet or not. Niether side won; but they have established clear territory for themselves and will soon be giving up on taking over one another’s territory. Here is where I think they will be when the dust settles:
- WS-*: The WS-* stack is about deep enterprise integration. It tackles problems that enterprise architects care about. It requires that integration endpoints support a common set of protocols; a requirement that becomes increasingly complex as the size of the stack being used increases. The number ofdevelopment platforms and client platforms which support SOAP is significantly smaller than the number which support XML. For each additional layer of the WS-* stack, the reach gets smaller. So the stack is best suited for scenarios where you have a high degree of control over the integration endpoints, and where you care about all of the additional CORBA-like features you get. WS-* is Biztalk, WebSphere, etc.
- POX/HTTP: HTTP + POX is about ?reach integration?. Pretty much every developer in the world can work with XML and HTTP. Nearly every client has support. You need almost no control over a partner’s endpont to allow him to integrate with you using HTTP redirects, querystring parameters, and form fields. This is why reach scenarios, where you want to integrate with thousands of partners, use HTTP or POX over HTTP. The WS-* advocates have argued that this sort of lightweight integration is insecure, but you need only realize that sites like PayPal, BitPass, and Passport use HTTP redirect with no WS-* for reach integration scenarios, and it works fine. POX/HTTP is MSN, Google, Yahoo.
Supposing I’m right, I see a couple of obvious implications of this:
- Complimentary: An app which exposes querystring APIs to mass end-users may use SOAP under the covers to integrate with other systems. In fact, I see a lot of this ?under the covers? use of SOAP.
- Microsoft Can’t Ignore Either: Microsoft needs to support developers using both models. Enterprise revenue is great, but so is reach web integration. We need thousands of medium-cost integrators and millions of low-cost integrators. For example, SQL Server is definitely an ?enterprise? product, and has several ways to interact with the server using WS-*. But one of the first features out of our SQL Server’s XML team was ?XML Views?, which expose a relational database as a virtual XML document. Everything in the database becomes an accessible URL, and developers of HTTP/POX solutions can interact with the database without writing any code (beyond some JavaScript, maybe). Enterprises who buy SQL Server can count on good support for depth integration, but they also have a pretty simple way to extend their investment to ?reach? partners when necessary. It would have been a huge mistake to de-emphasize either model in preference of the other.
- Tools Support: One of the recurring themes of Hailstorm was that ?mom n pop? would be able to use VB to integrate their website with services such as an authentication system, payment gateway, directory, or content download metering service. However, we were aiming too low on usability. You can integrate with PayPal or BitPass by cutting and pasting some JavaScript — installing and running Visual Studio is much harder. Look at del.icio.us and flickr bookmarklets, and ask yourself if it would be easier for mom-n-pop to use Visual Studio instead. Jon Udell has created a virtual bestiary of evidence that you can do amazingly simple integration of web services using HTTP and POX without needing Visual Studio or WS-*. Furthermore, if I am correct that WS-* is best for depth integration, then you don’t need cut-n-paste simplicity for WS-*. You need tools that target enterprise architects (and mort), not mom-n-pop. In fact, what you really need to be worrying about is making it easy for the Visual Studio developer to create apps that mom-n-pop can integrate with. If I write a big chunk of code and you tell me that only other enterprise architects can integrate with it, I might ask why. I might ask, ?why is it so easy to integrate with Flickr; what development suite did they use??