Although still in the introductory stage, Web services are already controversial. While software vendors almost unanimously proclaim Web services the wave of the future, numerous analysts and software developers remain skeptical. In this tutorial, Nelson King discusses the issues surrounding Web services and makes recommendations about ways organizations can prepare for them.
Though barely into the introductory stage, Web services are already controversial. Software vendors almost unanimously proclaim that Web services are the wave of the future. Yet numerous analysts and software developers are skeptical, at best, about the scope and importance of Web services.
In the middle of this hype and noise are the enterprises and individuals who feel that sooner or later they will have to deal with Web services. Should they believe the vendors and dive in with both feet? Or should they believe the skeptics and test the waters with a tiny toe? In this tutorial we will try to sort out the issues and make some recommendations about ways organizations can prepare for Web services.
What are Web services? If you ask 10 experts you'll get 11 answers and many qualifiers.
Let's start with an example instead: You want a stock ticker in your application or your browser? You can get that piece of programming as a Web service.
For the end user Web services run the gamut from simple programs like the stock ticker to the major components of a word processing application. Many vendors, such as Microsoft, hope to break up their huge applications and rent them out as Web services. You wouldn't buy Microsoft Word; instead you would rent the pieces of Word you want to use.
From a consumer point of view, "Web services" are program components (to use object-oriented language, objects with encapsulated functionality) that are registered on Internet servers to be used as-is or in combination with Web applications.
The concept of gathering components from across the Internet to make up a program is not new. Technologies for doing what are often called distributed applications, such as CORBA and DCOM, have been around for years. These approaches, however, never fully succeeded. So what makes people think Web services will succeed?
In one word: standards.
Standards are the heart of Web services; without them the over-arching goal of interoperability would be impossible. The primary standards involved are: XML (eXtensible Markup Language) to handle the data, UDDI (Universal Description Discovery and Integration) to register services on Internet servers, SOAP (Simple Object Access Protocol) to formalize how a service may be used, and WSDL (Web Services Description Language) to provide the scripting necessary to run the service.
Together these standards provide a common approach to building, distributing, and using Web services. Since all of the major software companies have signed on to these standards, we think Web services may accomplish things that haven't been possible before in business-to-business and business-to-consumer applications.
Consequently, a good way to prepare for Web services is to get up to speed on the standards and keep an eye on them. It's important to know how much the standards change as part of the ongoing work of standards bodies, such as the W3C, and how much individual vendors change (e.g., warp, pervert, suborn, embrace, and extend) the standards to fit their own agendas. This latter aspect is, unfortunately, already threatening to take place especially between the major vendors such as Sun, Microsoft, Oracle, and IBM.
Because Web services will probably have varied effect on different industries, it is helpful to read or hear case stories from peers. This will enable you to develop a sense for how Web services are applied and perhaps learn some of the caveats and gotchas. In the end though, you must acquire an intuitive feel for what Web services are and how they can be applied. That is usually the result of trying it for yourself.
A year or so ago it might have been advisable to use some of the kits that were just appearing (e.g., the Microsoft SOAP Kit), but we think that's no longer appropriate. Full-scale Web services tools have been released in many different forms, and organizations should experiment with tools that reflect its normal choice of languages and development environments. For example, an IBM shop ought to be working with IBM WebSphere Studio and the Web Services Extensions. Likewise, Microsoft shops should be working with the relevant portions of Visual Studio .Net.
Keep in mind that it might be difficult for one person to master all of the necessary elements of Web services -- SOAP, WSDL, and especially XML can require ascending a major learning curve.
If you have the resources (i.e., time, money, and patience) during a testing phase, try to push the limits of Web services in the context of your own organization. This means, for example, that you set up a pilot or trial program where users must connect with the Internet, fire up a Web-services-based application, have it find the UDDI service with the appropriate Web service, load it, and then run it -- all within a period of time in which the user doesn't begin to twiddle her thumbs and think about how she's going to complain to the support group. Push this envelope; don't just massage it with simple programs and cozy situations. An aggressive testing posture is necessary because there are weaknesses in both the theory and the protocols behind Web services that must be uncovered if they will affect applications.
Here are some questions we feel deserve close scrutiny and careful planning:
- What parts of existing programs lend themselves to a Web service? Not all applications should be part of a distributed scenario -- especially those that require tight security or are relevant to a single campus.
- Where is the data involved? Most Web services must tap into or contain data. This is not always easy to arrange in a far-flung distributed application environment.
- Where and how would you list a Web service with a UDDI server? Access to appropriate servers, which may need to be your own, can be critical for some Web services (and also part of the performance issues).
- Are there potential bottlenecks in the performance of your Web services? Performance may be a major issue if user download is lengthy or coordination of multiple services is required.
- Will you charge for the Web service, and if so, how will the money be collected?
- What security issues are involved? Most standards in this particular area are still on the drawing board.
So far we've talked mostly about building your own Web services. To a certain extent this is fine with many of the vendors, they'll sell the tools. However, most, if not all, of them also want to sell Web services in whole or in part. As mentioned, they see Web services as a cash cow spigot that they're eager to tap. Be prepared for the pitches. This also applies to the consumer, who's going to be hit with a bombardment of fragmented software like a meteor shower.
Everything we've previously stated falls into two threads: Web services are real, and they will (eventually) find an important place in the options for software distribution. However, whether they become the be-all, end-all of software is a very open question, so a degree of caution is warranted.
More than most "hot trends" in computing, Web services call for experimentation and some wait-and-see before jumping into full production.