Web services: what you need to know; not just the "next new thing," Web services actually work. (Technology).

In the classic scene from the movie The Graduate, the recent college grad played by Dustin Hoffman is portentously offered one word of business advice: "Plastics." This year, the newly diploma'ed are hearing two words: "Web services."

Indisputably, the technology buzz term of the moment, Web services have an advantage over earlier "breakthrough" Web technologies, many of which soared and crashed spectacularly within the space of three or four issues of Wired: Web services actually address users' needs.

DEFINING WEB SERVICES

The touters of Web services define the term in two ways:

1. A set of technology standards for communicating, exchanging data, and coordinating tasks over the Internet.

2. The software applications that are built with these standards.

The idea of services on the Internet is not new. Most of us have used a book-buying service like Amazon.com, a travel service like Expedia.com, or one of the many financial services that provide instant stock quotes. These services require application-to-human interaction: on one side of the conversation sirs a person, on the other side a computer. Web services, by contrast, employ application-to-application interaction -- computer programs interacting with other computer programs, no humans involved.

Consider Expedia and Amazon. You can use Expedia to buy a plane ticket to Paris, and then navigate over to Amazon and buy a guidebook to Paris art galleries. It would be more convenient to buy a ticket and merely click a button to have Amazon send you the guidebook. This could occur if the Expedia software communicated with Amazon's software -- if there was application integration between the two. Until now, this required customized code.

But what if applications vendors could agree on a standard for inter-application communication? Then, any compliant application could go out on the Internet and, to continue our example, request a purchase from a book service or a travel service. The same code that was written to submit a request to Amazon would work with Barnes & Noble or Powell's or any bookseller with a Web services presence.

Take this a bit further, and suppose there were places on the Internet, so-called registries, where all service providers, such as booksellers, could list themselves. Consumer service applications looking for booksellers would browse a registry to find the Internet addresses of available booksellers, then go to each of them and search for a particular book, or connect to all of the services, request pricing, and buy from the service that offered the best terms.

This is the vision for Web services.

FROM POINT A TO POINT "E"

In the beginning, the Internet was primarily the province of academic and scientific users who may even have enjoyed the arcane commands that navigating the Internet's labyrinths required. Later, normally contentious companies managed to agree on a standard for Hypertext Markup Language (HTML), and the user-friendly graphical interface of the World Wide Web opened the Internet up to regular folks. Sometime in the late 1990s, the needs of individual users stopped directing the Internet's evolution, for the most part, and businesses took their place. E-commerce flourished and merchants discovered in the Internet a new medium for marketing, distributing to, and servicing customers.

Manufacturers that had experimented with direct connections to their critical suppliers began switching their point-to-point connections to less expensive Internet-based communications. As more businesses came onto the Internet, business-to-business communication became increasingly significant. Soon, companies needed better support for more complex transactions. In desperation, some turned to traditional application integration, crafting custom code that would allow them to talk to one supplier. But what they really needed was a structure that would enable any business application to communicate with any other business application.

At the same time, after years of ecstatic expansion, traditional information technology departments found themselves entangled in an unsupportable jumble of disparate and antagonistic systems. Making these systems play together peacefully involved throwing large bags of money at custom software projects. At the outset, these projects always look simple; in the end, they always run over budget and behind schedule -- and they always underperform.

Beleaguered IT managers look at Web services and see they not only can address the issue of external integration, but also herd together all of those misbehaving internal applications.

SETTING STANDARDS

Web services attempt to define a set of standards that cover all of the components necessary to implement program-to-program communication, whether it occurs inside or outside the corporate firewall. These standards encompass a definition for the language used in communication, a grammar for this language, a format for the messages sent between applications, and the structure for searchable directories of information about these applications -- an ambitious agenda.

Specifications need universal support to become a standard. In a rare show of cooperation, IBM, Microsoft, and Sun have actually laid down their differences for the moment to join with the World Wide Web Consortium (W3C) to push for a common Web services specification. Each company has introduced development environments that support Web services. And although they each may trumpet the superiority of their unique tools, the applications produced with these tools are capable of working together.

This application integration solution has also attracted the attention of major business suite providers; such as SAP and Oracle, which are featuring Web services in the next generation of products to enable integration between products and allow customers easier access to data within applications. For customers, this promises to return us to the idea of "best of breed" -- choosing the best application for each task and orchestrating their interaction. Software companies have made this almost impossible over the past few years by providing systems with modules so tightly coupled that outside integration has become prohibitively complex and expensive.

Just as important, Web services do not require companies to trash all of their existing, or legacy, software. These applications can participate in Web services through a "wrapper" -- a piece of code that translates between the Web services interface and the legacy applications interface.

Still skeptical about Web services? Remember that guy in The Graduate with his plastics? He was right.

RELATED ARTICLE: WEB SERVICES BUILDING BLOCKS

No new technology is complete without its own set of sharp acronyms, and Web services is no exception. The big four to know are:

XML: Extensible Markup Language is the fundamental element of Web services. It is an evolution of HTML (Hypertext Markup Language), the stuff that the Web is built from. HTML was designed to use a plain text document to describe how data should be organized on the computer screen; thus, it is mostly concerned with data presentation. XML extends this idea to data representation and meaning -- XML documents not only contain the data itself, but also information that details the meaning of the data. A very brief example should illuminate this rather abstract description.

Consider an XML document with this fragment: <OfficePhone> 9082538600 </OfficePhone>. First thing to notice is that this is readable -- you can make a pretty good guess as to the meaning just by looking at it. This fragment contains both data ("9082538600") and information about what the data means ("<OfficePhone>"). The point here is that what makes Web services work is the simplicity and universality that XML offers. These characteristics have made XML the lingua franca of Web services. All Web services communicate across the Internet by sending and receiving messages written in XML.

SOAP: Simple Object Access Protocol describes the structure of the messages sent between applications and written in XML. A message, again just a plain text document, consists of a SOAP "envelope" that has two components: an optional header and a body. The header contains information on things like routing, sender identity (authentication), and other processing-specific info. At one end, an application requesting a service (the service "consumer") constructs and sends this SOAP envelope to the application providing the service (the service "provider"). The provider receives the message, opens the envelope, and processes the data according to the instructions received in the header. The provider packages its response in another SOAP envelope and sends this back to the consumer.

UDDI: Universal Description Discovery and Integration is a specification for a distributed registry of Web services. It lays out the structure of an Internet-based Yellow Pages where an application can find other service providers. In our example with Expedia and Amazon (see story), the travel service goes to a UDDI registry to look up bookseller services, or more specifically, it could look up booksellers that specialize in travel books.

WSDL: (say "whiz-dill") Web Services Description Language, again based on XML, provides a service consumer with all of the information it needs to interact with a service provider. Once a consumer has located a service on an UDDI registry, the registry sends the consumer to a WSDL document prepared by the service provider. Equipped with this document, the consumer now has everything it needs to communicate with new and previously unknown application.

JOHN SEELY BROWN: UNDERSTANDING THE "SOCIAL LIFE" OF INFORMATION

As chief scientist of Xerox and former director of its Palo Alto Research Center (PARC), John Seely Brown was responsible for guiding one of the most famous technology think tanks in the world and leading one of the most celebrated and far-ranging corporate research efforts.

During his 23 years at PARC, the Center helped shape the direction of the digital revolution by inventing the graphic user interface, the mouse, the first real personal computer, and a host of other breakthrough technologies. When asked about his own most significant contributions while at PARC, JSB (as he prefers to be called) points to two innovations: defining and disseminating an understanding of the "social life" of information, and his work on systemic MEMS, microelectromechanical systems.

Part scientist, part artist, and part philosopher, Brown combines an incredibly fertile technical imagination with a broad view of the human contexts in which technologies operate. In his latest book, The Social Life of In formation (co-authored with Paul Duguid, Harvard Business School Press, 2000), which reveals Brown the scientist-philosopher, he discusses the dynamics of information and how information takes on meaning from its social contexts.

MEMS springs from Brown the scientist-artist. Imagine materials that are partly computational and partly structural, like clothing that monitors blood pressure, or structural beams that can sense and compensate for buckling motions, or reusable electronic printing paper. Brown calls this "smart stuff" and believes the field has the growth potential to match personal computing itself.

At Xerox, Brown was deeply involved in corporate strategy and in expanding the role of corporate research to include such topics as organizational learning, ethnographies of the workplace, complex adaptive systems, and techniques for unfreezing the corporate mind. His personal research interests include digital culture, ubiquitous computing, and user-centering design. He's focused especially on human learning and the creation of knowledge ecologies for supporting radical innovation.

In addition to Brown's newest book, he authored Seeing Differently: Insights on Innovation (Harvard Business Review Books, 1997).

Kyle Roth is chief information officer of W. Colston Leigh Inc., Advisory Services LLC. He also has consulted and spoken on technology issues, founded two technology companies, developed software, and co-authored a book and several articles on computer topics. He can be reached at [e-mail]