The Web service is the quintessence of the Web as we know and use it today. Even though the term Web service has been around only a short while, the concept is nothing new. You can think of a Web service as an abstract interface, first implemented in the HTML-based interaction between a user and a Web server. When a user invokes a URL, he is invoking a default method on a server-side module that provides some services. The return value is the plain old HTML page, where raw information is interspersed with graphics and layout information.
Take this idea one step further, and you get the broadly accepted definition of a Web service. A Web service is a software application that can be accessed over the Web by other software. A Web service is applicable to any type of Web environment: the Internet, an intranet, or an extranet. A URL is all the user needs to locate and access a Web service. In theory, a number of Internet-friendly protocols might be working under that URL. In practice, the protocol for Web services is always HTTP. A Web service has only one type of consumer: other software. Users can certainly access a Web service, but only by means of other tailor-made software.
The software community’s recent focus on the term Web service suggests that the technology—regardless of platform or philosophical approach—is finally sophisticated enough to generalize and parameterize the software mechanism used to access URLs. Web services have extended and made more powerful the programming interface for accessing Web applications. Instead of using only one default method to access a URL and return HTML, you can use a variety of more specialized methods with customized signatures. Most important of all, you have programmatic support from the development environments on a variety of software platforms (Microsoft .NET, Oracle, and Java). You can now manipulate a Web service by its software elements—an object, a class, a function, or anything else exposed by the interface of the environment.