Chapter 10: Extending the Web Services Framework

Overview

The key to software design is to take a problem or a task and divide it into the actions that must be taken to solve the problem or complete the task. Sometimes those component actions must be further divided until each action is a simple unit that can be implemented as a class method or a single line of code.

The problem that this book addresses can be summed up as “how to deliver a Microsoft .NET solution that exposes operations as methods that are available publicly as a Web service.” If we apply the simple tenet of division to this problem, we can see that in the ASP.NET infrastructure Web methods should do only what they were intended to do. On a live production server, security, logging facilities, quality-of-service regulation, and other features must be implemented as part of the infrastructure and not as part of the service.

In this chapter, we’ll look at two kinds of components you can attach to a Web application: HTTP modules and SOAP extensions. Each type of component influences a different period in a SOAP request’s life cycle. We will discuss how they differ, how to build them, and when to use them. Like the HTTP handlers you saw in Chapter 5, both allow you to get closer to the actual processing logic that the Web method API deals with and “protects” you from. Using one or even both in tandem, you can intercept requests before they are processed by the handler and intercept the responses before they make their way back to the client.

Just because you have access to the message doesn’t mean your components will necessarily alter that message. They might carry out administrative tasks such as logging, tracing, and validating.