How Web services might change the nature of computing.
Raise your hand if you’ve heard of Web services. Drop your hand if you’re not sure what they are. Drop your hand if you’ve never seen one. The two of you with your hands still in the air might wonder if the computer industry hype has been very effective. Depending on whom you talk to, Web services are either the most important technology since the Web or a minor improvement in enterprise application integration. Seldom has a technology category been so heavily hyped–and dissed–before its significant products or projects have been widely deployed. It seems like Web services are already hitting the third stage of the four-stage technology life cycle: Hype, disillusionment, reality, and decline. That is, they’re close to reality.
For this story on Web services, we’ve pulled together an unstinting review of the pluses and problems of this emerging technology. Whether you’re a corporate enterprise, a small business, or an end-user, you’re going to encounter Web services sooner or later. It may be a big opportunity. It will probably cost you money. It might even change the nature of computing. In any case, Web services are worth a closer look.
What a concept
Compared to many other major developments in computing, such as the personal computer or the Internet, the nature of Web services is difficult to pin down. That’s why almost everybody takes a stab at defining it, and almost none of the definitions are the same. Maybe that’s a clue: Web services are many things to many people.
Web services involve both data and programs, and not always simultaneously. So Web services can provide data transfer between otherwise incompatible computer systems. Web services can also provide programming modules written in different languages and residing on incompatible systems. Web services can be combined to make up larger applications. To use the jargon of the trade, Web services are a standards-based Internet integration platform.
Here’s a definition most will agree on. Let’s say you run a mid-sized manufacturing company with around 200 suppliers. Most of these suppliers would like to be connected to your company via the Internet for inventory, sales, and other information. Each supply company has its own combination of hardware, software, and communications. To share business information, your company must research each of its supplier’s computer systems, and they must know yours. Without this mutual knowledge, neither your company nor the suppliers can devise a means of interfacing the systems, implementing a design, and then maintaining it. Despite the advantages of doing this, such as just-in-time inventory management, this is a very time-consuming and expensive process.
Now suppose all your company needs to do is publish the following to a directory service: This is what you have; this is how users can get it; and this is what you expect in return. Suppliers use this directory to determine if and how they will exchange information. The whole process might be done electronically, but it doesn’t require a team of programmers and database administrators. This is one instance of what Web services promise.
Here are some areas in which Web services are expected to play a major role:
Moving data between incompatible systems Distributing and updating applications Selling portions of applications Hosting applications Providing subscription data services Integrating existing applications Enabling massively parallel (grid) computing
What a process
Another essential element of Web services is the process involved in developing and using them.
Those who have a Web service to offer will decide what the service contains: data, programming, or both. A Web service might be weather data or a program that displays the forecast for a specific city. Especially if programming is involved, the provider decides on the functionality, or what the service does. It might calculate something, like a currency converter, or conduct a transaction, such as a purchase. The provider also needs to decide who should have access to the service and whether there are conditions such as fees and verification. Essentially, the provider makes up a software package that neatly contains a service.
The service package becomes an item that can be used (the industry likes to say consumed) by someone with a need for that service. But how does the consumer find out about the service? Described in outline, the consumer goes to an accessible directory that lists many services and searches for one that fits their need. For example, say you need a service that will translate a letter into German. Your program searches a directory to find such a service. If there is a match, you may be shown what it is, where it’s coming from, and how much it costs. If you agree, this service may be downloaded or run from a server somewhere on the Internet. It may (or more probably, not) stick around in your computer after you’re done.
The content of a Web service can be tiny, perhaps one bit of information; or huge, like an entire application–although for performance’s sake, most Web services will not be very big or require lengthy downloading. There are a jillion variations on what Web services will contain and do, where they will be located, and how the consumer will use them. This is why those who develop Web services and Web-services tools believe there is such a vast potential market.
Standards and bystanders
Those of you who have been around computing a while realized long ago that distributing data and applications over a network is hardly a new idea. In fact, the idea goes back many decades, if not to the dawn of computing. There have been many attempts to forge technologies for distributed computing: Think of OSI, DCOM, IIOP, and CORBA. Most of them worked, more or less, but none became dominant or very popular. For the most part they were complicated and difficult to program. They usually required tight integration between the client who requested something and the server that provided it–meaning they usually had to run on similar operating systems and conform to specific data formats. There were standards, but they remained narrowly accepted.
In this context, the big deal about Web services is threefold: The technology doesn’t require the best and brightest to implement, which is to say that normal programmers can make the services work. The Internet provides a hugely successful common network, functioning on a scale never achieved by any other network. And the standards involved with Web services have, so far, been accepted more widely than any previous standards.
At its core, the standard of standards is the eXtensible Markup Language (XML). Originally designed by the Worldwide Web Consortium (W3C) to augment HTML with some badly needed data-handling capability, it has become the seed from which many other standards have grown, including the other Web-services standards.
XML has the task of describing the data in Web services, most of which flows over Hypertext Transfer Protocol (HTTP). The place to find Web services, the directory, is standardized by Universal Description, Discovery, and Integration (UDDI). The Simple Object Access Protocol (SOAP) is used to describe standard methods of communications packaging used by applications to exchange data with other applications–the glue for knitting together data and programming pieces. And Web Services Description Language (WSDL) provides the XML definitions for the high-level capabilities and technical details of Web services.
Together these standards provide enough information and procedures for very sophisticated Web services; at the same time, they’re simple enough to be generated and managed by computer programs. This relieves programmers and users of much of the burden of creating and using Web services.
The cold shower
To the computer industry, especially the software companies, Web services sound like a great solution to the age-old problems of integration and interoperability, and a new opportunity for revenue. That’s the big attraction. The question remaining is: What needs to be done to turn Web services into the Next Big Thing? The answer is, a lot more than we can discuss in this limited space.
This may sound like sour grapes to evangelists, but there are questions and problems that Web services must address before they become widely accepted. Some are quite fundamental and, if unanswered, could be lethal to broad success.
Transaction security, which is at the heart of many Web services, can be complicated. Transactions must be authenticated (from both provider and requester); remain confidential; remain intact across the Internet (not a given); and be verifiable (did you get what you expected?). The more important the data or programming–think of moving money–the more crucial this security becomes. Security experts warn that Web services may provide a whole new playground for hackers.
Other major considerations include: How do users pay for Web services? Micropayments and other credit systems are not yet in place. Who supports an application that’s built with Web services from all over the place? How do you select a Web service? You might need 10 or 15 Web services for an application. How do you know you’re getting the best ones, or even that you’re getting ones that work? Think of Web services as publicly advertised DLLs. That should send a shudder down the spines of Windows users everywhere. How do you know that you can trust the services to get along and be good citizens in client computers? How do you know that they don’t contain fiendishly clever hacker work? Then there’s version control: How can you be sure you’re getting the latest and greatest?
To answer these and other questions, the industry is scrambling to invent new protocols and standards, plus work out the kinks through practice. Over the next year or two substantial progress needs to be made in these areas, among others:
Make the transmission of services reliable and secure. Assure the quality, privacy, and security of listings in UDDI directories. Ensure that transactions embedded in services are secure and verifiable. Provide adequate performance despite the latency and bottlenecks of the Internet. Develop an infrastructure of hardware and software to support Web services. Provide the means for workflow standards, management control, and business rules to be adequately handled by Web services.
With all the work that needs to be done for Web services, who’s doing the heavy lifting? Some of it is being done in standards committees, populated in large part by members from IBM, Microsoft, Oracle, Sun, and a handful of smaller companies. Products and development systems produced by IBM, Microsoft, Oracle, Sun, and (again) a number of smaller companies are doing the rest of it. There are two main Web services camps: Java and Microsoft, a situation that produces a running controversy about which has the best approach.
Microsoft has a two-pronged strategy with a unifying structure, the .NET Framework architecture. Under this umbrella there is Visual Studio .NET and the .NET server to provide programmers and software companies with the tools to develop Web services (among other things). The other piece is .NET My Services, in which Microsoft sells its own Web services such as .NET Alerts (news, information), .NET Wallet (purchase verification), and .NET Inbox (mail). .NET My Services was initially slated for rollout this spring and summer, but has been delayed by Microsoft’s admission that security and privacy concerns need to be more fully addressed. By the time it sees the light of day, My Services will probably look a lot different than how this outline portrays it. But some sort of client-side service package will be part of Microsoft’s Web-services products. Microsoft has quite literally bet its future on Web services, which is something to ponder.
In the other camp, Java–or, more specifically for Web services, Java 2 Enterprise Edition–there are a number of companies: Sun Microsystems, IBM, Hewlett-Packard, and Oracle among others. This is a fractious group, sometimes seeming only to be held together mainly by their desire to compete with Microsoft. Java has been said to be behind Microsoft in Web services but ahead of Microsoft in overall approach.
In recognition of the issues surrounding Web Services, a number of vendors from both camps recently formed the Web Services Interoperability Organization (WS-I). Among the founding companies were Microsoft and IBM. Sun, however, was not so honored. This immediately resulted in a nasty row. At any moment, the centripetal force of competition can threaten to blow apart the standards crucial to Web services.
Is a lock-in looming?
The issue of competition over Web services has other ramifications. Consider these two scenarios for the future: Web services will be dominated by monolithic corporations that will compete among themselves to lock in customers (i.e., business as usual) Or, Web services will once again open up the software market to allow numerous small companies and integrators to provide best-of-breed services for selection by the consumer.
One scenario looks at the vast software architectures such as Microsoft .NET and Sun One, and sees them binding programmers and users to one or the other by dint of sheer complexity and overwhelming influence. The other sees hundreds (if not thousands) of companies offering Web services and competing on more or less even ground with the major software vendors. One seems to lead to lock-in, the other to freedom of choice.
To this line of thinking, the major vendors generally say, “Bosh.” Yes, the big software companies will provide large-scale frameworks for developing and using Web services, but within those frameworks, a thousand points of entrepreneurial light will shine. I guess this is the computer industry’s equivalent of lions chumming with lambs. In the biggest picture, even Web services from .NET and Java will be able to work together.
Your own choices for Web services
For individual users and for most corporate purposes, there are some relatively easy questions that will help you judge the value and validity of a Web service:
Is it safe? Is it private? What does it cost? How long does it take to get and use it? Does it work better than what you had?
Expect an onslaught of Web-services developments throughout 2002, particularly by fall, as vendors tumble over themselves and standards committees to make the dream come true. Some say the killer app for Web services will show up in the mobile crowd. Nowhere is the quick-bytes mentality of Web services more at home than among PDAs, mobile phones, and other small devices that don’t have the built-in resources of the desktop PC. Others say a less glamorous but perhaps more fundamental use of Web services will be in enterprise application integration (EAI), stitching together many incompatible systems.
Businesses are likely to use Web services piecemeal at first (if at all) and the reality is they will do so only when they can afford the expertise needed to make them work. This means that for the majority of businesses, large and small, Web services are going to be studied, tested, used, and deployed at a rate measured in years instead of months and without the frenzy we saw with e-commerce. This is hardly a bad thing, because it’s probably going to take that long for Web services to acquire the necessary security, reliability, and support.
Web services can do data. Web services can do programming. Combinations of Web services can do applications. What proportion of these will actually show up in working Web services, we don’t know yet. This is just one of many questions about a very promising technology. No question about it though: Web services is a mixed bag–a very big mixed bag. It just might turn out to be the whole kit and caboodle.