Home > Articles > Web Services

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Defining “Web” and “Service”

So let's dig a little deeper into our definition. Just what is a Web service? If we dissect the name, we can infer that a Web service has something to do with the Web and something to do with services. I like to say that a Web service is a service that lives on the Web. This definition doesn't help us very much, though, unless we know the meaning of the terms “Web” and “service.” So let's start there.

The Web is an immensely scalable information space filled with interconnected resources. The architecture for the Web has been developed and standardized by the World Wide Web Consortium (W3C). A Web resource is any type of named information object—such as a word processing document, a digital picture, a Web page, an e-mail account, or an application—that's accessible through the Web. All resources on the Web are connected via the Internet, and you access Web resources using standard Internet protocols. Any network-enabled application or device can access any resource in the Web. Right off the bat, you can see that the Web solves one of your integration challenges: The Web is pervasive and provides universal connectivity.

A service is an application that exposes its functionality through an application programming interface (API). In other words, a service is a resource that is designed to be consumed by software rather than by humans.

The term “service” implies something special about the application design. It refers to something known as the service-oriented architecture (SOA). The SOA is the basic architecture used by most RPC-style middleware systems. Chapter 3 talks about the SOA in detail.

One of the most important features of the SOA is the separation of interface from implementation. A service exposes its functionality through an interface, and that interface hides the inner workings of the application. A client application doesn't need to understand how the service actually performs its work. All it needs to understand is how to use the interface. To give you an analogy, let's look at a car. A car is a complicated machine, but the car provides a set of interfaces that's relatively simple to use. To start a car, you don't need to know how an internal combustion engine works, or even how the starter motor works. You only need to know how to use the interface that the car supplies to start it: Turn the key.

A Web service possesses the characteristics of both a Web resource and a service. It is an application that exposes its functionality through an API, and it is a Web resource that is designed to be consumed by software rather than by a human sitting at a browser.

Understanding the concept of a service is key to understanding Web services. A service is a piece of software that does work for other software. In most circumstances, a service runs on a server, waiting for an application to call it and ask it to do some work. In many cases services don't provide any type of human interface, and the only way to access the service is through its API.

A service can perform system functions or business application functions. For example, a file service can create, find, save, or delete a file. A stock quote service can retrieve the current ask and bid prices of an equity.

All client/server technologies rely on this basic concept of a service. A service is the business or system application that plays the part of the server in a client/server relationship. Print servers, file servers, database servers, Web servers, and application servers are all examples of service-oriented systems.

Any business application that exposes its capabilities through an API is a service. Business application services often run in an application server. An application server manages and coordinates the utilization of all resources available in a shared, multiprocessing environment, enabling optimized performance, scalability, reliability, and availability.

You often need this type of scalability because many different users can share a single service. A service is a shared resource. One reason you might want to design a business application as a service is to consolidate your efforts and reduce duplicated work. If there is a particular piece of functionality that many of your applications need to perform, you should build this functionality as a service rather than reimplement the functionality in each application.

For example, as shown in Figure 2-1, it's much simpler and easier to manage and maintain your order processing system if you have only one application service that actually processes orders. This one service can support all the different ways that you offer to place orders, inquire about order status, and generate reports about orders.

02fig01.jpgFigure 2-1. A service can be shared by many different applications.

Building Services

To let clients access a service over the network, you must build a network API for the service. You generally use some type of communication middleware to create a network API. You can use a traditional middleware technology, such as RPC, DCOM, CORBA, RMI, or MOM, but all these technologies suffer from the Traditional Middleware Blues. If you want to make your services available to heterogeneous users across multiple systems (including the Internet) at a reasonable cost, you should use middleware technology that supports these requirements.

Web services represent a new type of middleware that relies on the Web. The Web resolves the pervasive aspects of the Traditional Middleware Blues.1 The Web is pervasive. The Web is free. The Web is completely vendor-, platform-, and language-independent. The Web uses the Internet as its native communication protocol. Web services support easy integration, flexibility, and service reusability.

  • + Share This
  • 🔖 Save To Your Account