Web services aren’t the answer, but you should use them anyway. I’ll tell you why.
Let me start with a quick definition of web services. When you use web services, you allow software applications to communicate with each other using three technologies: HTTP, XML, and SOAP. HTTP is the primary protocol used for data transmission over the Internet. Using HTTP means that applications can communicate with each other if they’re in different parts of a company, in different companies, and even in different countries. HTTP is allowed through most firewalls because it’s the same protocol used by web browsers. Web services use HTTP because it’s the universal common denominator for communicating across the Internet.
XML is a data format that includes the definition of the data along with the data itself. Sending data in XML is like sending a book with a complete dictionary of the language as well a classroom guide on how to read it. Using XML for data transmission means that the sending and receiving applications don’t have to agree in advance on how to store the data.
SOAP (Simple Object Access Protocol) is a method for packaging the XML data into a request that a receiving application can understand, and to which a receiving application can respond. It’s like a work order that anyone can interpret: it says “I want you to do this, and when you’re done, here’s what I want the result to look like.”
Combine HTTP, XML and SOAP into “web services” and you have a way for any two applications to communicate with very little prior work. The approach even works between applications which use entirely different architectures, like Java-based systems and Microsoft .NET-based systems. That’s why it has been hailed in the technology press in terms that make it sound like the Holy Grail of IT.
While web services are undoubtedly a good idea, they are not nearly the be all and end all that the press has described them to be. As a child, did you ever have one of those sets of boxes where you open a box to find another box, and then open the second box to find another, etc., etc., until you finally end up with a very small interior box? All Web Services do is open up another box, but the next box down in the layers of boxes is much more challenging.
Web services make it easier for two applications to communicate with one another. But opening up most applications to outside access makes it painfully obvious just how confusing and proprietary those applications are. Most application-specific data requires an understanding of the application software in order to interpret it. In spite of industry adoption of relational databases as a standard, many databases are far from normalized. And what’s worse, the accuracy and validity of data in most databases is extremely uneven: some data is highly accurate, but other data is hardly verified at all, much less kept up to date.
Using web services to arbitrarily connect two applications is a little like buying a car from an ad in the newspaper without seeing the car in advance and without having anyone test the car. You might get something worthwhile, but it’s hard to know.
After you open up the web services box, the next “box within a box” is the need for the standardization of data to make it more understandable and more reliable. Maybe we should even “grade” our data elements so that someone reading the data can know what data they can trust and what data to ignore. Until we solve this data problem, web services aren’t the answer; they just make it easier to communicate with another application that isn’t very trustworthy.
Should you use web services? They definitely make inter-application communication easier, particularly across diverse architectural platforms. But they’re also valuable because they call attention to the data validity problems we all face. So go ahead and use web services. After all, you never would have found the second box if you hadn’t opened up the first one.