Handling Metadata with Indigo - Web Site Templates
(Page 3 of 4 )
Many web site templates exist for creating new ASP.NET applications, so it shouldn't surprise you that there is a template to get you started with WCF. The new WCF Service template can be used to create a new web site that is file-based or hosted in IIS. This lab illustrates how to create an IIS-hosted site--the preferred way to test your services if you want an accurate depiction of security-related behavior. Regardless, if you create an IIS- or file-based web site, the files generated are the same:
- A sample service contract and implementation
- A .svc endpoint for the sample service
- A web.config file with service model configuration settings for the sample service
@ServiceHost Declarations
IIS hosting requires a file-based endpoint with a .svc extension. That's because it relies on file-extension mappings to determine how incoming requests should be delegated. The .svc extension is a new extension specific to WCF, and IIS knows to pass those requests to the service model for processing (via ASP.NET). In this hosting environment, each unique service must have a .svc endpoint. Chapter 4 discusses hosting in detail.
The .svc endpoint has one job to do--help the service model find the correct service type to host. The@ServiceHostdirective is the link between the incoming request and the service model. In theory this directive can point to a service type declared with inline code based on a source file or belonging to a compiled assembly.
Similar to inline ASMX web services, .svc files can contain the actual source code for the service contract and type. This makes it possible to deploy just the .svc file without any accompanying source, as shown in Example 1-16. In this case, theServiceattribute refers to the inline service type, and you can even enable inline debugging by setting theDebugattribute totrue. Although ASP.NET 2.0 introduced the possibility of compiling this inline code into an application assembly to protect the source, I still consider this a tight coupling of the service implementation to the hosting environment--and that doesn't promote reuse or deployment flexibility.
Example 1-16. Inline service code
<%@ ServiceHost Language="C#" Debug="true" Service="MyService" %>
using System;
using System.ServiceModel;
[ServiceContract()]
public interface IMyService
{
[OperationContract]
string SomeOperation(string myValue);
}
public class MyService: IMyService
{
public string SomeOperation(string myValue)
{
return "Hello: " + myValue;
}
}
Another approach is to associate the .svc file with a code file in the web site as the original sample service did in this lab. For ASP.NET 2.0 web sites this means placing the source in the \App_Code directory. In this case, theServiceattribute still refers to the service type, but theCodeBehindattribute is present to indicate the location of its source file:
<% @ServiceHost Language=C# Debug="false" Service="MyService"
CodeBehind="~/App_Code/MyService.cs" %>
This approach still couples the source to the host and lacks autonomous version control over services apart from their host.
Ultimately, the preferred way to associate a service type with its .svc endpoint is to add an assembly reference to the project and specify the fully qualified service type in theServiceattribute:
<% @ServiceHost Service="MyNamespace.MyService" %>
This approach gives you the desired autonomy and reuse for the service.
Message-Based Activation
One of the benefits of using a fully featured host such as IIS or WAS is that it handles service activation on your behalf as messages arrive to the service. In the first and second labs in this chapter, you hosted a service in a console application. In all such self-hosting environments, you must explicitly run the host process before clients can invoke the service. The ServiceHost instance is constructed and opened explicitly, and its lifetime is tied to the lifetime of the host process.
IIS and WAS, on the other hand, are system services that are equipped to process incoming messages even if theServiceHosthas not yet been constructed. For example, when a request arrives for a particular .svc endpoint, the request is ultimately forwarded to the service model. The service model looks at the@ServiceHostdeclaration to find the associated service type. It then instantiates theServiceHost instance for that type on your behalf, within an ASP.NET worker process. The web.config settings are used to initialize theServiceHostand thenOpen()is called--at which point the first request is forwarded to the appropriate channel listener. Once theServiceHost has been constructed and opened, subsequent requests for the same service are directed to it. Simply put, with IIS or WAS hosting, you needn't manually create theServiceHostinstance--this is handled for you by the host process. This is called message-based activation. The details of hosting are discussed in Chapter4 .
Another convenience of IIS and WAS hosting is that you can modify web.config settings for a service and the changes are reflected in subsequent calls without restarting IIS or WAS. That's because changes to configuration files are detected, and if necessary, a new application domain is constructed to service requests. For example, if changes to the service model configuration require that a newServiceHost instance be constructed to reflect the changes. In a self-hosting environment, new settings are not known to the host process and thus are not reflected until you restart. You could optionally build logic into the host to detect changes and recycle anyServiceHostinstances. With IIS and WAS, configuration changes are detected and a newServiceHostis created to handle subsequent requests.
Next: Browsing and Exporting Metadata >>
More BrainDump Articles
More By O'Reilly Media
|
 This article is excerpted from chapter one of the book Learning WCF A Hands-on Guide, written by Michele Leroux Bustamante (O'Reilly, 2007; ISBN: 0596101627). Check it out today at your favorite bookstore. Buy this book now.
|
|
