I've just managed to get the .NET 3.5 style of WCF Web Programming Model services to work inside an EPiServer 5 R2 site on IIS 7 and Windows 2008.  I had a few difficulties finding out how to integrate the new model into IIS/ASP.NET and then further problems getting it working in EPiServer.  Here, I outline the solution.

Context

I'm currently designing a site that will be using the Akamai Edge Suite of technologies (www.akamai.com) and so I desire that all client access is through the caching layer.  Additionally, I'm motivated towards a REST model for web services to support a greater degree of caching.

The new WCF Web Programming Model is ideal for this purpose as I can wrap service parameters directly into the URL and reduce the coding effort considerably.  I had been concerned about the integration of services into the same website as EPiServer because of how the URL mapping works in the Web Programming Model.

Solution

The solution is really easy once you realise that the typical EPiServer installation changes the default ASP.NET configuration.  Specifically, you may need the following:

• Create a new folder to host your services
• Create a small web.config in this folder (or use location tags in the main web.config file) and add service handlers
• Create a ".svc" file for the service
• Create the supporting .NET service code

Create a new folder to host your services

This is necessary to allow a separate application configuration.  You can change the main application configuration at your own risk, however :)

For the purposes of this post, I'll use "~/services/".

Create a small web.config for this folder and add service handlers

You'll need to add the following:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="svc-ISAPI" path="*.svc" verb="*" modules="IsapiModule" 
           scriptProcessor="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
           resourceType="Unspecified" 
           preCondition="classicMode,runtimeVersionv2.0,bitness32" />
      <add name="ServiceHost" path="*.svc" verb="*"
           type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel,
                 Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
           resourceType="Unspecified" preCondition="integratedMode" />
    </handlers>
  </system.webServer>
</configuration>

Now I took this from a cleanly created website with no configuration (using the IIS management console) and I recommend that you do the same.

Create a ".svc" file for the service

This file is created in the service folder and forms part of the URL so name it accordingly.  I'll just use "service.svc" for illustration:

<%@ ServiceHost Language="C#" Service="Service" CodeBehind="~/App_Code/service.cs"
    Factory="System.ServiceModel.Activation.WebServiceHostFactory" %>

You should name your services more appropriately, of course.

Create the supporting .NET service code

So, you need to create the classes.  Here, I'm using a simple file in the App_Code folder, but you might prefer to use a separate code project and assembly.  Here's a simple example:

using System.ServiceModel;
using System.ServiceModel.Web;

[ServiceContract]
public interface IService
{
  [OperationContract]
  [WebGet(UriTemplate = "test?s={s}")]
  string test(string s);
}

public class Service : IService
{
  public string test(string s)
  {
    return "test: " + s;
  }
}

So, this is a very basic service with a single HTTP GET method that returns some data dependent on a single query string parameter.  A perfect REST example as the result is defined by the input, there is no change of state (so two identical GET requests result in the same value) and so the response is suitable for caching.

Using the service

So now, you can access the service as http://your_episerver_site/services/service.svc/test?s=YourTestString.  ASP.NET integration (and IIS) requires the use of a service extension, in this case ".svc", however this article may help you to remove this issue: http://blogs.msdn.com/bags/archive/2008/08/22/rest-in-wcf-part-ix-controlling-the-uri.aspx but don't forget that EPiServer already does some URL rewriting and so you'll have to make sure they don't conflict!

Metadata

• Categories: ASP.NET, EPiServer, SOA, WCF, .NET, Windows Server
• Keywords: Web Programming Model, Windows Communication Foundation, Service Oriented Architecture, AJAX, JSON
• Technorati Tags: software development, Windows Communication Foundation, .NET, JSON, WCF, SOA, service design, Service Oriented Architecture, EPiServer, ASP.NET, AJAX