Try our conversational search powered by Generative AI!

Configuring the Image Service

Product version:

EPiServer CMS 5 R2

Document version:

1.0

Document last saved:

23-09-2008

Introduction

The EPiServer CMS Image Service runs by default in the same application domain as the EPiServer CMS site. For performance and scalability reasons it is possible to host the EPiServer CMS Image Service in another process and use Windows Communication Foundation to access it.
The Image Service can be found in the EPiServer.ImageLibrary.dll assembly.

Table of Contents

Hosting the EPiServer CMS Image Service

The EPiServer CMS Image Service can be hosted in a Windows Communication Foundation enabled application. This could be an ASP.NET Web Application, a Console Application or even a WinForms Application.

See the MSDN article http://msdn.microsoft.com/en-us/library/ms730158.aspx about WCF hosting options.

Hosting with IIS HTTP / WAS

If hosting using IIS and the HTTP protocol or with Windows Activation Services (Windows Server 2008 / Windows Vista only) then a file with the svc extension should be created somewhere in the Web site. The svc file should contain the following line of code:

<%@ ServiceHost Language="C#" Debug="true" Service="EPiServer.ImageLibrary.ImageService" %>

See this article http://msdn.microsoft.com/en-us/library/ms733766.aspx for more information about hosting in IIS and this article http://msdn.microsoft.com/en-us/library/ms733109.aspx for more information about hosting with Windows Activation Services on Windows Server 2008 / Windows Vista.

Hosting with a Console / WinForms Application

In the startup code for the application, a System.ServiceModel.ServiceHost instance should be created passing in the ImageService type:

//Create a service of for the type EPiServer.ImageLibrary.ImageService
   ServiceHost serviceHost = new ServiceHost(typeof(ImageService));

Then, the service host needs to be opened in order to start the listening operation:

   //Start the service
   serviceHost.Open();

Note that the call to Open is non-blocking. Therefore, in a console application you should have code to stop the application exiting immediately:

   Console.WriteLine("Press any key to stop the service");
   Console.ReadLine();

Always close the service host before the application exits, either with an explicit call to Close() or by employing the C# using statement:

   //Close the service
   serviceHost.Close();


Hosting with IIS and a non-HTTP protocol on Windows Server 2003 / XP

Hosting a WCF service in IIS on Windows Server 2003 / Windows XP using a non-HTTP protocol (e.g. net.tcp, net.pipe) is not a scenario Microsoft support. However, it is possible and works quite well using the help of an http module.

The EPiServer.ImageLibrary assembly actually supplies such a module to support this hosting option. No user code is required for this, only configuration, which is discussed below.

The main disadvantage with this hosting method is that the requests to the WCF service do not go through the IIS HTTP pipeline and therefore have no effect on the lifetime of the web application. This means that the web application hosting the service must be activated via a normal web request in order for the http module to be called and the service host opened.

Configuring the EPiServer CMS Image Service

Windows Communication Foundation client and service can be configured from both code and configuration files. Configuration files are the most flexible as endpoint addresses and binding types can be changed without having touch the code.

Image Service Host Application Configuration

Below is a configuration example for an Image Service hosting application which uses the net.tcp protocol. The <system.serviceModel> section should be placed in the application’s app/web.config file as a child of the <configuration> section.

  <system.serviceModel>
    <services>
      <service name="EPiServer.ImageLibrary.ImageService">
        <endpoint address="net.tcp://serverxyz:8000/ImageService" binding="netTcpBinding" bindingConfiguration="ImageServiceBinding" contract="EPiServer.ImageLibrary.IImageService" />
      </service>
    </services>
    <bindings>
      <netTcpBinding>
        <binding name="ImageServiceBinding" maxReceivedMessageSize="20000000">
          <readerQuotas maxArrayLength="20000000" />
        </binding>
      </netTcpBinding >
    </bindings>
  </system.serviceModel>

If the IIS non-HTTP hosting on Windows Server 2003 / Windows XP option is to be used then the following line should also be added to the configuration file as a child of the <system.web>/<httpModules> section:

<add name="ImageServiceModule" type="EPiServer.ImageLibrary.ImageServiceModule, EPiServer.ImageLibrary" />

EPiServer CMS Site Configuration

In order for an EPiServer CMS site to actually use the remote Image Service, it also needs to have some WCF configuration in its web.config file. Assuming the Image Service has been configured to use the net.tcp protocol and is listening on port 8000/ImageService on serverxyz then the following configuration would be required:

<system.serviceModel>
<client>
      <endpoint
        name="ImageServiceClientEndPoint"
        address="net.tcp://serverxyz:8000/ImageService"
        binding="netTcpBinding"
        bindingConfiguration="ImageServiceBinding"
        contract="EPiServer.ImageLibrary.IImageService" />
</client>
    <bindings>
      <netTcpBinding >
        <binding name="ImageServiceBinding" maxReceivedMessageSize="20000000">
          <readerQuotas maxArrayLength="20000000" />
          <security mode="None">
          </security>
        </binding>
      </netTcpBinding >
    </bindings>
</system.serviceModel>

Note that the client endpoint’s name MUST be “ImageServiceClientEndPoint” as this is the name that EPiServer CMS looks for when decided if the Image Service should be accessed using Windows Communication Foundation or not.

Note that if there is no client endpoint with the name “ImageServiceClientEndPoint” then a local version of the Image Service is instantiated by EPiServer CMS in the same application domain.