One of the challenges I’m facing in the project I’m working on is that
we want to store configuration values for the system in a central
location that can be accessed via a service… but that’s not how most
.NET developers are used to working with configuration. Most folks are
used to
ConfigurationManager
or
WebConfigurationManager,
something like this:
NameValueCollection config = (NameValueCollection)WebConfigurationManager.GetSection("mySection");
this.SomeObject.Value = config["key"];
That’s great if everything is stored in your app.config or web.config,
but if you’ve got everything behind a service, it’s trickier. You’ve got
to get a proxy to your service, get the approriate values, handle
exceptions… it’s a lot messier, and if you’re trying to get a bunch of
devs up to speed using that, it’s going to take a bit. Wouldn’t it be
nice if they could just use the stuff they’re used to?
There are a couple of ways that can happen.
First, you can use a
ProtectedConfigurationProvider
implementation. You might be used to seeing these in the form of things
like the
RsaProtectedConfigurationProvider
that you’d use to store settings encrypted in your configuration files.
The cool thing is, the ConfigurationManager doesn’t really care what’s
stored in the <EncryptedData> element in your config. For example,
when you use the RsaProtectedConfigurationProvider, you’ll see something
like this in your config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<mySection configProtectionProvider="RsaProtectedConfigurationProvider">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>(encrypted data here)</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
<CipherData>
<CipherValue>(encrypted data here)</CipherValue>
</CipherData>
</EncryptedData>
</mySection>
</configuration>
But everything inside <EncryptedData/> is entirely up to the
configuration provider. Since you can define your own providers, what if
you did something like this:
<?xml version="1.0"?>
<configuration>
<configSections>
<section name="mySection"
type="System.Configuration.AppSettingsSection, System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</configSections>
<configProtectedData>
<providers>
<add name="ServiceConfigurationProvider"
type="Framework.ServiceConfigurationProvider, Framework"
endpointName="WSHttpBinding_IConfigurationService"/>
</providers>
</configProtectedData>
<mySection configProtectionProvider="ServiceConfigurationProvider">
<EncryptedData>
<values>
<value key="value1"/>
<value key="value2"/>
</values>
</EncryptedData>
</mySection>
</configuration>
See what we have there?
- A custom section that (for simplicity) is just a key/value section
like AppSettings.
- A custom protected config provider that has a special extra
configuration property - an endpoint name (that would correspond to
something in your <system.serviceModel> configuration).
- A section that uses the configuration provider you specified… and
notice how the contents of the <EncryptedData> are simply keys?
These are the values you’d want to retrieve from your configuration
service.
So how would you do it? You could implement a provider that looks like
this:
using System;
using System.Configuration;
using System.Xml;
using System.Xml.Linq;
using System.Collections.Generic;
using System.Reflection;
using System.ServiceModel;
using System.Text;
namespace Framework
{
public class ServiceConfigurationProvider : ProtectedConfigurationProvider
{
public string ServiceEndpointName { get; set; }
public override XmlNode Decrypt(XmlNode encryptedNode)
{
List<string> keysToRetrieve = new List<string>();
foreach (XmlNode value in encryptedNode.SelectNodes("/EncryptedData/values/value"))
{
XmlAttribute keyAttrib = value.Attributes["key"];
if (keyAttrib != null && !String.IsNullOrEmpty(keyAttrib.Value))
{
string key = keyAttrib.Value;
if (!keysToRetrieve.Contains(key))
{
keysToRetrieve.Add(key);
}
}
}
ChannelFactory<IConfigurationService> factory = new ChannelFactory<IConfigurationService>(this.ServiceEndpointName);
IConfigurationService service = factory.CreateChannel();
AppSettingsSection section = new AppSettingsSection();
foreach (string key in keysToRetrieve)
{
section.Settings.Add(key, service.GetValue(key));
}
XmlDocument doc = new XmlDocument();
StringBuilder builder = new StringBuilder();
using (XmlWriter writer = XmlWriter.Create(builder))
{
typeof(AppSettingsSection)
.GetMethod("SerializeToXmlElement", BindingFlags.Instance | BindingFlags.NonPublic)
.Invoke(section, new object[] { writer, "root" });
}
doc.LoadXml(builder.ToString());
return doc.DocumentElement;
}
public override XmlNode Encrypt(XmlNode node)
{
throw new NotImplementedException();
}
public override void Initialize(string name, System.Collections.Specialized.NameValueCollection config)
{
this.ServiceEndpointName = config["endpointName"];
base.Initialize(name, config);
}
}
}
Note that, in the above, there’s a lot I’m not doing to keep it
simple - I’m not properly closing the service channel, I’m not
handling errors in the call, etc. It’s for illustration purposes. I’m
also doing some reflection magic to get the AppSettingsSection to
serialize to XML so I don’t have to manually do it. Wouldn’t that be
nice if it was public?
The point is, you can use the protected configuration provider mechanism
to store things elsewhere - service, database, etc. Consuming something
like this would look exactly like the previous example. You’d literally
never know the difference as a consumer of the settings. The problem
with this solution is that once the value is read, it’s cached and never
re-read. Which is to say, the service will only ever get called once.
If the configuration value changes in whatever data store the service is
wrapping, you’ll never get it in your app. Also, if you wanted strong
typing, you’d have to implement a custom configuration section that
handles strong typing and that’s what your provider would return from
the Decrypt method. (Like I said, a
simple AppSettingsSection
keeps it simple.)
A solution that’s chattier but overcomes this caching issue is to
implement a special
ConfigurationSection.
In that section, you can simply have a method that wraps the service
call.
Your configuration file might look like this:
<?xml version="1.0"?>
<configuration>
<configSections>
<section name="mySection" type="Framework.ServiceConfigurationSection, Framework"/>
</configSections>
<mySection endpointName="WSHttpBinding_IConfigurationService"/>
</configuration>
It’s a little shorter, but you can still see there’s a service endpoint
name in there that’d correspond to the configuration service you’ll be
calling. You can also see that we’re using a custom configuration
section rather than one of the standard out-of-the-box ones.
The ConfigurationSection implementation might look like this:
using System;
using System.Configuration;
using System.ServiceModel;
namespace Framework
{
public class ServiceConfigurationSection : ConfigurationSection
{
[ConfigurationProperty("endpointName", IsRequired = true)]
public string ServiceEndpointName
{
get
{
return (string)this["endpointName"];
}
set
{
this["endpointName"] = value;
}
}
public string GetValue(string key)
{
ChannelFactory<IConfigurationService> factory =
new ChannelFactory<IConfigurationService>(this.ServiceEndpointName);
IConfigurationService service = factory.CreateChannel();
return service.GetValue(key);
}
}
}
Again, there’s a lot I’m not doing in there to keep it simple, but,
again, you see the idea - the GetValue method on the section wraps the
service call. Consuming this looks very similar to the original example:
ServiceConfigurationSection config = (ServiceConfigurationSection)WebConfigurationManager.GetSection("mySection");
this.SomeObject.Value = config.GetValue("key");
This version retrieves the value every time you ask for it, which gets
you around the caching issue. That said, the developer using this
mechanism should probably be made aware of what’s going on so he or she
doesn’t wonder why performance has gone down the tubes on that page that
uses 150 bajillion configuration values.
For
the printer, I ended up getting an HP Photosmart
D7260.
