Today I explain what ChannelFactory caching in the WCF 4.5 framework is. With the help of this new feature in .NET we can cache the service instance. Microsoft has introduced a new property for the ClientBase<T> class; the property name is CacheSetting. We can set the cachesetting with the help of the CacheSetting enum.

Here are the values of the Enum:

Here is sample code for the Default CacheSetting:

class Program
    {
        static void Main(string[] args)
        {
             ClientBase<IService1>.CacheSetting = System.ServiceModel.CacheSetting.Default;
             using (ServiceReference1.Service1Client client = new Service1Client()) {

             }
        }
}

Here is sample code for the AlwaysOn CacheSetting:

static void Main(string[] args)

{

  ClientBase<IService1>.CacheSetting = System.ServiceModel.CacheSetting.AlwaysOn;

using (ServiceReference1.Service1Client client = new Service1Client()) {

   }
}

Here is sample code for the AlwaysOff CacheSetting:

static void Main(string[] args)
{
   ClientBase<IService1>.CacheSetting = System.ServiceModel.CacheSetting.AlwaysOff;


   using (ServiceReference1.Service1Client client = new Service1Client()) {

   }
}

Web Services have one great virtue: they're completely interoperable. They also have one great failing: in order to be interoperable, Web Services use a set of technologies that are guaranteed to give you, at best, adequate performance. Fortunately, WCF 4.5 has a solution: support for WebSockets.

Ever since Web Services appeared, developers have been trying to make them run faster. REST and JSON can be seen as a way of speeding things up by reducing the overhead in the messaging format used by Web Services. However, even with REST and JSON you're still moving and parsing text, which is the bulkiest and slowest data transfer mechanism; you'd get better performance if you could move binary data around. And REST and JSON don't tackle another reason for why Web Services give poor performance: HTTP, the network protocol used by Web Services. There are slower protocols than HTTP around, but no one is using them.

But performance isn't the only issue that using HTTP creates: HTTP in Web Services is tied to a request/response cycle. The reason Ajax applications make all their requests asynchronously is because if you call a service that takes a long time to complete, your request has to wait for that response before you can get your result.

On top of that, if your service has something else to tell your client after that initial response (an ongoing set of updates, for instance), then either your client has to make repeated polling calls to the service to get the result (another performance burden) or, in a non-Ajax application, you have to set up a complementary Web Service that the service can call with the updates.

A far better arrangement would be for the client to submit its request in a "fire and forget" kind of arrangement and then for the service to call back to the client when it has the data (and keep calling back if there are updates to send).

WebSockets addresses all of those issues, while still being an industry standard and therefore interoperable (confusions in vendor's implementations of the standard may interfere). In fact, your browser probably already supports WebSockets.

For most processing, WebSockets uses TCP to communicate, giving you the benefit of a faster protocol. WebSockets also supports sending both binary (for speed) and text (for interoperability). But in many ways, the best part of WebSockets is that it supports two-way communication: The client can call the service just to open communication; and after that, the service can call the client whenever it has information to share. And WCF 4.5 provides support for WebSockets.

So in the next few columns, I'm going to look at WebSockets in WCF 4.5. I'll look at the two ways you can implement WebSockets (one complicated and flexible, one simpler and less flexible) and create client a JavaScript client. Along the way I'll also discuss some of the issues you should consider in creating a WebSocket application.

Configuring the Server

One warning: You may not be able to use the code in this series, yet. As I write this (April 2012), WebSockets is only supported on Windows 8 (I worked on the 64-bit beta ISO for Windows 8 Server); even then, you'll need to configure Windows 8 to support WebSockets.

To configure Windows 8, in Server Manager, from the Manage menu, run the Add Server Roles and Features wizard. In the Wizard, you'll need to add the Web Server (IIS) role. After that, under Features, select ASP.NET 4.5 (if it isn't already selected) and, under Web Services, select HTTP Activation. Finally, under Web Services (IIS)/Role Services, select WebSockets. After finishinb the Wizard, select Local Server and set IIS Enhanced Security Configuration to off.

To work with WCF 4.5, you'll need Visual Studio 11 (again, in beta, as I write this). The first time you run it, Visual Studio 11 will probably offer to download an update; if so, take the update (I took the update and I won't guarantee that the following code will work without it).

Second warning: This may be a frustrating set of columns if you're reading them as soon as I post them. I've got a fair amount of ground to cover so, in this column, I'll only be setting up to write the code that a WebSocket service requires. But hang tough; the next column will have the code and subsequent columns will show you how to build the clients and provide an alternative way to build a WebSocket service.

Building the Service

I did my testing with a WCF Service Application Project. To take advantage of IIS's support for WebSockets that I'd just finished configuring, I went to the Web tab of my Project Properties and unchecked the Use IIS Express option so that I was testing with the "real" IIS.

Once you've set up your server and project, the first step in creating your WebSocket service is to define two interfaces: one with a single method that accepts requests from clients and another interface with a single method to send results.

For the first interface, I'll define a method that accepts an Order Id (I call the method OrderStatusById method and the interface IRequestOrderStatusUpdates). In the ServiceContract attribute on the interface that accepts requests, you need to use the attribute's CallbackContract to specify the second interface (the one with the method used to send data back to the client is ISendOrderStatus in this example). The method must accept a Message as its only input parameter and the method's OperationContract attribute must set its IsOneWay property to True and its Action property to an asterisk.

The result for my Order status example looks like this:

<ServiceContract(CallbackContract:=GetType(ISendOrderStatus))>
Public Interface IRequestOrderStatusUpdate

  <OperationContract(IsOneWay:=True, Action:="*")>
  Sub OrderStatusByID(OrderStatusMessage  As Channels.Message)

End Interface

The definition for the return method is similar, except that you don't need any special specifications for the ServiceContract attribute. I've called my method SendOrderStatus:

<ServiceContract()>
Public Interface ISendOrderStatus

  <OperationContract(IsOneWay:=True, Action:="*")>
  Sub SendOrderStatus(OrderStatusMessage  As Channels.Message)

End Interface

At this point you're ready to write the code for these methods, which I'll look at in my next column (the column after that will look at building a client).

In previous post, you can see how easy it was to add a basic HTTP Web Service to a Web site in the beta of the .NET Framework 4.5 through code: Just add a shared/static method called Configure to your service and put some code in it to configure the ServiceConfiguration object passed to the method. In fact, because of the defaults that WCF 4.5 takes for a WCF service in a Web Site you don’t really need to add any code at all. In my example I did add some code to explicitly enable my service as a basic HTTP Web Service. I also chose to configure the service to return a contract and verbose error messages (both of which are turned off by default) to support testing.

But the power of WCF is in providing multiple ways of accessing the same code–as a basic Web Service or as a high performance TCP-based service. Adding TCP access requires a change in the project type: Testing a TCP-based service from Visual Studio is awkward (at best). Instead, you’ll want to create a WCF Service library where you service is hosted by WAS rather than IIS. While that makes testing your TCP access is simplified, the defaults don’t give you a service automatically and you’ll need to use a few more lines of code.

After creating your WCF Service library project add a new WCF Service to it, giving the service some meaningful name (I used “CustomerService”). Then, to demonstrate the power of configuring by code, go to your app.config file and delete the entire system.model element. You’re now ready to control your service from code.

These two lines of code make your service available as a Web Service and as a TCP-based service (which will have orders-of-magnitude better performance than the HTTP-based Web service):

PublicSharedSub Configure(sc AsServiceConfiguration)
sc.EnableProtocol( New BasicHttpBinding) 
sc.EnableProtocol( New NetTcpBinding)

While that (in theory) makes your service accessible, it doesn’t make the information about the service (the metadata) available. As a result, you won’t be able to either use Visual Studio’s WCF Test Client or be able add a service reference for your service to another project by using the Add Service Reference dialog’s Discover button. To enable the metadata you use the same code that I had in my previous post but with one extra line of code that specifies the address where the metadata is available. In that line you create a System.URI object specifying the address (the address must reference your computer name but the port and service name are up to you) and use it to set the HttpGetUrl property:

Dim behavior As New Description.ServiceMetadataBehavior
behavior.HttpGetEnabled = True
behavior.HttpGetUrl = New System.Uri("http://localhost:1868/Customers")
sc.Description.Behaviors.Add(behavior)

You also need to add endpoints for HTTP and TCP access to your service. For that, you use the AddServiceEndpoint method on the ServiceConfiguration object passed to your Configure method. The first parameter to the AddServiceEndpoint is the type of the interface that your service implements (“ICustomers” in this example), the second parameter is the binding class for the endpoint, and the final parameter is the address itself (make sure that you use different addresses for each endpoint):

sc.AddServiceEndpoint(GetType(ICustomerService),
         New BasicHttpBinding(),
         "http://localhost:1868/Customers")
sc.AddServiceEndpoint(GetType(ICustomer),
         New NetTcpBinding(),  
         "net.tcp://localhost:1867/Customers")

There is an annoyance when you go to test your service: In a Service Library, in the absence of any entries in the config file, the test client can’t retrieve the information about the service. You’ll first get a dialog that the “WCF Service Host cannot find any service metadata”–just click the No button to continue. When the Test Client appears, it won’t display any services. You’ll need to go to the Test Client’s File menu and select Add Service to display the Add Service dialog box. In the box, enter the URL you used to set the HttpGetUrl property followed by “?wsdl” (e.g. “http://localhost:1868/Customers?wsdl”—and make sure you type the URL exactly the way it appears in your code). When you click the OK button, the Test Client will finally grab the service information and you’ll be able to test your service. The good news here is that, once you enter the URL with ?wsdl successfully, you won’t have to enter it again (you will still need to go through all the dialogs, though).

And there you go: With less than a dozen lines of code you’ve configured a service as both a basic HTTP service and TCP-based service. Adding additional access methods (e.g. named pipes, advanced web services, https) should just consist of enabling the protocol with the EnableProtocol method and adding a compatible endpoint.

The WCF 4.5 beta simplifies configuring WCF, provides better support for code-based configuration, and makes it easier to do code-based configuration in Web sites. Don’t get me wrong: I like the WCF configuration files but, I gather, I may be in a minority. Many developers prefer to configure their WCF services from code where possible. Unfortunately, one of the places where that isn’t possible is the most common place to host WCF services: in a Web application (well, I’m told it was possible but only in the sense that it’s possible to remove your own appendix).

WCF 4.5 (at least, in the beta) provides a simple solution: Add a static/shared method called Configure to your service class and fill it with the code required to configure your service. WCF will call that Configure method at the appropriate moment and pass the method an instance of the ServiceHost class. In your Configure method, you can work with that ServiceHost to configure your service.

What’s especially impressive is how simple it is. The default settings alone mean that if you add an svc file to your Web site then you have a Web Service. You can make that explicit, however, with a single line of code. This example makes the service containing this method available as a Web Service with no WCF-related tags required in the config file at all:

Public Shared Sub Configure(sc AsServiceConfiguration)
 sc.EnableProtocol(NewBasicHttpBinding())
End Sub

You can configure these services by instantiating behavior classes, configuring them, and adding them to the ServiceConfiguration’s Description property’s Behaviors collection. That’s a good thing because, while my previous example was all the code you need (in fact one more line than you needed), it’s probably not all the code you want, for two reasons.

Configuring the Service

First, with just that code you won’t be able to retrieve the WSDL contract for this service (what WCF refers to as service’s “metadata”) so you won’t be able to use Visual Studio’s WCF test client (you also won’t be able to use the Discover button in Visual Studio’s Add Service Reference dialog). For testing purposes, and until you can save to a separate file the WSDL contract that you can give to the developers building the clients/consumers for this service, you’ll want to configure your service to return a WSDL contract. To tell your service to make its metadata available you add code like the following to your Configure method. This code creates a ServiceMetadataBehavior object, sets its HttpGetEnabled property to True (that actually turns on the feature), and add the configured behavior to the Behaviors collection:

Dim behavior As New Description.ServiceMetadataBehavior
behavior.HttpGetEnabled = True
sc.Description.Behaviors.Add(behavior)

Second, by default, WCF services don’t return a lot of information in their exception messages. That’s a good thing: While that information is very useful in debugging, it probably isn’t something you want to share with the general public. However, in testing, you probably do want that those chattier error messages and you can enable the with this code in the Configure method:

Dim debugBehavior As New Description.ServiceDebugBehavior
debugBehavior.IncludeExceptionDetailInFaults = True
sc.Description.Behaviors.Add(debugBehavior)

But both of these changes highlight an issue with code-based configuration. In production, you probably don’t want your service freely giving up its contract to whoever asks for it. Instead you probably want to control access to your service’s contracts so that you have some idea who’s using your service and can contact those users when you’re making changes to your service. And you certainly don’t want to send out those verbose error messages from your production system. So, before moving your service to production you’re going to want to change the values used in this code.

The problem is that, with the code I’ve used here, there’s no simple way to inspect the assembly you’re deploying to production to determine if the settings are correct: the code is compiled and is unreadable. One of the nice features of the config files is that you could inspect them (and even change them) with Notepad. The right answer is probably to move settings that will change from one installation to another (e.g. test and production) into your AppSettings where you’ll still have visibility to them.

Please visit our site at http://www.hostforlife.eu if you need Silverlight 5 WCF RIA hosting. Starts from only €2.45/month.