Enterprise Software

What are Web services anyway?

The amorphous term "Web services" has a lot of people confused. What exactly does it mean? Here's one explanation that should help you sort it out and decide how to put Web services to use for your organization.

By David Berlind

ZDNet Tech Update contributing editor Eric Knorr's story on the state-of-the-state of Web Services is a must-read. If you haven't figured out why Web services might be for you, Knorr's column will certainly whet your appetite. However, one thing Knorr doesn't tell us is: What are Web services? Okay, maybe you know the answer. But apparently, your peers do not.

At last fall's Gartner Symposium, just before an icebreaker session on Web services, I asked several attendees—presumably C-level technology executives—if they could give me a definition of Web services. Their answers fell into one of three camps:
  • Web hosting
  • Internet service provider
  • Application service provider

Essentially, no one really knew. Before the session's end, over half the attendees had left because they were expecting a discussion about something else. Judging by the e-mail I receive almost daily, nearly everyone is still confused about what Web services are.

"Web services" is nothing more than a fancy moniker for "big honking application programming interface (API)." Consider what xDBC (replace the x with O for "Open" or J for "Java") and structured query language (SQL) did for databases. They made it possible for just about any software—reporting tools, spreadsheets, even word processors—to extract query results from any database. Any software. Any database.

Now, in the same way that xDBC and SQL provided a standard way for any software to access a discrete package of data (the database), Web services provide a standard way to discretely package anything (a database, a specific query, some business logic) and make it accessible to anything else (another database, a WAP-enabled phone, or better yet, an external partner's business logic systems).

In other words, you can cut your business logic up into discrete modules (you decide where the boundaries should be) and make those modules accessible, as needed, to the business logic in your partners' systems. In essence, you're now providing that logic as a service—the service part of Web services. This is what Web services proponents like Sun CEO Scott McNealy mean when they say one of every technology manager's top priorities should be to turn all software into services.

It's the protocols
In the past, integrating dissimilar external systems or even internal ones (where most people think Web services will ramp up first) generally required a proprietary interface that was difficult to develop and prone to breakage every time one of the integrated systems changed. Web services are simply the de facto standard protocols that make such integration possible without requiring you to reinvent the wheel for each new integration project.

Those protocols are XML, SOAP, WSDL, and UDDI. XML and SOAP are probably the two most important ones. The idea behind SOAP is that you have a standard way of accessing objects on any systems that support the protocol. Those objects are the discrete packages of data or business logic that I mentioned earlier.

XML is simply a standard way of structuring the text that gets passed between these objects. In the same way that Internet browsers understand HTML, SOAP-based objects are pretty handy with XML. It's the reason that techies call the process an XML RPC (remote procedure call). Think of the logic in the SOAP-based object as a remotely located procedure that needs to be "called" from across the Internet or a local area network. Whatever "calls" that object, be it a WAP-phone or a partner's system, packages its request in XML.

As Knorr points out in his column, there is a lot of work to be done on the XML front. XML may provide a way to structure the text, but within industries, companies must agree on what that structure (also called a schema) will look like. For example, if all airlines are going to integrate easily with all car rental companies, there needs to be some consensus within those two industries as to what the standard XML schemas look like.

Those agreements are taking shape, as working groups within industries are just beginning to coagulate. For instance, the human resources industry has already organized an XML schema standardization effort and maintains a Web site to track its progress. In addition to industry-specific efforts, several technology companies such as Intel, Microsoft, Computer Associates, and SAP, and industry leaders such as Ford, Gillette, and Pennzoil, have joined forces to form the Business Internet Consortium (BIC) to more broadly attack the problem of XML schema standardization.

No doubt, those and the other technology companies that belong to the BIC would love to see Web services become the next revolution in computing. Somewhere along the line, if companies decide to join the revolution, they'll need new technology and tools. And if their business grows as a result (one promise of Web services), they'll have to buy more gear. In other words, the involvement of Intel, Microsoft, and others in the BIC isn't purely altruistic.

Something vendors can agree on
This leads me to the most interesting and curious aspect of Web services. For the first time ever, there is virtually unanimous agreement among all technology providers on the point that Sun ONE VP Marge Breya made at the Blanc & Otus roundtable: Web services could be "the fundamental change of this century." Well, maybe agreement isn't unanimous on the timeframe; since it's only 2002, I wouldn't sign off on something as the most fundamental change of the century. But it's certainly the most significant change in computing.

Although the market is in an embryonic stage, just about every major company—Intel, Microsoft, IBM, Sun, Oracle, BEA, Computer Associates—is talking as though Web services is the greatest thing since sliced bread. All of them are racing to be the first to talk to you about it and the first to deliver all of the necessary widgets (mainly development tools and application servers) that will actually make it work.

Microsoft and Sun are the noisiest players. Each is attempting to outduel the other with announcements on the tools front. Both companies are focused on delivering tools that smooth the migration from the old world to the new, easily converting your existing software to services. This mainly involves taking old world objects and enabling them for the Web services protocols.

Microsoft's Visual Studio .NET makes child's play of this migration, easily converting COM objects into SOAP objects. Sun's Java Web Services Developer Pack does the same for Enterprise JavaBeans, although a shim is needed until XML is one of Java's native data types. Java's lack of built-in XML support is one reason Microsoft is perceived as leading in the race. XML will be a native data type in version 1.4 of the Java specification, scheduled for release mid-2002.

The truth is that both Java and .NET are so close to each other in terms of execution that deciding to go one way or the other should have nothing to do with who's ahead at any given time. The decision should have more to do with your existing infrastructure and talent pool.

A choice question
One upside to going with Java is that you'll have a choice of providers for your application servers. Even though Java is Sun's intellectual property, a whole bunch of other companies, including IBM, BEA, Oracle, Borland, and Macromedia, also make J2EE-based application servers and will be competing for your dollars via features, performance, reliability, security, and price. All of them offer something unique (like the clustering capabilities of Oracle 9iAS) that might appeal to you. Because so many vendors support Java, you have more choices for the underlying operating system and server hardware than you have for .NET.

When it comes to .NET-based application servers, you have one choice each for provider, operating system, and hardware: Microsoft, Windows, and Intel. Those of you who choose to go the .NET route will most certainly benefit from the competition between hardware companies such as IBM, Dell, Hewlett-Packard, and Compaq that offer Intel-based solutions. But only one company will offer a .NET server—and that's Microsoft.

Windows .NET Server, which ships later this year, will no doubt be a viable Web services platform, and Visual Studio will be a great tool for developing Web services that run on it. That doesn't change the fact that there will be only one provider. Adopting a platform for which there is only one provider puts that provider—and not you—in control of the platform. Microsoft is in charge of .NET's performance, reliability, and price. With a J2EE-based server, if IBM's WebSphere keeps crashing on you, develops a bad track record for getting hacked, or runs too slowly, or if IBM decides to raise the price, you always have the option of saying "enough!" and looking for a J2EE alternative that's more reliable, more secure, faster, or less expensive. With Windows .NET, there are no alternatives.

Anyone still wondering about the "Web" in "Web services"? Those XML RPCs are hitching a ride on the same transport protocol used by the Web: Hypertext Transport Protocol (HTTP) . They don't have to, but they do because it's a convenient way for the RPCs and their results to get in and out of the firewall, which is something sure to drive your security specialists crazy.

Editor's Picks