Service With a Smile
With all the hype about Web services, you'd think it would solve every ill known to IT kind. To the World Wide Web Consortium, or W3C, the defining body for all things Web, the term "Web services" refers to any of the various schemes for allowing applications to communicate with one another over the Internet to share information and support business processes. But it's the very broadness of that definition that contributes to the confusion.
Web services are really modular components, basic building blocks that can be assembled into larger applications. They can be as small as a single function, such as asking a legacy system about the exchange rate between two currencies, or as large and complex as initiating a series of currency exchanges using multiple banking systems. And these services can be run by everything from a single user with a Web browser to a massive enterprise application.
But that's nothing more than middleware, you say. Actually, middleware is responsible for finding and supplying the necessary data wherever it's located; Web services are responsible for processing the data. Think of Web services as a layer of standards slathered over middleware and Web-based applications that ensure information will be transmitted and processed in consistent ways.
To build a basic Web service, you need HTTP, the HyperText Transfer Protocol; XML, the Extensible Markup Language; and SOAP, the Simple Object Access Protocol. XML defines the standard format for the data, and can even define the business processes that should be used with the data. HTTP lets you send and receive data freely through the corporate firewall, without needing to punch a new security hole in the firewall. SOAP lets applications, either on your own system inside the firewall or on another company's, "invoke," or execute, the Web service.
But Web services can start to get complicated when you want to do more than transmit basic information. If you want to make it easy for your applications to find unfamiliar Web services somewhere on the Net so the applications can run those Web services, you'll need some kind of white or yellow pages: That's the Universal Description, Discovery and Integration service, UDDI. And if you want your applications to be able to find information about a Web service, such as how it should be used, you need WSDL, the Web Services Description Language.
Here's another way of looking at it. Think of how you might go about finding a plumber when you're living in a foreign country. If you already know the plumber and the language he speaks, you'd simply dial him up (HTTP). But if you didn't speak the same language, you'd need a translator who could speak both your language and the plumber's, and translate between them (XML). Now suppose you needed the plumber on a regular basis; you'd want to be able to put his number on speed dial, and possibly even have a recorded message saying what you wanted him to do automatically (SOAP). But what if you didn't know how to reach the plumber? You'd need a good phone book (UDDI). Now suppose you regularly required different kinds of laborers on a regular basis, but needed to know ahead of time what their qualifications were, when they were available, and so on; you'd need a standard way of describing, in a manner both you and the workers understood, what they could do (WSDL).
Most users today are focusing their Web services efforts inside the firewall, on relatively straightforward problems such as linking two legacy systems to a new business process such as allowing visitors to a corporate portal to check their benefit balances. The best way to begin with Web services is to start off with small pilot programs using the basic XML and SOAP protocols, then continually adapt those basic applications until they're performing as needed.