RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Caching Data with a Web Service in Enterprise Library : Page 3

If you've ever wondered whether you might be able to use a web service to cache data—or whether it would be fast enough to be useful—wonder no more.

Designing the Web Service Interface
The interface required for communication between the backing store provider and the web service is basically the set of methods that the backing store provider must implement, such as LoadDataFromStore, Remove, AddNewItem, and Count (implemented as CachedItemCount). I modified the signatures to include the name of the cache partition, and chose to change the types to simplify transmission over the wire by using mainly Base64-encoded String and String Array types. However, this is an arbitrary decision; you can choose the types that best suit your requirements.

The following code shows the Interface class (named ICustomCacheWebService) that defines the communication interface:

   using System;
   using System.Collections;
   namespace Microsoft.Practices.EnterpriseLibrary.Caching
      public interface ICustomCacheWebService
         Int32 CachedItemCount(String partitionName);
         String AddNewItem(String partitionName, 
            String storageKey, String[] cachedItemInfo, 
            String base64ItemBytes);
         String Remove(String partitionName, String storageKey);
         String RemoveOldItem(String partitionName, 
            String storageKey);
         String UpdateLastAccessedTime(String partitionName, 
            String storageKey, DateTime timestamp);
         String Flush(String partitionName);
         String[] LoadDataFromStore(String partitionName);
         // String array:
         // @ Index + 0 = cache key
         // @ Index + 1 = last accessed date/time
         // @ Index + 2 = duration (seconds)
         // @ Index + 3 = Base64 encoded data
         // repeats in multiples of 4
Implementing the Interface in a Web Service
After creating the interface class, copy it into the App_Code folder of a new C# Web Service project in Visual Studio.

Author's Note: you must use the same language to create both the interface and the web service.

Then add the interface to the class declaration (you may need to include the full namespace-qualified names):

   public class Service : WebService, ICustomCacheWebService
Now right-click the interface name and select Implement Interface, and then click Implement Interface in the fly-out menu. This creates all the outline methods required for the web service and the web service proxy.

Author's Note: If you click the option "Implement interface explicitly" instead, Visual Studio uses the full namespace-qualified names for each member instead of just the member name.

Next, change the value of the Namespace property of the WebService attribute within the new web service from its default (http://tempuri.org/) to the namespace binding you want to use for communication between your backing store provider and the target web service(s):

   [WebService(Namespace = 
Running WSDL to Generate the Proxy Class
After the outline web service is available, open a Command window and execute wsdl.exe to generate the required proxy class. To see all the options for WSDL, type:

   wsdl.exe /?
If you are happy with the default language for the proxy class (C#), all you need enter to generate the class is a command using this syntax:

   wsdl.exe http://path-to-your-web-service/
Insert the /language:VB option before the URL if you want the proxy class generated in Visual Basic.NET instead of C#, and include the /out:file-path-and-name option if you want to generate the class file with a specific name, or in a specific folder instead of the same folder as the WSDL tool. The sample proxy provided with the samples is named CustomCacheWebServiceProxy.

Modifying the Generated Proxy Class
The generated proxy class will contain the methods exposed by the web service. As an example, here's a method that takes the partition name and the storage key of a cached item:

   public string Remove(string partitionName, string storageKey)
However, you must make a few minor changes to the class before you can use it. By default, the WSDL tool does not add a namespace to the proxy class (although you can specify one as an option if you wish). However, if you want to locate the proxy class within a namespace in your modified version of the Enterprise Library Caching Application Block, you can simply add it to the class. This is the namespace used by the Caching Application Block:

   namespace Microsoft.Practices.EnterpriseLibrary.Caching
     ... WSDL generated code here ...
Next, add the name of the interface for the custom class and web service so that you can access the proxy in your code using the interface type instead of requiring the proxy class type:

   public partial class CustomCacheWebServiceProxy 
      : System.Web.Services.Protocols.SoapHttpClientProtocol, 
To allow users to configure the URL of the proxy to point to their custom Caching Web Service, modify the proxy class constructor to accept the URL as a parameter, and set the Url property of the class to this value instead of the fixed value that WSDL generates within the constructor:

   public CustomCacheWebServiceProxy(String webServiceUrl) 
      this.Url = webServiceUrl;
Finally, if you want to use a different namespace binding from that specified in your temporary outline web service, change the value of the namespace in the WebServiceBindingAttribute near the start of the class, and in all of the SoapDocumentMethodAttribute instances on the members of the proxy class.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date