Before I did that, I took a look at the wireless security options in the ADSL modem. I had a choice of WEP or WPA Pre-Shared Key (or WPA-PSK). What do these mean? A quick search on Google found a great explanation of the differences between WEP and WPA. Wikipedia of course also had a lot of information. WEP is the old protocol, the one with all the problems I remember reading about -- the one that is hackable and should be avoided at all costs! WPA is markedly better, very secure, although essentially a retro-fitted stopgap and still theoretically hackable. We have to wait for 802.11i (WPA2) for true security it seems.

WPA-PSK is the small network version of WPA, for people that can't afford a separate authentication server. It relies on a shared key that both the access point and end point must have before a wireless connection can be made. Using a simple password as the key here is a major no-no; it can be hacked using brute force. Wikipedia recommends 22 random characters, but being the security freak I am I went for the full 63.

I also engaged the other security options on my ADSL modem which I suspect won't stop a determined hacker but should make life harder. I turned off the ESSID broadcast to stop my access point advertising its presence. I also limited the MAC addresses to just my laptop's MAC address. My final super security option? I turn off the wireless LAN whenever I'm not using it... just to be safe. ;)

All I really needed was RDC, so could I run RDC by itself securely, without a VPN? Well the answer turned out to be yes, provided I beefed up RDC before I opened it up to the big bad internet. This guide does a great job listing all the things that need to be done to secure RDC for internet use. The caveat at the bottom of the guide caught my eye however. RDC uses encryption but doesn't have an authentication process to ensure you're connecting to the right computer. Basically RDC is vulnerable to man-in-the-middle attacks.

Well, being the paranoid security freak that I am, this wasn't good enough for me. I took the recommendation of the guide and looked into SSH. I found this article which describes how SSH protects against MITM attacks. Fortunately I also found the guide that I mentioned before on how to setup SSH on Windows for use with RDC. Quick, simple, secure, and with the public/private key option, very secure. Not only do I have to have the password (or passphrase) to get into my home network, I also need to have my private key in a file too, or my home workstation won't even talk to me. Very nice!

I'm happy to report the entire SSH setup works as expected too. I'm writing this post on my home workstation using RDC from across town. ;)

That's later. For now I'm amazed at how little code I'm actually writing to get this application up and running. Tables, business objects, NHibernate files, service objects (using the flexible NHibernate query language), and web forms with ObjectDataSource controls, all with very little code in them. I'm not using cheap data access code in web forms to get the UI in front of the user, this is a simple, scalable, maintainable framework I can easily add to as the feedback and additional requirements roll in. The experience is more akin to Ruby on Rails than ASP.NET 1.1 development, and I'm loving it so far.

In 1.1 I used to have to retrieve my objects myself in the code, employ all kinds of tricks to either serialize the objects in the ViewState or Session, or track the UIDs -- then re-retrieve on postback, write over the properties with the DataGrid data, blah, blah, blah. A lot of code to maintain on every page. I am wondering what 2.0 does with the objects between postbacks though... There doesn't seem to be a re-retrieve, so I suspect the objects are being serialized into the ViewState. I should really look into this and see what is actually happening -- some objects can be quite large, and if I'm showing 20 objects or so in a GridView, that can be a lot of ViewState, especially if I'm only displaying some of their properties.

The one fancy thing that I did manage to do was handle a user specified URL similar to how the MSDN Library works. This allows direct links to specific folders or files, complete with tree view synchronisation. Here is a quick demonstration of how that works...

• You can browse the Cojay code here.
• You can take a look at the Cojay configuration file here.

Feel free to download the source code for the Cojay program here. I've put it under the GNU General Public License.

I know nothing about AOP, but from this quick overview in Wikipedia it occurred to me that the Provider Pattern is a model for handling crosscutting concerns in object oriented applications. Sounds fancy doesn't it, but it's not. Crosscutting concerns are simply the things that appear everywhere in applications -- things like logging and transactions. The crosscutting concerns get tangled with and obfuscate the core business logic, a.k.a. the business logic concerns. Yeah, everything is a concern in AOP...

Now I don't want to get into join points, pointcuts and weaving too much, except to say that weaving is the process of injecting the advice in aspects into join points -- basically getting the centralised logging and transaction code where it's supposed to be. Wikipedia lists five possibilities for weaving...

• A source pre-processor.
• A post processor that patches binary files.
• An AOP-aware compiler that generates woven binary files.
• Load-time weaving.
• Run-time weaving (trap each join point at runtime, and execute all relevant advice).

The first four are beyond the abilities of a lowly C# developer, but the fifth one there rings a bell. By using providers, we've identified our join points with generic provider code. The advice in our provider is weaved into the application code when the generic provider code is reached. Maintenance of, revamping, or even replacing crosscutting concerns becomes much, much easier -- as long as you don't want to change the provider interface.

Of course, the core business logic is still obfuscated with the generic provider code, so that goal of AOP isn't fulfilled by the Provider Pattern at all. But at least it's easier to maintain to some degree.

Does any of this make sense? How about a point?

Well my point I guess is this. In defining the Provider Pattern perhaps some of this AOP language can be adopted. It seems to me there is a whole swag of named concepts in AOP that relate closely to what the Provider Pattern actually does. Thoughts?

• What is a blog and where did blogs come from?
• What kind of blog software is available for running a blog?
• Using a blog client to post entries (optional).
• Reading blogs with a news aggregator.
• Finding a news aggregator.

If you're interested in starting a blog, don't forget to check out web syndication and Creative Commons as well. Of course the Creative Commons website is also a good place to go. :-)

For those of you new to blogging (like me), here is a really good definition of web syndication and an explanation of what Atom and RSS feeds are all about. While my Atom and RSS feeds could be used for a variety of (license compliant) purposes (Movable Type automatically includes my Creative Commons license in the feeds), I've mostly provided them for the majority of blog readers out there that use some form of aggregator. Let's face it, I don't blog every day, so why not make it easy for folks to automatically get my content when I finally do write something? It can be a pain clicking on a website several times a week just to find nothing new has been posted.

(Did I mention that my Optimising Movable Type for Google post is back in the rankings? Probably not, since I decided I wouldn't blog about that stuff anymore. I don't know what's changed, but it's up there.)

The full analysis is interesting reading, but in the end it mostly confirms what we already know about search engine optimisation. Organic growth of good content will lead to high quality links, which in turn will lead to a handy search engine ranking. The optimisation tips help, but good content is much more important.

The article points out a couple of pitfalls though. One is the length of the domain name registration as already mentioned. The other (well known one) is knowing who is sharing your hosting server. If you neighbour is engaged in dodgy search engine spam tactics, your shared IP address might be banned. Could be a case for getting your own IP block whether you're sharing a server or not.

Thanks to Craig for sending me this link.

Update: 23 June, 2005

There is some interesting discussion on the Google patent here. The actual patent application can be found here.

It occurred to me that some applications might not need their plugins instantiated straight away. The instantiation of plugins as they're needed shouldn't be a feature of just the ProviderSectionHandler class alone, so I've made this the default behaviour of the PluginSectionHandler class instead. Since this was the only difference between the PluginSectionHandler class and the ProviderSectionHandler class, there's no need to keep the ProviderSectionHandler class anymore. It's gone.

So, the updated PluginSectionHandler class now behaves exactly the same way as the old ProviderSectionHandler class did. And a new class, the PluginInfoDictionary class, bridges the gap between the new and old behaviour of the PluginSectionHandler class.

To switch from the ProviderSectionHandler class to the PluginSectionHandler class, provider configuration information should change from something like this...

<configSections>
    <sectionGroup name="example">
        <section name="persistenceProviders" type="SevenCamels.Framework.Configuration.Providers.ProviderSectionHandler, SevenCamels.Framework.Configuration" />
    </sectionGroup>
</configSections>

To something like this...

<configSections>
    <sectionGroup name="example">
        <section name="persistenceProviders" type="SevenCamels.Framework.Configuration.Plugins.PluginSectionHandler, SevenCamels.Framework.Configuration" />
    </sectionGroup>
</configSections>

The actual provider configuration section won't need to change. It should continue to look something like this...

<example>
    <persistenceProviders default="SqlPersistenceProvider">
        <add key="SqlPersistenceProvider" type="Example.PersistenceProviders.SqlPersistenceProvider, Example">
            <constructorParameter name="connectionString" type="System.String">blah, blah, blah</constructorParameter>
        </add>
        <add key="XmlPersistenceProvider" type="Example.PersistenceProviders.XmlPersistenceProvider, Example">
            <constructorParameter name="fileName" type="System.String">blah, blah, blah</constructorParameter>
        </add>
    </persistenceProviders>
</example>

The PluginSectionHandler class now returns the new PluginInfoDictionary class, so provider factory constructor code should change from something like this...

static PersistenceProviderFactory()
{
    _providerInfos = (PluginDictionary)ConfigurationSettings.GetConfig("example/persistenceProviders");
}

To something like this...

static PersistenceProviderFactory()
{
    _providerInfos = (PluginInfoDictionary)ConfigurationSettings.GetConfig("example/persistenceProviders");
}

The provider factory creation code won't need to change. It should continue to look something like this...

public static IPersistenceProvider Create()
{
    // Find the configuration information for the default provider.
    PluginInfo providerInfo = _providerInfos.Default;

    // Instantiate it and return it.
    return (IPersistenceProvider)providerInfo.Instantiate();
}

Plugins aren't automatically instantiated anymore, so plugin code should change from something like this...

PluginDictionary rules = (PluginDictionary)ConfigurationSettings.GetConfig("example/rules");

To something like this...

PluginInfoDictionary ruleInfos = (PluginInfoDictionary)ConfigurationSettings.GetConfig("example/rules");
PluginDictionary rules = ruleInfos.Instantiate();

Note that the PluginSectionHandler class no longer returns a dictionary of instantiated plugins, it just returns the plugin configuration information instead. Getting actual instances requires the extra step of calling the Instantiate method on the PluginInfoDictionary class. Of course, if you don't need to instantiate all the plugins at once, you can call the Instantiate method on the individual PluginInfo objects instead...

PluginInfoDictionary widgetInfos = (PluginInfoDictionary)ConfigurationSettings.GetConfig("example/widgets");
...
Widget defaultWidget = widgetInfos.Default.Instantiate();
...
Widget myWidget = widgetInfos["MyWidget"].Instantiate();

Key the Constructor

The second change to the library was to make each plugin take its key as its first constructor parameter. This is mostly a precaution in case an exception is thrown in the constructor of plugin. By having the key available in the constructor, it can be included in the exception message -- which can be crucial to figuring out which plugin actually went wrong.

Plugin (and provider) constructors should move from something like this...

public Rule()
{
    Key = string.Empty;
}

To something like this...

public Rule(string key)
{
    Key = key;
}

Not a big change.

Typed Collections

The final change was to make all the collection classes (ConstructorParameterInfoList, PluginDictionary and PluginInfoDictionary) typed. This makes them a bit easier to use -- although they were a pain to write.

That's mostly what the SectionHandler class deals with. It has an abstract property for the XSD (the complete XSD, not a filename) which the concrete classes implement. It takes that XSD and applies it to the configuration section using a standard XmlValidatingReader. If the reader finds any discrepancies, an informative ConfigurationException is thrown. One nice thing about the ConfigurationException class is that if you provide it with the XML node where the error took place, it will translate that into a configuration file line number -- and that makes debugging the configuration file for the end user so much easier.

The next class is the DictionarySectionHandler class. The PluginSectionHandler class (which we'll talk about next) works very similar to the DictionarySectionHandler class in the .NET framework in that it uses add, remove and clear XML elements to add, remove and clear plugins from its dictionary collection. It really makes sense to subclass from the .NET DictionarySectionHandler class and override its methods to handle the more detailed add XML elements (you might want to take a look at the "app.config" file in the Example program to see the kind of add XML elements I'm talking about). Unfortunately the DictionarySectionHandler class doesn't provide enough members to override, so I quickly whipped up my own. There's no real reason to use it over the .NET framework version -- it's mostly there for subclassing.

Finally the meat of the library, the PluginSectionHandler class. By now you should be familiar with how section handlers work and specifically how the DictionarySectionHandler class works. Every time it finds an add XML element, it reads it and adds what it finds to a dictionary collection, which eventually gets returned to the calling code. The PluginSectionHandler class works in exactly the same way -- there's just a bit more to read when an add XML element is found. Rather than read all this configuration information itself, it passes this responsibility along to the PluginInfo class which uses the add XML element to initialise itself. Once the PluginInfo is constructed and no errors are found, the PluginInfo is used to instantiate the actual plugin. The new plugin is then added to the dictionary collection.

That's one of the key differences between how I've implemented the Plugin Pattern and the Provider Pattern. Plugins are always instantiated and returned in a dictionary collection for the calling code to use. Providers are a bit more discretionary in that they only instantiate the actual provider when it's requested. As a result the ProviderSectionHandler (coming up) hangs on to the provider configuration information instead of the instantiated providers themselves. The provider factory does the instantiating later.

The PluginInfo and ConstructorParameter classes are pretty straight forward. They receive an XML element when they're constructed which they read to initialise themselves. The PluginInfo class is mostly interested in its key and type. The key differentiates it from other plugins and the type defines what the plugin is actually going to be when instantiated. Valid type strings can be anything from a simple type name, to a full name, to an assembly qualified name. If you're sure the assembly is already loaded before the application reads this configuration information, I'd recommend at least a type full name, otherwise bung in the name of the assembly as well. If there's multiple versions of the same assembly floating around, go for the assembly qualified name instead. Here are some examples:

• Type.Name

  ExampleClass

• Type.FullName

  XYZ.Example.ExampleClass

• Type.FullName w/ Assembly Name

  XYZ.Example.ExampleClass, XYZ.Example

• Type.AssemblyQualifiedName

  XYZ.Example.ExampleClass, XYZ.Example, Version=1.0.1983.25223, Culture=neutral, PublicKeyToken=null

The add XML element can contain zero or more constructor parameter XML elements representing the parameters for one of the plugin type's public constructors. The PluginInfo class passes the responsibility of reading these XML elements along to the ConstructorInfo class. The ConstructorInfo class is interested in the name (which isn't really used, it's more for the user), the type and the inner text representing the string value of the parameter. The constructor parameter type can really be anything as long as it has a TypeConverter that can handle conversion from strings. Note, the number and type of constructor parameters must match the signature of one of the plugin type's public constructors.

Finally, the ProviderSectionHandler class. There isn't a lot of difference between this class and the PluginSectionHandler class for the reasons I've described above. Just one method is overriden -- and that is to store the provider configuration information (a PluginInfo) in the dictionary collection instead of the instantiated provider itself.

At first glance the Provider Pattern seems to be the Plugin Pattern renamed. Take a look at this excerpt from the first article.

[A] provider is the implementation of [an] API separate from the API itself. For example, the new Whidbey Membership feature has a static method called Membership.ValidateUser(). The Membership class itself contains no business logic; instead it simply forwards this call to the configured provider. It is the responsibility of the provider class to contain the implementation for that method, calling whatever Business Logic Layer (BLL) or Data Access Layer (DAL) is necessary.

There are some key concepts in there, mainly the separated interface/contract, multiple implementations to meet the contract, and the specific implementation configured at runtime. This runs very close to the Plugin Pattern by David Rice and Matt Foemmel described in Martin Fowler's book, Patterns of Enterprise Application Architecture. Here's an excerpt from that book describing how to implement the Plugin Pattern.

The first thing to do is define with a Separated Interface any behaviors that will have different implementations based on runtime environment. Beyond that, we use the basic factory pattern, only with a few special requirements. The Plugin factory requires its linking instructions to be stated at a single, external point in order that configuration can be easily managed. Additionally, the linking to implementations must occur dynamically at runtime rather than during compilation, so that reconfiguration won't require a rebuild.

To me the Plugin Pattern basically boils down to a Strategy Pattern with the chosen strategy configured at runtime. The Provider Pattern definitely falls within the realm of the Plugin Pattern as described, but is in fact a more specialised/hybrid version. Take a look at the first excerpt again, specifically at the mentions of an API, business logic layers and data access layers. The provider itself sits between a defined API (the contract/interface) and the business logic / data access layers of an application/subsystem. This is kind of like a reverse Service Layer Pattern. The Service Layer Pattern by Randy Stafford (again from PoEAA) is described as this.

A Service Layer defines an application's boundary and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations.

The Service Layer Pattern deals with the allowed operations on an application or subsystem by one or more external clients. It's purpose is to protect the application/subsystem from external clients but also to make it relatively easy to add or switch clients for an application. I say the Provider Pattern is kind of like a reverse Service Layer Pattern because it instead makes it relatively easy to switch business logic and data access code for an application instead. It's theoretically possible to use the Provider Pattern to substitute the entire guts of an application leaving only the client the same; but, in reality, the pattern typically only deals with one small part of the application, like the Membership example given by Rob Howard in the first excerpt. From the perspective of the proposed Membership provider, there is a real service layer involved since the Membership provider would be used by multiple clients. The service layer just happens to be identical across multiple concrete implementations of the Membership provider.

So there you go. The Provider Pattern is unique in that it defines the API for a complex subsystem, with a view to substituting that subsystem through the use of configurable plugins. In this day and age of making applications work with multiple storage technologies and integrating with an infinite variety of other applications, a pattern that deals with this kind of subsystem substitution is helpful. With a consistent set of APIs for common subsystems, applications can even focus on their core proficiency and leave the subsystem implementation to existing libraries, and as a nice little ancillary benefit, remain open to future libraries and technologies without having to recompile.

The SevenCamels.Framework.Configuration Library

Without boring you to tears, here is something for you to actually look at. Included in this download is my new SevenCamels.Framework.Configuration library, recently revamped to support the Provider Pattern, and a small Example program to demonstrate both plugins and providers. The SevenCamels.Framework.Configuration library is licensed under the GNU Lesser General Public License, and the Example program is licensed under the GNU General Public License. The links take you to the human readable summaries of these licenses on the Creative Commons website. I won't bother talking about the licenses other than to say the GNU LGPL allows the free use of the library in any application, commercial or otherwise, with only a few conditions. You're also free to modify the source code.

Okay, lets actually talk about the SevenCamels.Framework.Configuration library. This library primarily deals with the reading of configuration files, specifically the reading of plugin and provider configuration information. This is something it does through custom section handlers, classes that implement the IConfigurationSectionHandler interface. There are two main classes in the library, the PluginSectionHandler and the ProviderSectionHandler. They're very similar to each other in the way they work. The PluginSectionHandler class returns a dictionary collection of instantiated plugins, while the ProviderSectionHandler class returns a dictionary collection of provider configuration information with a view to actually instantiating the providers later on request. I won't get anymore specific than that for now, instead I'll save the details for another post. Let's move on the Example program to see how the library can be used.

The Example Program

To show off both plugins and providers, the Example program will simulate an email gateway service. The idea is to take emails previously saved, apply rules to them, and then send them off. Our provider example will be in the persistence mechanism for the emails, SQL Server or XML file. Our plugin example will be in the rules we apply to the emails. Rules can be written by anyone and "plugged into" the application through the configuration file. We're interested in all rules defined and we only need one instance of each -- perfect for the PluginSectionHandler to deal with.

As you can see in the code, providers still need a lot of work to get going. The library above helps with getting the configuration information out of the configuration file, it doesn't actually do much of what makes up a provider. The first thing to do is define the seperated interface/contract. This can either be an interface like the IPersistenceProvider interface, or an abstract class like the abstract PersistenceProvider class. I've provided both to demonstrate what they would look like. Other implementations of the Provider Pattern can use one or the other (or both) -- Rob Howard seems to favour the abstract class approach which makes sense if there is a lot of common code.

The next thing to do is create a provider factory class. Rob Howard's example code had a factory method on the abstract MembershipProvider class instead, but I prefer to seperate out the responsibility for instantiating the provider from the provider itself. This lets the provider class focus instead on what it's providing and not be cluttered up by factory code. Either approach is fine, it's a personal choice. The factory class reads the provider configuration information and stores it away for when it's needed, similar to the caching code in Rob Howard's example. The factory class also has a static Create method which uses the default provider's configuration information to instantiate it. The new instance of the default provider is then returned to the calling code. Not a lot to it.

That's pretty much all that would be standard between different implementations of the Provider Pattern. Some kind of interface/contract, and some kind of factory process. The rest of it, the actual providers, is academic. In the Example program the SqlPersistenceProvider and the XmlPersistenceProvider classes simply serve up a fake email for demonstration purposes.

So once the Example program has an email, it needs the rules to apply to them. Here the PluginSectionHandler comes into play, reading the plugin configuration information, instantiating the plugins, and returning them as a dictionary collection. The SevenCamels.Framework.Configuration library really makes this easy. Our plugin classes can have multiple public constructors (like the RedirectRule class does) which we can easily switch between simply by changing the number and type of constructor parameters in the configuration file.

In case you're wondering, the rules in the Example program implement the Decorator Pattern (GoF, sometimes called the Wrapper Pattern). The email is wrapped by a rule, which itself is wrapped by another rule, and so on. Each rule exposes the public properties and methods of the object it wraps, altering only those that it needs to (effectively "decorating" it). The rules in the Example program override the properties they're concerned with and may alter the value of the properties depending on the rule itself and its criteria. Take the RedirectRule class for example. If its criteria match (and it always does for demonstration purposes), the To, CC and BCC email addresses are altered -- effectively "redirecting" the email.

To see how easy it is to configure an application that makes use of the Plugin and Provider Patterns, try altering the configuration file. Switch the default persistence provider, comment out rules, even add an extra rule. Try to break the application by altering the types, or by setting up constructor parameters that don't match a public constructor. You should get nice, informative error messages.

And that's all. If you have any questions, feel free to email me at adam@sevencamels.com. If you find any bugs or have any suggestions, please pass them along.

Now take a look at the search results with the "omitted results included". There's my post, just after the third post that I trackbacked to. You're probably familiar with the phrase "omitted results included". That's because Google usually has a line similar to this at the end of every search...

In order to show you the most relevant results, we have omitted some entries very similar to the 190 already displayed. If you like, you can repeat the search with the omitted results included.

I've actually read about this happening to someone else. The web designer for a carpet cleaning site kept a copy of their work on their own site. Google saw identical content and removed one of the sites from its search results. Unfortunately it chose the wrong one (I imagine there was a bit of abuse from the carpet cleaning company after they realised what had happened).

Anyway, it looks like something similar has happened to me. By putting four trackbacks out there, three of which are on posts that have ended up ranking higher than mine, Google has decided my post is too similar to the others and has omitted it from the search results. All based on my post's title and the tiny excerpt that gets passed along with the trackback. Damn trackbacks!

There's not a lot I can do about it apart from change the first paragraph of my post in an attempt to avoid being "very similar". Alternatively I could email these very nice people and ask them to remove my trackbacks from their posts. Or perhaps I should just stop caring about my Google rank and start blogging about something actually worthwhile. Yeah, I might give that a go instead.