text: The sample provider stores the cached data as disk files (using the same approach as my previous article), placing them in a subfolder under the root caching folder. However, one interesting feature (see Figure 1) of the sample application is the ability to define a partition or filter value that the web service can use to implement multiple separate caches without requiring you to implement multiple web services. In the configuration of the web service Cache Provider, you can specify a name for the partition that this provider will use.
  The partition name gets sent to the web service with every call from the Caching Application Block. The web service can use the partition name to store cached items in different folders on disk, in different database tables, or under different keys—depending on how you choose to implement persistent storage. The sample web service stores cached data in subfolders that correspond to the partition name.
  Creating a Web Proxy Class for the Caching Provider
  The first—and in fact the trickiest—issue in creating the provider turned out to be implementation of a suitable web service proxy. Initially, I wanted to implement a system where users could create a custom proxy and install it with the web service backing store provider simply by specifying the proxy class type within the Enterprise Library configuration.
  However, this approach turned out to be difficult, made even more so because the backing store provider would need to instantiate the proxy without previously knowing the type. While you can instantiate the proxy in that way using the Activator.CreateInstance method, figuring out how to integrate varying classes, types, and properties from a custom proxy class seemed unduly complicated.
  Generating a Web Proxy Class Dynamically
  One approach to creating the proxy would be to generate it dynamically from the web service Description Language (WSDL) document exposed by the target web site. There are well-known techniques for this; described, for example, in the MSDN article "Calling an Arbitrary Web Service." Roman Kiss wrote a comprehensive and useful article on this technique as well. You can even get a ready-built component from GotDotNet to generate web services from WSDL.
  However, it soon became clear that this approach was also overkill. The interface for the proxy and the corresponding interface of the web service are fixed by the requirements of a Caching Application Block backing store provider. So there's no need to generate the proxy dynamically; the WSDL would be the same every time.
  User-defined or Built-In Proxy?
  Other issues are determining how much variability and configurability should be available for the target web service, and making it configurable within the backing store provider, as these affect the proxy implementation. For example, should the configuration support user-defined namespaces for the web service methods? Or should it be possible to specify the namespace and the target URL at runtime?
  In the end, after much consideration, it became clear that—except for the target web service URL—the proxy does not actually need to be configurable by users. Hard-coding the namespace binding into the proxy is not unreasonable, because users can specify the required namespace binding within their custom web service classes.
  Finally, because the interface is fixed (based on the methods that a custom backing store must implement), it seemed easier to create a public Interface class that describes the interface. Visual Studio (VS) can then insert stub code for the interface into the web service automatically.
  Using the Interface class means the proxy can become a permanent class compiled into Enterprise Library. Users then need only build the web service by implementing the same interface and using the specified namespace binding.
  Building the Web Proxy Class
  The easiest way to create a web service proxy class is to use the WSDL tool provided with Visual Studio. You may need to extract wsdl.exe from your VS 2005 setup files, as it is not installed automatically with the standard installation. You need the two files wsdl.exe and wsdl.exe.config (The WSDL tool is a command-line executable and has no GUI).
  To create a proxy class with wsdl.exe, you must provide an XML schema or a WSDL document as the source. Here's one process:
  Please enable Javascript in your browser, before you post the comment! Now Javascript is disabled.
  Your name/nickname
  Your email
  WebSite
  Subject
  (Maximum characters: 1200). You have 1200 characters left.