Building on the Foundation | Programming MicrosoftВ® .NET XML Web Services (Pro-Developer)

If Web services were limited to the kind of simple operations we’ve used to demonstrate how to create a service and client, there would be no need for a book like this. Using .NET to build your services means you have complete access to the .NET Framework and the functionality it offers—data access, directory services, window management services, and so on. There are few aspects of the Windows operating system and the applications running on it that Web services cannot access. Indeed, Microsoft has already integrated Web services into its Office application, MapPoint, SQL Server, and several more of its server applications. This should give you an idea of the ways in which Web services will soon be a part of everyday applications.

Aside from the functionality that a service and its methods can provide, it’s worth noting the way in which they can be integrated into a larger application. Indeed, the possibilities mirror those for standard ASP.NET pages.

State Management

By deriving your Web service’s class from the .NET base class for Web services, System.Web.Services.WebService, you have access to the HttpContext class’s Application and Session properties in the same way an ASP.NET application’s Page object does. That is, you can use, maintain, and update session-level and application-level variables for the Web application as a whole inside a Web method. All you do is set the WebMethod attribute’s EnableSession property to true and make sure your class inherits from the WebService class. Here’s an example in C#:

<%@ WebService Language="C#"  %> ⋮ public class OneArmBandit : System.Web.Services.WebService {     [ WebMethod(EnableSession=true) ]     public prizemoney Gamble()     {         ⋮         Session["Kitty"] = 25;         Application["Jackpot"] = ((int)Application["Jackpot"]) + 10;         ⋮     } }

And here’s one in Visual Basic .NET:

<%@ WebService Language="VB"  %> ⋮ Public Class OneArmBandit : Inherits System.Web.Services.WebService     < WebMethod(EnableSession:=True) > _     Public Function Gamble() As prizemoney         ⋮         Session["Kitty"] = 25;         Application["Jackpot"] = CInt(Application["Jackpot"]) + 10;         ⋮     End Function End Class

We’ll look more at maintaining state within Web methods in Chapter 7.

Incorporating Transactions

You can also make use of .NET support for transactions to ensure that a Web method completes its task either completely or not at all. That is, you can treat the Web method as a transaction. All you do is add a reference to and then import System.EnterpriseServices, which holds the transactional support in .NET, and set the WebMethod attribute’s TransactionOption property to the appropriate level. Here’s an example in C#:

<%@ WebService Language="C#"  %> <%@ Assembly name="System.EnterpriseServices" %> ⋮ using System.EnterpriseServices; ⋮ public class OneArmBandit {     [ WebMethod(TransactionOption=TransactionOption.RequiresNew) ]     public CashInChips(prizemoney Winnings)     {         ⋮     } }

And here’s one in Visual Basic .NET:

<%@ WebService Language="VB"  %> <%@ Assembly name="System.EnterpriseServices" %> ⋮VE> using System.EnterpriseServices; ⋮ Public Class OneArmBandit     < WebMethod(TransactionOption:=TransactionOption.RequiresNew) > _     Public Sub CashInChips(Winnings As prizemoney)          ⋮     End Sub End Class

There are a couple of things to note here, even with this cursory glance:

Your service class does not need to inherit from the .NET WebService base class to support transactions.
There is no need for your method’s code to explicitly commit or roll back the transaction if it succeeds or fails. If an exception is thrown while the method is running, the transaction is automatically aborted. If no exceptions are thrown, the transaction is automatically committed.
Because HTTP is a stateless protocol, Web methods can take part in a transaction only as the root of a new transaction. If one transactional Web method calls another, they each take part in their own transaction. This is true whether the TransactionOption property is set to RequiresNew or Required.

Asynchronous Services

Our examples have thus far used HTTP as the go-between protocol, as will be the case most of the time. As we’ve noted, however, HTTP isn’t the only protocol you can use to send a SOAP message. SOAP defines a binding to HTTP where the call and its response are sent asynchronously. Indeed, SOAP messages have also been carried over SMTP (e- mail) and several message queuing systems such as MSMQ and even floppy disk. (Carrier pigeons, as proposed in RFC 1149, have yet to be tested.)

The curious will have already noticed that the service proxy class you generate by creating a Web reference in a Visual Studio .NET project or by calling WSDL contains a pair of asynchronous methods for each Web method. These functions, BeginMethodName and EndMethodName, are called to send a message to the service and to process the results of the service’s response, respectively. Barring the additional method to call, however, the building of both service and client remain essentially the same as when you use HTTP or other synchronous protocols.

The structure of the SOAP message remains the same, and the only extra consideration is how the application will know when to call the End method for the call to the Web service. You have two choices:

Send the Begin method a callback function that will be triggered when the method has finished.
Have the client use a member of the WaitHandle class to listen for the Begin method to finish running.

The SOAP request to a service is dealt with by a different thread than the one looking after the SOAP response, so there’s no performance hit.

You’ll see more on client-server synchronicity in Chapter 8.

Security

Consumers and developers are both worried about holes through which malicious code can harm our systems and our data. This concern applies to Web services as well, and several efforts are ongoing to secure the contents of SOAP messages as they’re sent over the Web and make sure they’re from who they say they’re from.

Here are the three most common ways to secure your Web services communications:

Send all the requests and responses between client and service over HTTPS rather than HTTP.
Use Windows authentication to validate the identities of both client and service before reading and acting on the content of the SOAP message. Optionally, you can strengthen this authentication by using client certificates or Secure Sockets Layer (SSL).
Incorporate additional information into the SOAP message headers to provide a custom authentication solution. A couple of extensions to the SOAP standard are designed for just this purpose.
Set up a file/IP/URL authorization policy on your server that restricts access to clients based on the files they’re requesting or the IP/URL the request came from.

Microsoft’s .NET My Services was going to use a Kerberos-enabled version of Passport to identify users and establish which set of records their requests would read from and write to. Ironically, this was probably the nicest feature of .NET My Services. The point is that you can easily come up with your own security solution, as you can an XML grammar, or you can use a tried and trusted solution. The whole of Chapter 11 deals with this issue.