Hosting the WCF Service

Naveenmanam
Posted by Naveenmanam under Windows Forms category on | Views : 4779
Hosting the WCF Service
This topic outlines the basic steps required to create a Windows Communication Foundation (WCF) service that is hosted by a Windows Service. The scenario is enabled by the managed Windows service hosting option that is a long-running WCF service hosted outside of Internet Information Services (IIS) in a secure environment that is not message activated. The lifetime of the service is controlled instead by the operating system. This hosting option is available in all versions of Windows.

Windows services can be managed with the Microsoft.ManagementConsole.SnapIn in Microsoft Management Console (MMC) and can be configured to start up automatically when the system boots up. This hosting option consists of registering the application domain (AppDomain) that hosts a WCF service as a managed Windows service so that the process lifetime of the service is controlled by the Service Control Manager (SCM) for Windows services.

Once you have created this new Console Application project, add a reference to the System.
ServiceModel.dll and MagicEightBallServiceLib.dll assemblies, and update your initial code file
by importing the System.ServiceModel and MagicEightBallServiceLib namespaces:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
using MagicEightBallServiceLib;
namespace MagicEightBallServiceHost
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("***** Console Based WCF Host *****");
Console.ReadLine();
}
}
}


This console-based host will indeed make use of an application configuration file, so insert a
new Application Configuration File into your current project using the Project äAdd New Item
menu option.
Establishing the ABCs Within an App.config File
When you are building a host for a WCF service type, you will follow a very predictable set of steps-
some via configuration and some via code:
1. Define the endpoint for the WCF service being hosted within the host's configuration file.
2. Programmatically make use of the ServiceHost type to expose the service types available
from this endpoint.
3. Ensure the host remains running to service incoming client requests. Obviously, this step is
not required if you are hosting your service types using a Windows service or IIS.
In the world of WCF, the term "endpoint" simply represents the address, binding, and contract
rolled together in a nice tidy package. In XML, an endpoint is expressed using the
element and the address, binding, and contract elements. Update your *.config file to specify a
single endpoint (reachable via port 8080) exposed by this host:


<?xml version="1.0" encoding="utf-8" ?>
<configuration><BR><system.serviceModel>
<services><BR><service name="MagicEightBallServiceLib.MagicEightBallService">
<endpoint address ="http://localhost:8080/MagicEightBallService"
binding="basicHttpBinding"
contract="MagicEightBallServiceLib.IEightBall"/>
</service>
</services>
</system.serviceModel>
</configuration>





Coding Against the ServiceHost Type
With the current configuration file in place, the actual programming logic required to complete
the host is painfully simple. When our executable starts up, we will create an instance of the
ServiceHost type. At runtime, this object will automatically read the data within the scope of the
element of the host's *.config file to determine the correct address, binding,
and contract, and create the necessary plumbing:


static void Main(string[] args)
{
Console.WriteLine("***** Console Based WCF Host *****");

using (ServiceHost serviceHost = new ServiceHost(typeof(MagicEightBallService)))
{

serviceHost.Open();

Console.WriteLine("The service is ready.");
Console.WriteLine("Press the Enter key to terminate service.");
Console.ReadLine();
}
}



Host Coding Options
Currently, we are creating our ServiceHost using a constructor that simply requires the service's
type information. However, it is also possible to pass in an array of System.Uri types as a constructor
argument to represent the collection of addresses this service is accessible from. Currently, the
address is found via the *.config file; however, if we were to update the using scope as so:


using (ServiceHost serviceHost = new ServiceHost(typeof(MagicEightBallService),
new Uri[]{new Uri("http://localhost:8080/MagicEightBallService")}))
{
...
}
we would be able to define our endpoint as so:

binding="basicHttpBinding"
contract="MagicEightBallServiceLib.IEightBall"/>

the type information as we did before:
using (ServiceHost serviceHost = new ServiceHost(typeof(MagicEightBallService)))
{
...
}


One of the (slightly frustrating) aspects of authoring host *.config files is that you have a number
of ways to construct the XML descriptors, based on the amount of hard-coding you have in the
code base (as you have just seen in the case of the optional Uri array). To show yet another way to


<?xml version="1.0" encoding="utf-8" ?>
<configuration><BR><system.serviceModel>
<services><BR><service name="MagicEightBallServiceLib.MagicEightBallService">
<!-- Address obtained from <baseAddresses> -->
<endpoint address =""
binding="basicHttpBinding"
contract="MagicEightBallServiceLib.IEightBall"/>
<!-- List all of the base addresses in a dedicated section-->
<host><BR><baseAddresses>
<add baseAddress ="http://localhost:8080/MagicEightBallService"/>
</baseAddresses>
</host>
</service>
</services>
</system.serviceModel>
</configuration><BR>

Comments or Responses

Login to post response