From Subroutines toWeb Services AnEvolutionary View-Beyond client/server computing: The next generation of life on the

In many respects, Web services are nothing new. They are just a natural evolution of an approach to building systems that dates back 40 years. On the other hand, they hold the promise of truly transforming computing in the same way that client/server computing did over the past 15 years. This article tries to address the question, "What's all the excitement about?"

What is a Service?
Let's begin by defining the term "service." A service is a reusable piece of self-contained logic that knows how to do a task, but does not know why it is being called upon. A water fountain is a good example of a service: it is quite skilled at providing drinking water, but it has no idea that its client is thirsty.

Software developers long ago recognized the need for services. Without reusable and self-contained programming logic, they had to write the same code multiple times, and then maintain each of these multiple instances. In the early days of computing, when systems were limited to a single host platform, reusable services were called subroutines or external program calls. Regardless of the name, though, these were early versions of services.

As computing spread across multiple computers, the need arose for reusable services that could operate across machine boundaries. An entire industry evolved around this need, which became known as client/server (i.e.,client/service) computing. Fortunes were made by companies that built tools to help programmers build systems that interoperated across machine boundaries. Note that the concept of a service had not changed at all. Only the underlying environment had changed - transitioning from single to multiple machines.

Web Services
The evolving maturity of the Web takes the notion of a service to yet another level. In the world of client/server computing, service invocations are typically made within a single, private network, or at least within a pre-established network of partners. In addition, client/server components are generally "tightly coupled," which means that the client needs to have registered to use the service in advance. (This is analogous to a water fountain working for you only if you have registered in advance for its use.)

Web services, on the other hand, are typically invoked across the Internet or an intranet, and are always loosely coupled. In other words, there is no technical requirement for a Web service to know in advance which clients will access it. Indeed, new clients can "add themselves" simply by using the correct calling parameters and demonstrating proper authorization.

Since Web services can be made publicly available so easily, they promise to bring new possibilities to the way organizations work with each other, transforming B2B commerce over the next few years. This is the most common view of Web services, and is what most of the excitement is about.

Interestingly, though, Web services are emerging even more quickly as an integration mechanism within individual organizations for Application-to-Application communications (A2A). The loosely coupled architecture of Web services delivers a flexible, extensible architecture for companies trying to integrate disparate systems. Important companies in this space include webMethods, Tibco Software, SeeBeyond Technology, and Vitria Technology.

For externally-accessed Web services, the idea is that a service can be placed onto the Web, where any organization's applications can find it and use it easily - much like a drinking fountain. Once again, there has been no change to the concept of a service. Rather, the underlying environment in which services operate has changed fundamentally. And these changes in turn fundamentally transform the way we do business.

Some Examples
Let's take a look at how Web services are already beginning to change the face of computing to get a taste of this new technology's power:

An early example of Web services is Dun & Bradstreet's Global Access Toolkit (reviewed in WSJ, Vol. 1, issue 1). D&B provides creditworthiness and other information about businesses worldwide. Last year they implemented a Web services system (Global Access) that allows authorized customers to access D&B data across the Internet as if that data was local to their own system. For example, a commercial bank's loan application system might call out to Global Access with a client company's key identification information (name, address, etc.) while the rest of the loan application is still being entered by a user. Within seconds, the loan system receives D&B's credit rating, enabling a credit decision to be rendered even before the application is completed.

A much more broad-reaching Web services example is Microsoft's .NET My Services formerly code-named Hailstorm. Based on Microsoft's .NET platform, My Services promises to put many individual services into Web service form, including management systems for contact lists, calendars, inboxes (both e-mail and voice mail), money, and far more. Web services are so fundamental to Microsoft's strategy that they openly speak about redefining the company over the next five years as a provider of Internet software-based services, rather than a software producer.

In truth, nearly every developer-centric software company has jumped onto the Web services bandwagon. Major platforms include Microsoft's NET, Sun's Open Net Environment (Sun ONE), IBM's WebSphere, BEA's WebLogic, Cape Clear, Iona, SilverStream, OASIS, Apache, Borland, and many others.

Buzzwords - Four Key Technologies
Now that we understand the conceptual definition of a Web service, I'll mention the key underlying technology standards upon which Web services are based. The technologies listed below reflect current thinking, and are widely supported. Bear in mind, however, that other variants exist; this is a fast-changing world. That said, following are the key technologies behind Web services today:

• XML (eXtensible Markup Language): An extension to the HTML language that allows data definitions to be transmitted along with the data itself. Prior to XML's development, it was difficult to write software that would interpret the contents of a Web page because the pages simply contained text and graphics. XML allows the individual fields in a page to be described, so that a piece of software can understand them. XML is by far the most universally accepted standard for Web service enablement.
• SOAP (Simple Object Access Protocol): A standardized way of using the XML language to call a Web service. Just as the English language needs grammatical rules to be understood, SOAP is a "grammar" that uses XML to call a Web service.
• UDDI (Universal Description, Discovery, and Integration): A central directory of Web services where services can be registered, much like the Yellow Pages. This permits potential customers (i.e., automated programs) to browse available services, and identify the location of these services and what information they require. For example, a system looking to purchase 100 tons of steel can browse a UDDI directory, find the services that vend steel, and submit price queries instantly and automatically.
• WSDL (Web Services Description Language): A standardized way in which the interfaces (i.e., inputs and outputs) of Web services are described. A WSDL file is generally part of a UDDI directory entry, and thus enables the client software to determine how to use the published service.

Key Issues
The power of Web services is no longer in question. Over the next few years, they will fundamentally change the way most companies build and use software. Of course, as with any important new technology, Web services also raise new challenges. I will touch on just a couple in the following paragraphs. Each of these items could easily fill a complete introductory article in its own right, but it is worthwhile to at least mention them here.

• Security: When we open our services to the world, all sorts of security issues arise. Some obvious examples include authentication, authorization, and bill/payment processing. Every situation is different, but all require a security analysis.
• Discovery: A Yellow Pages for Web services is very powerful, but also complex. There is a large difference between publishing phone numbers categorized by business and publishing the very mechanisms for doing business with companies. Standards are not yet firm in this area, and they have a long way to go before reaching universal acceptance. In addition, there is a real question as to how popular UDDI or other methods will be beyond a certain class of universal services.

Conclusions
My hope is that this article has communicated two key messages that might at first seem contradictory. First, Web services are nothing new; they are simply the next step in service-oriented computing, which has been evolving for more than 30 years. There is no great mystery here, and they are not the solution to world hunger.

The second key point is that Web services change everything. They provide the mechanisms to automate the Web, and to bring enormous efficiencies to the marketplace. All technology leaders should begin now to look for the B2B initiatives within their organizations that can benefit from this key technology. Web services may become the most significant new technology category for many companies during the next several years.

Many of us are excited about Web services. But be cautious: they do not solve all of your problems. Do not let your over-enthusiastic developers make them the answer to all things IT. If it doesn't make sense to you, don't do it. Also, remember that Web services are in their infancy and it would be unwise to over-commit. Put a toe in the water. Get some experience. Experiment. Don't lock into a single vendor until you understand the domain.