Web Services: "How we gonna get these here machines to talk to each other"
Web services are certainly the buzz de jour and have had quite a bit of sustaining power over the past couple of years. Many seem to think that this it is all very exciting, whilst newcomers seem very intimidated by it all. This is understandable, given:
While in fact the point of web services is that they are very simple. In order to recognize this, it is important to take a historical perspective of the computer industry, namely “how we gonna get these here machines to talk to each other?”
In the 1970s, the early days of computers, getting two computers to talk to each other was pretty straightforward. You laid a physical wire between the two machines, developed a proprietary protocol, messed around on either end for a while, and presto, the two machines could talk to each other! Needless to say, this was very expensive and cumbersome, and machines generally were only hooked up to each other if it was a very pressing need and they were in close geographic proximity to one another.
Phase 1 lasted for a while, but soon enough people needed a machine to be able to talk to more than a handful of other machines, and the packet network was invented. Third party companies hosted packet switching networks based on protocols like X.25, and if two companies participated in the same network, they could send data to each other. The format of the data was up to those two companies to decide, so there was still a bit of negotiation involved. However, this architecture enabled closed supply chain systems like EDI to evolve.
In the background, while corporations were using private X.25 networks, the Internet evolved amongst government and educational institutions. This was eventually opened up for commercial use and everyone switched to it. At this point, anyone could connect with anyone with a variety of open protocols to choose from, yet there was still no standard for data format.
While this may seem like a panacea, in fact it was still very complicated for divisions within a company, let alone companies, to interact with each other. Consider your average e-commerce site a couple of years ago. In order to to accept credit cards over the web, they needed to sign a deal with a company like CyberCash. This entailed choosing which client API to use (Solaris C++, Windows C++, Java 1.1, Java 1.2, etc.) and sending engineers to a training class. Want to show your physical store locations on a map? Same type of API deal with MapQuest. Someone in marketing wants to start a frequent flyer miles promotion? Netcentives provided this service, but required that you leased a computer, added it to your cluster, and send it data via a proprietary protocol. The leased Netcentives computer would then forward the data on to Netcentives.
Today, all of these contortions sound ridiculous. Yet we forget that this is what the industry was doing only two years ago.
Enter the world of Web services, initially popularized by IBM and Microsoft both agreeing to support SOAP. This was enough to kick-start the industry, since it would bind the Java and .NET worlds.
Web services are inherently pretty simple – self-describing text files are sent around. In the most basic implementations, there are no binary formats, the elements are named and can therefore be in any order, and the data is hierarchical and therefore relatively well organized. When you compare this to the data that was exchanged in Phases 1-3 above, this is really simple. Essentially the McDonald’s of data exchange, just like everyone can buy a Big Mac, everyone can generate or parse a text file and communicate over HTTP.
Definitely web services are not what you would design if you were to create an efficient, technically elegant protocol for machines to communicate with each other (CORBA, DCOM, etc.). But in the real world, especially the world of high power processors sitting around idle most of the time, agreement amongst endpoints is much more important than technical efficiency. So if all everyone can agree on is self-describing text files over HTTP, so be it.
While it seems like web services are a big jumble of standards, most of those emerging standards are domain specific, like how to describe identity provisioning or a manufacturing part. Most of the web service standards are pretty mature:
| | | | | |
| 1 - Dig a Trench | Proprietary | Proprietary | Proprietary | $$$$ |
| 2 - Private Packet Switching (X.25) | Proprietary | Standard | Proprietary | $$$ |
| 3 - Public Packet Switching (TCP/IP) | Standard | Standard | Proprietary | $$ |
| 4 - Web Services | Standard | Standard | Standard | $ |