Consuming a Web Service

361

Trying Out the Client

To simulate two different users making changes to the same record, start two Web

15

browsers. In the first Web browser, use the URL http://localhost/TaskClient/ TaskUI.aspx. In the second browser, use the URL http://127.0.0.1/TaskClient/ TaskUI.aspx. Using these different URLs has the effect of creating two different ASP.NET sessions, so you can simulate two different users.

Try adding and modifying records using the two different clients. Figure 15.2 shows an example in which one user tries to modify a record changed by another user.

FIGURE 15.2

Two shared task clients that modify the same record.

Summary

Today’s lesson showed how to create Web Services that use and return custom data structures and complex parameters. The first section detailed each kind of data type that you can use with HTTP and SOAP. You saw how HTTP restricts many of your options for a Web Service and how you can use SOAP to transmit almost any kind of data.

The second half of today’s lesson gave an advanced example of a Web Service that handles conflicting data modification requests from multiple clients. You learned the difference between optimistic and pessimistic locking and saw one strategy for overcoming some of the limitations of the optimistic locking scheme. The example used a record versioning strategy, which added a timestamp to each record. You can use the techniques presented in this sample in your own Web Service applications. These record-locking techniques aren’t unique to Web Services and can be applied in many kinds of applications.

362

Day 15

Q&A

QBecause the HTTP protocol is limited to call by reference, what practical effect does this have for my Web Service clients?

AWeb Service clients that use HTTP instead of SOAP won’t be able to use any Web Service methods that use call by reference parameters. ASP.NET generates the WSDL interface file automatically, and it won’t generate method definitions for methods that use reference parameters for the HTTP protocol. All methods will contain definitions for the SOAP protocol.

QI’m not sure if I should use an optimistic or pessimistic locking scheme for my Web Service. What are the critical issues?

AOptimistic locking works well when a large number of client programs don’t modify the same records frequently. This situation can be described as the “low contention” scenario because client programs don’t contend to modify the same records too often. However, if multiple client programs update the same records frequently, optimistic locking doesn’t work very well. Use pessimistic locking for this “high contention” scenario, when many users want to modify the same data record.

Workshop

The Workshop provides quiz questions to help you solidify your understanding of the material covered today as well as exercises to give you experience using what you’ve learned. Try to understand the quiz and exercises before continuing to tomorrow’s lesson. Answers are provided in Appendix A, “Answers to Quizzes and Exercises.”

Quiz

1.Can the HTTP protocol support methods that use the ADO.NET dataset as a parameter? Why or why not?

2.What is an “out” parameter?

3.What is a “ref” parameter?

4.What is optimistic locking?

5.Why is optimistic locking used in Web applications and services?

6.What method can you use to check the validity of a record modification request when using optimistic locking?

Consuming a Web Service

363

Exercises

1. The Task Server contains a major defect if used by many clients simultaneously.

15

The problem is that the Update method might change the contents of the source XML file while the AddTask method is being called. Use the .NET Monitor class to synchronize access to the XML file in the Web Service.

2.Change the Task Server to use a SQL Server database or a database server of your choice. How much of the code needs to be changed?

WEEK 3

DAY 16

Putting It All Together with Web Services

By reading the last three days’ lessons, you’ve gained a good knowledge base to use when creating your own Web Services. Today’s lesson will build on the last three and will teach you some more advanced techniques that you can use in your own Web Services.

Today’s lesson will begin by explaining how to manage state in your Web Services. This issue arises when you need to store information about particular Web Service clients between the calls that they make to your service. You will learn how to use the built-in Application and Session objects within your Web Services. As you will see, managing state can get complicated depending on the capabilities of the client accessing your service. This lesson will give solutions to many of these complex issues.

Today’s lesson will continue by introducing a new technique called asynchronous calling. Web Service clients can use this method to call Web Service methods that may take a long time to complete. Clients can create a request to execute a Web method, perform other work, and then be signaled when the method is complete. You will see two examples that use this technique, including a Web form–based client.