"Web Services" Building Blocks
To continue the discussion of Web services that we began with the last tip, I want to discuss the building blocks of Web services. And to start that discussion, I'd like to quote from my last tip, wherein I did a good enough job of defining the phenomenon that I'd rather quote myself than restate it in other terms:
"In a nutshell, a Web service is a special kind of application where some kind of Web-enabled user agent -- a browser is a good example, but other software for cell phones, PDAs, embedded systems, and so forth can also qualify -- enables a user anywhere on the Internet to interact with a meaningful combination of data and processing abilities to perform useful work. In current practice, this often means performing financial or commercial transactions (where data about funds and transfers is crucial, as are secure transaction processing services), or interacting with various databases (such as airline or other travel reservations, reviewing account histories, and so forth). In database-speak, however, this usually means that individuals are limited to specific "user views" of much larger collections of data, so that they can interact with information that's relevant to them, but are kept away from the vast majority of such data that has no bearing on their account, history, or particular needs."
Another take on Web services is that they provide a way to run special purpose applications or to access otherwise restricted source of information from any suitably-equipped device that can access the Internet. Hence, all the hoopla from Microsoft about its Hailstorm initiative which offers a single logon credential for all kinds of Web sites (Passport) plus access to calendar, e-mail, and journaling information for individuals, and even for groups of users who may need to plan meetings or whatnot. The power of this idea is that it liberates users from their needs to access a specific server or a specific desktop to get the services and grab the data they need. In fact, it lets them access the same set of data and services from a computer, a PDA, a cell-phone, and from other future devices with Internet access and, no doubt, magical capabilities.
Under the hood, XML is rampant and absolutely essential to help make Web services real. In particular, XML's self-describing capabilities (documents and services can carry metadata that describes them completely and fully as part of the same text stream that conveys content, binary code, or other payloads) and its platform neutrality (XML doesn't care what kind of user agent examines its payloads and metadata; such user agents need merely be prepared to parse XML text, and act on what they find therein to do their jobs).
Thus, it should come as no surprise that a number of important XML initiatives are helping to drive how Web services are defined and advertised, how user agents communicate with servers and vice-versa, and how data is packaged for exchange between consenting parties to such services. A fascinating set of XML standards defines an environment in which Web services can operate, including (but not limited to) the following mouthfuls of alphabet soup:
- WSDL, or Web Services Definition Language. WSDL provides a mechanism whereby Web Services can describe themselves, what kinds of services and data they have to offer, what kinds of message formats they use, and how to access them. This building block is how services make themselves available to clients, by describing what they are, how they're laid out, and how they may be accessed. In other words, WDSL permits network services to describe themselves as being either document or procedure based, so they can be used to access and read specific information, or accessed to obtain just about any kind of service you can imagine. If you want more information on WSDL, send me an e-mail at email@example.com, and I'll be glad to send you some. For a great set of WSDL pointers, please visit http://xml.coverpages.org/wsdl.html.
- UDDI, or Universal Description, Discovery and Integration. As WSDL allows services to advertise themselves individually, UDDI provides a "directory service" for services and other information available on the Web. Think of this building block as the "yellow pages" or "white pages" for Web services, depending on whether you look for them by category (yellow) or by name (white). The "brand" of directory you use corresponds to the particular UDDI server (or servers) with which you interact to perform discovery and make service connections. For the lowdown on UDDI, please visit both http://www.uddi.org and http://xml.coverpages.org/uddi.html.
- SOAP, or Simple Object Access Protocol. SOAP is an abstract messaging technique that permits creation of self-describing, XML-based messages chock full of metadata and payloads relevant for delivery or access to all kinds of information and services. Think of SOAP as the building block for Web services that provides a generic way to transport requests for services from service consumers to service providers, and to transport responses to such requests from service providers to service consumers. Although IBM, Sun Microsystems, and Microsoft don't currently entirely agree on the exact layouts, formats, and capabilities of what SOAP transports for their differing notions of Web services, all are agreed that SOAP is the right technology to transport the messages that make Web services work. For a killer list of SOAP references, please visit http://www.lanw.com/books/javasoap/soapref.htm and http://xml.coverpages.org/soap.html.
When these building blocks are combined, you have a way to advertise services for service providers, a way to describe, discover, and connect to services for service consumers, and a way to move requests and data between consumers and providers (and vice-versa, of course) that ties the whole shebang together. Notice that XML is integral to every aspect of this operation, and hence to the realization of a vision of Web services far beyond what's available on the Web today. "What's that?" you ask. Think Application Service Providers (ASPs), any kind of online subscription service (anti-virus, security, Windows Update, etc.), and any kind of online service monitoring or management you can outsource via the Internet (security management, performance and availability monitoring, backup, and much, much more). It's already a big world, and these building blocks will help not just to rationalize it, but to make it much bigger than it is at present. All I can say in closing is "Buckle your seat belts. The fun's about to start."
Have questions, comments, or feedback about this or other XML-related topics? Please e-mail me at firstname.lastname@example.org; I'm always glad to hear from my readers.
Ed Tittel is a principal at LANWrights, Inc., a wholly owned subsidiary of LeapIt.com. LANWrights offers training, writing, and consulting services on Internet, networking, and Web topics (including XML and XHTML), plus various IT certifications (Microsoft, Sun/Java, and Prosoft/CIW).