Day 16: Creating Web Services
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 WorksRevisited
When you began your journey through ASP.NET 15 days ago, you examined the fundamental operations of the Webnamely, 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.