Summary

In this chapter, you have seen how to create and consume Web services using C# and the Visual Studio .NET development platform. Doing this is perhaps surprisingly simple, but is instantly recognizable as something that could prove to be incredibly useful. There have already been many announcements about new Web services, and I suspect that they will be everywhere before long.

It has also been pointed out that Web services may be accessed from any platform. This is the result of using the SOAP protocol, which doesn’t limit you to .NET.

The main example developed in this chapter illustrates how you can create .NET-distributed applications with ease. I have assumed here that you are using a single server to test things, but there is no reason why the Web service shouldn’t be completely separate from the client. It may even be on a separate server from the database if an additional data tier is required.

The use of data caching throughout is another important technique to master for use in large-scale applications, which might have thousands of users connecting simultaneously.

Exchanging data via SOAP headers, introduced in the last example, is another useful technique that can be worked into your applications. The example uses the exchange of a login token, but there is no reason why more complex data shouldn’t be exchanged in this way. Perhaps this could be used for simple password protection of Web services, without having to resort to imposing more complex security.

Finally, remember that Web service consumers don’t necessarily have to be Web applications. There is no reason why you can’t use Web services from Windows Forms applications - which certainly seems like an attractive option for a corporate intranet. One added bonus concerning Web services in ASP.NET 2.0 is the ability to call Web services asynchronously, using a simple, event-driven system. This fits in perfectly with Windows Forms applications, and means that you can keep your applications responsive while complicated Web services carry out hard work for you. derive from MarshalByRefObject. Classes of these types cannot be used as parameters in a remote object’s public methods. These classes are bound to the application domain where they are created. Nonremotable classes should be used if the class has a data member that is only valid in the application domain, such as a Win32 file handle.