When you think ASP, think...
Recent Articles xml
All Articles
ASP.NET Articles
Related Web Technologies
User Tips!
Coding Tips
spgif spgif

Sample Chapters
JavaScript Tutorials
MSDN Communities Hub
Official Docs
Stump the SQL Guru!
XML Info
Author an Article
spgif spgif
ASP ASP.NET ASP FAQs Feedback topnav-right
Print this page.
Published: Friday, September 07, 2001

Sams Teach Yourself ASP.NET in 21 Days
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 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.

  • Read Part 2

  • ASP.NET [1.x] [2.0] | ASPFAQs.com | Advertise | Feedback | Author an Article