Yesterday you learned about building components for your ASP.NET
applications. These components can be used over the Internet to provide
functionality for your ASP.NET pages. What happens, though, when you want these
components to be available without having to use ASP.NET pages?

Web services are a new way to deploy applications. Using XML and other
standard technologies, Web services enable applications and components to talk
to other applications no matter where they're located, whether it's on
the same machine or across the globe.

Today will be spent learning all about building Web services. They're a
revolutionary way to think about Web applications and are an essential topic for
ASP.NET developers. Tomorrow, you'll learn how use these services in your
ASP.NET applications.

Today's lesson will cover the following:

What Web services are

How Web services work

When to use Web services

How to build Web services

How to create Web services from existing business objects

The Way the Web WorksRevisited

When you began your journey through ASP.NET 15 days ago, you examined the
fundamental operations of the Webnamely, the request/response model of
operation. A client (such as a browser) requests a page from a Web server, and
the server sends the page back to the client through a response.

Then you learned about the programmable Web. ASP.NET and other technologies
allow you to perform tasks when the pages are requested. You can serve data to
clients dynamically by providing programmatic capabilities on the server.
Although ASP.NET extends this model by placing an event-driven mechanism on top,
the fundamental mechanism of the Web is still the same: request/response.

ASP.NET pages provide a front end that allows users to interact with a Web
site. Behind the UI, possibly in business objects, there may be some powerful
application logic. What if the functionality in one Web site is so useful that
other programmers want to include it in their sites? Or what if people want to
use the functionality but can't use the UI, such as if they're working
from a command prompt? How do you take advantage of the request/response model
in these situations?

It's easy. Think of the way ASP.NET pages interact with business
objects. They use methods and properties provided by the objects to perform some
functionality, and the object may or may not return some information. In
essence, you're sending a request to perform some function and waiting for
a response.

Why can't any other application interact with the objects the same way?
Just send a command over the Internet and wait for a response. Figure
16.1 illustrates this concept. The idea is very simple, but until now the
technology to make it happen didn't exist.

In a more real-world example, one Web site should be able to make a request
of a second Web site and wait for a response. The first Web site could interact
with methods and properties available at that second. Figure
16.2 illustrates this concept with a stock price service. The user makes
a request from a Web site, which in turn makes a request from a stock exchange
site. The second Web site returns the data to the first, which can display the
data to the user in any way it wants.

Figure 16.1
Applications should be able to interact with Web services just as ASP.NET pages
interact with business objects.

Figure 16.2
Web services allow Web sites to use functionality available on other sites.