Insert Catchy Title Here

Justin Etheredge posted a list of blogs that he follows.  He also posted a snippet of LINQ that converted his OPML file to a simple unordered HTML list.  He encouraged his readership to let him know if there are any really good blogs he was missing.  I was curious to see which blogs he reads that I have not yet subscribed to.  I tweaked his LINQ slightly to output blogs that were in his OPML file, but not in mine.

var doc1 = XDocument.Load("http://media.codethinked.com/downloads/Opml.xml");
var doc2 = XDocument.Load("http://services.newsgator.com/ngws/svc/opml.aspx?uid=134891&mid=1");

var result = new XElement("ul",
  from d1 in doc1.Elements("opml").Elements("body").Elements("outline")
  join d2 in doc2.Elements("opml").Elements("body").Elements("outline")
    on d1.Attribute("htmlUrl").Value equals d2.Attribute("htmlUrl").Value into d3
  from d2 in d3.DefaultIfEmpty()
  where d2 == null
  select 
    new XElement("li", 
      new XElement("a", 
        new XAttribute("href", d1.Attribute("htmlUrl").Value), d1.Attribute("text").Value
      ), 
      " ", 
      new XElement("a", 
        new XAttribute("href", d1.Attribute("xmlUrl").Value), "RSS"
      )
    )
  );

using (var xw = XmlWriter.Create("diff.xml", new XmlWriterSettings { Indent = true }))  
{   
  result.WriteTo(xw);
}

diff.xml will contain blogs present in doc1 but not present in doc2.  This is by no means perfect so don’t cry if it includes a few entries present in both or doesn’t work with your OPML.  You could easily see which blogs both Justin and I read by changing the where clause.

Several readers wrote to Justin asking how he could possibly keep up with that many blogs.  I only spend about 20 minutes a day reading through new posts.  Only autonomous coding machines post everyday, so as long as I don’t lapse for more than a day or two it isn’t a problem keeping up.  I also skim long posts and flag them for a more thorough reading later.  Most of my subscriptions focus on .Net development but I have a few outliers like Zed Shaw’s blog.  It can make for an extremely entertaining read (as long as you are not the subject of his attentions :).

Read about it at NHForge.org

Can someone please explain how this is possible?

NPG is dead.  Long live NHPG.  In an attempt to not duplicate information, I’m going to put most of the technical details on NHForge.  I will highlight here the improvements that have been made to NHPG since its original inception.

• Renamed NPG.exe to NHPG.exe (Duh)
• Improved error handling and informative error messages
• You can now provide several mapping assemblies at once
• Removed dependency on ActiveRecord.  Don’t cry though, you can still use it on AR assemblies.
• Now with more cowbell
• I was given the directive to support multiple proxy generation frameworks and while the design is there, you can currently get your proxies in any color, as long as it’s black.  (By color I mean framework and by black I mean DynamicProxy2)
• Improved unit test coverage.  (By improved I mean there was none and now there is some)
• Improved runtime logging (See previous bullet)
• The code now looks like a slightly more intelligent monkey wrote it
• Intermediate files are now cleaned up properly
• Proxy assembly version is now synchronized with mapping assembly version
• Working example now distributed with source

Where you can help.

• Additional proxy generation implementations
• The generation is dog slow
• The need for intermediate files mentioned above could probably be avoided by someone who knows what they’re doing

Enjoy, and please proxy responsibly.

This was way harder to find than it should have been.  There are various posts on downloading a Technical Preview that installs on Server 2008.  This installation told me it would expire shortly and it also appeared to be an older version (v12).  Some comment trolling turned up a German Windows Live Writer Blog that had what I was looking for.  The link at the very bottom installed what appears to be the latest beta for Windows Server 2008 x64.

Another loosely coupled post on Going to Production with MonoRail.

One thing I haven't stressed in recent posts is the absolute necessity to thoroughly test and understand the implications of your modifications when you start pushing a framework outside of the box.  In my post on Advanced Dependency Injection with Castle Windsor I lightly touched on the lifestyle implications of my patch to the code.  The same warning covers today's post when we start jimmy jacking with a custom connection provider in NHibernate.

If you've been following along you know that for various reasons we host multiple clients on a single instance of our B2B web application.  For other various reasons we like to keep the data for each client segregated into separate databases.  We use NHibernate for persistence ignorance so that seemed to be the logical place to start when attempting to segregate client data.  When I was doing my research it became apparent that at a high level I was trying to implement a horizontally partitioned database.  In my case, partitioned by client.  Hibernate supports horizontal database partitioning through Shards.  Dario Quintana is in the process of porting Shards to NHibernate, but I don't believe it is quite ripe yet.  Shards appears to address all of the nuances and edge cases that would reveal themselves when attempting to logically split data.  My needs were much cruder and I was willing to sacrifice a fully functional implementation (see first paragraph above though).  

Each client hosted in our application has their own configuration file.  Within this file is a database connection string that points to the database for the particular client.  As long as the database structure of each database is identical, NHibernate is cool with that.  What I ended up implementing is a custom IConnectionProvider that would load the current client's configuration, read the connection string, and create a connection using that, rather than the connection string that would normally be read from your hibernate.cfg.xml file.  The sample code gets the job done.

namespace My.Application
{
  public class ClientConfigurationConnectionProvider : DriverConnectionProvider
  {
    public override IDbConnection GetConnection()
    {
      string clientId = ClientIdProvider.Get();

      if (null == clientId)
      {
        return base.GetConnection();
      }

      ClientConfiguration clientConfiguration = ClientConfigurationManager.GetByClientId(clientId);
      string dbConnectionString = clientConfiguration.DbConnectionString;
      if (string.IsNullOrEmpty(dbConnectionString))
      {
        return base.GetConnection();
      }

      IDbConnection conn = Driver.CreateConnection();
      conn.ConnectionString = dbConnectionString;
      conn.Open();
      return conn;
    }
  }
}

Very straight forward.  By inheriting from the built in DriverConnectionProvider, most of the hard work is done for us.  To tell NHibernate to use our connection provider, a small change to the configuration file is required:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
  <session-factory>
    <!-- <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property> -->
    <property name="connection.provider">My.Application.ClientConfigurationConnectionProvider, My.Application</property>
    <property name="dialect">NHibernate.Dialect.MsSql2000Dialect</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">Server=(local);Database=MyApplication;Trusted_Connection=True;</property>
    <property name="show_sql">true</property>
    <mapping assembly="My.Application" />
  </session-factory>
</hibernate-configuration>

Remember what I said though, depending on your database structure, and the features of NHibernate you choose to take advantage of, bad and unexpected things could happen with this implementation, so do your testing.

Another loosely coupled post on Going to Production with MonoRail.

The ability to customize every aspect of an application Lego style is great, but there will always be client needs that are absolutely off the wall.  Not a customization of an existing component, but something so specific and unique to the client's domain that it cannot be encapsulated into something reusable.  My mind struggled with the paradox, how do I architect the ability to insert non-reusable functionality in a reusable way?  Mike Nichols put me on the path to my solution.

Dynamic Actions are a feature of MonoRail that allow you to decouple an action from a controller.  This sounds pretty simple but when you read through the documentation and the many ways that developers are putting them into practice, Dynamic Actions reveal their true power.  The first part of my solution: completely custom functionality is simply implemented by a class that implements IDynamicAction.  Each piece of custom functionality corresponds to a dynamic action.  The next question is how do I expose this functionality to the Client?  How do I ensure that this functionality is only exposed to the Client that paid for it?

I haven't yet posted about how we manage configuration for each client, but essentially we have an INI file (cringe! gasp! moan!) for each client hosted on a particular server.  A sample section of the INI file for the Contoso client would look like so:

[Actions]
DoWork=ContosoDoWorkAction
DoWork2=ContosoDoWork2Action

The key (DoWork) represents the name of the action, the value (ContosoDoWorkAction) is the name of a class that implements IDynamicAction and the logic for the custom functionality required by the client.  Actions are loaded into the child container for the Client during application startup.  Now we need a controller that we can attach these actions to at runtime.  This is achieved using the code sample below:

namespace My.Application
{
  public class CustomController : Controller
  {
    public CustomController(IKernel kernel)
    {
      ClientConfiguration clientConfig = ClientConfigurationManager.GetCurrent();

      NameValueCollection actions = clientConfig.Actions;

      foreach (string actionName in actions.AllKeys)
      {
        string actionTypeName = actions[actionName];
        Type actionType = Utility.GetImplType(actionTypeName);
        DynamicActions[actionName] = (IDynamicAction)kernel.Resolve(actionType);
      }
    }
  }
}

So simple it should be criminal.  With the configuration sample above and the CustomController implementation, we now have valid URLs of:

https://contoso.myb2bapplication.com/custom/DoWork.rails

https://contoso.myb2bapplication.com/custom/DoWork2.rails

At the same time, by the nature of our child container configuration magic, the following URLs would be invalid:

https://fabrikam.myb2bapplication.com/custom/DoWork.rails

https://fabrikam.myb2bapplication.com/custom/DoWork2.rails

This is because the actions are only available to the client for which they were configured.  By the same token I can disable an action by commenting out the line in the configuration file.

Who's your daddy paradox?

Another loosely coupled post on Going to Production with MonoRail.

Many moons ago I wrote a post about dynamically resolving a component from the Castle container based on runtime parameters.  There was some discussion about the limitations of the approach (the biggest is that all components that require customization or components that have dependencies that require customization must be Transient) but overall it accomplished my goals at the time.  To summarize, my implementation allowed you to load multiple components that implement the same service (say an IOrderValidator) and also allowed you to provided a predicate that would be invoked when your code resolved an IOrderValidator to allow you to choose which specific implementation to return.  The idea was that you could have multiple clients hosted on a single instance of your application, each requiring their own order validation logic.  Using a runtime parameter (like the host header) your provided predicate would resolve the IOrderValidator associated with the particular client's requirements.  This implementation worked for some time but had a few limitations, namely all components for all clients had to be loaded into the same container.  This ended up being a tad unruly to manage.  There were also some limitations on the order in which components were loaded into the container, which was problematic when auto configuring the container via code or something like Binsor.

I set out for a better solution that addressed my new requirements and ran into the related issue of scoped containers that had been proposed on the Castle mailing lists.  Scoped containers have a slightly different use case and requirements but overlapped some with the approach I ultimately settled upon.  My container contains over thirty (30) components that make up the core functionality of the application.  Some of these components have dependencies on other components and all of this management, injection, and resolution is handled nicely and elegantly by the container.  Lets say for a particular client I need to customize one of the these components.  But the component in question has dependencies on three other components, whose functionality I do not need to customize.  I need a way to add my customized component to the container, but still resolve its dependencies from the core set of components.  The answer to my problem came in the form of Child Containers.

A child container is just like your standard container only that it has an associated parent.  When you try to resolve a component from a child container, it looks at its own components to fulfil dependencies and if it doesn't find it, it asks the parent container if it can fulfil the dependency.  This sounds like just the solution I needed.  I can load all of my core components into the parent container, then load any custom components into a child container.  One glaring flaw though.  Lets say I have component A that has a dependency on component B.  I have a core implementation of both components in my parent container.  I have a custom implementation of component B in my child container.  I attempt to resolve component A from the child container.  It is not present so it is retrieved from the parent container.  When resolving the dependency of component B, the parent uses the core implementation, not the custom implementation in the child container.  I considered this a bug in the dependency resolution code and you can read about the ensuing discussion on the Castle mailing list.  This issue was also reported by Rinat Adbullin a few months back and prompted him to choose another container implementation.  I submitted a patch for my implementation but as far as I know it has not been applied.  I've heard Hammett say that child containers are the devil (my words, not his) I believe because they can introduce difficult to diagnose bugs and make dependency resolution more complicated.  For my problem they have provided an elegant solution.

To bring this implementation into MonoRail was simply a matter of crafting a custom HttpApplication that implements IContainerAccessor, and returning the appropriate child container based on the host header of the current request.  I have the base container that contains all of the core components.  I create a child container with the base as its parent for each client and load the appropriate components.  MonoRail can be configured to use Windsor to resolve all of its internal components (including your controllers).  MonoRail calls IContainerAccessor.Container to obtain the container to use for its resolution.  By providing the appropriate child container to this call, I can ensure that any custom components for the particular client are used in place of the core components.  By using the dependency resolution patch discussed above, I ensure that any core component dependencies are properly resolved against any existing customized components in the child container (code sample below).

To sweeten the deal, child containers are configured using a simple text file that can be modified at runtime to turn individual custom components on or off on a per client basis, without restarting the application.  More on that in my future post on managing configuration.

namespace My.Application
{
  public class CustomHttpApplication : HttpApplication, IContainerAccessor
  {
    private static IWindsorContainer _baseContainer;

    private static readonly Hashtable _configToContainer = new Hashtable();

    protected virtual void Application_Start(object sender, EventArgs e)
    {
      _baseContainer = new CustomContainer();
    }

    public IWindsorContainer Container
    {
      get { return GetContainer(); }
    }

    protected virtual IWindsorContainer GetContainer()
    {
      string clientId = ClientIdProvider.Get();

      if (string.IsNullOrEmpty(clientId))
      {
        return _baseContainer;
      }

      ClientConfiguration clientConfig = ClientConfigurationManager.GetByClientId(clientId);

      IWindsorContainer clientContainer = null;

      if (!_configToContainer.ContainsKey(clientConfig.Path))
      {
        clientContainer = new CustomContainer(clientConfig, clientId, _baseContainer);
        _configToContainer.Add(clientConfig.Path, clientContainer);
      }
      else
      {
        clientContainer = (IWindsorContainer)_configToContainer[clientConfig.Path];
      }

      return clientContainer;
    }
  }
}

We went to production with our B2B e-commerce product going on three months ago.  I've waited this long to write anything about it because I wanted to include in my documentation the process we used to address bugs we found after we went to the field as well as all of the interesting nooks and crannies of the architecture, what worked, what didn't, what I will do again, what I will be changing through careful refactoring, etc.  Over the next few weeks look for posts covering in some detail the topics outlined here.

Setting the Stage

This is a small application written by myself and one other dev over the course of three months.  This is not a COTS product nor is it written for a single client.  Our application provides a hosted set of core "out of the box" functionality that can facility B2B e-commerce as is, but all of our customers require some amount of customization.  When I said small, I meant small.  We average six (6) requests per second during business hours and spike to about forty (40) requests per second during peak times (moving the mouse on the server causes more CPU utilization than than the app itself :) The core application is only forty-three (43) models, six (6) controllers, forty-two (42) actions (including overloads), nineteen (19) views, and twenty-seven (27) services.  We integrate with five (5) third parties for things like credit card authorization and capture, real time shipping quotes, inventory availability, customer profile management, and order fulfillment.  We use a private build of  MonoRail RC3 with Windsor integration and Helen Keller's view engine of choice.  We use NHibernate 2 wrapped with Rhino Commons for persistence and log4net for all our logging needs.  This was a legacy application that has been in production for approximately four (4) years that originated as a classic ASP application, was ported to ASP.Net 2.0 Web Forms, then was refactored to a home grown ASP.Net 2.0 MVP framework, and is now in its current incarnation.

High Level Overview

I will be talking in volumes about the ability to customize nearly every aspect of our small application.  The reason is because all of our customers need the ability to receive an order from an end user, perform some sort of validation on the order information, then feed that order into their order fulfillment system.  The problem is that every customer has a slightly different take on end user, validation, and fulfillment system :)  Rather than write separate products for each customer or make a branch of the code for each customer we sign, our goal was to provide a core application that can be kept current, with new core features added as time goes on, and still allow any level of customization a specific customer requires.  This could be anything from re-arranging user interface elements on one or more screens, to making email address an optional field, to authorizing a credit card, but not capturing it, to feeding an order into SAP or into a legacy AS/400 order system via custom web services.  Some customizations become configuration options in the next release of the core product.  Others are so far out there they they will always remain customizations.  We also have the rare customer that happily uses the core product as is.  This model allows us to provide a tiered customization path: configuration changes can be made by operations monkey, view customizations can by made by any html monkey, and service customizations can be made by any code monkey (that's me).  So rather than giving our customer the brush off of "we will look at incorporating that in our next version", they flash us the cash and we do the deed, without affecting or breaking the core product or any other hosted customers.

The Highlights

Here are the topics I plan to touch on in no particular order.  Some will be brief others might span a few posts.  As I write the posts I will come back here and update the links and I might add other topics as I think of them.

• Managing Configuration - Me: "Check out this new feature in v5", Marketing: "That's configurable right?"
• Managing Customization - Marketing: "Customer wants to sell stuff without displaying prices", Me: "Ha ha, good one.  No...you're serious?...seriously?...are you kidding me?...are your f***king kidding me!"
  • Customizing Views
  • Customizing Services
  • Customizing Controllers
  • Customizing Actions
• Post Production - Patching, hot fixing, and tracking down bugs
• NHibernate Tricks - Poor Man's Shards
• Windsor Tricks - My Golden Swiss Army Knife
• Layout Tricks - Handling Popup Windows, Sidebars, and Error Notification
• jQuery Tricks - How do I love thee? Let me count the ways.
• Brail Tricks - I have an Orange Belt in Quack Fu

We just deployed the first phase of a new project that uses a large number of open source components including Castle (Windsor & MonoRail), NHibernate, and Rhino Commons to name the big players.  As with any project as much as I know about programming I learned even more when the rubber met the road.  Many right decisions were made, some wrong decisions were made, and the code has only been deployed for a month and I'm already making a long list of how I can do it better next time. 

One particular area that I want to get better at is staying current with dependencies.  Most OSS projects are constantly being improved and still remain stable.  Here is how my project began...I downloaded a debug build of Castle RC3, picked out the assemblies I needed, and added them to my /trunk/lib folder (What I look back on as my first mistake).  I built the latest trunk revision of Rhino Commons, and added those assemblies to my lib folder (at least I was consistent).  I then happily worked on my application, writing code, unit tests, a build script, life was good.  As we progressed in development there was a few things we needed to do in MonoRail that just didn't jive with MR conventions.  So, I synced to the RC3 branch, changed two lines of code, rebuilt, and updated my libs (second BIG mistake).  Life was good again, but then ran into a small snag with Rhino Commons.  Ok, I was able to tweak MR just a bit, so I can do the same with Rhino (see consistent, but I shoulda learned :).   Hmmm...the AI Sourcing machine has been busy and Rhino Commons has changed quite a bit since I grabbed the source last.  So I had to do some digging and diffing to find out what rev I had built from previously.  Finally I get back to the right rev (I right it down this time) make my changes, rebuild, and update my libs.  Coding progresses, but eventually I run into the same situation again, this time I actually commit a copy of the relevant (read only the projects that I need to tweak) code into our source repo (which isn't SVN to make things even more interesting) and begin to diligently comment explicitly the lines I change.  Just call me Sofa King Screwed :)

I'm a half way decent coder but I make dumb decisions sometimes.  I acknowledge that, and I want to get better.  At some point I will need to re-up my dependencies or be forever locked into an out dated version.  What I'm looking for is a better way.  What do you do with your OSS dependencies?  I've read posts where devs refer to a "private branch" which I presume to be a more organized approach to what I ended up doing.  Do you merge with the projects trunk?  How often do you merge with the projects trunk?  Are your dependencies built with your application or do you build them separately and only reference the assemblies?  Dan's post on How to Branch Properly got me thinking that may be the way to go.  Grab a trunk copy of the dependencies to be used, add them into my application's solution/build process, and merge with the trunk on a scheduled basis.  If appropriate the changes I make to my private branch can be refactored into patches to be submitted.  Is this an approach any of you have used?  Does it work?  Have you automated the trunk merge process?  We don't use SVN, but our source control solution is touted as king of merging, so I presume it would be fairly straightforward.  The other issue is when my dependencies depend on each other.  Oren makes it look easy.  This leads me to believe that the right approach is to stick with the build/reference as lib approach.  I'm willing to earn my paycheck, but if somebody already has a working solution, I'd love to hear about it.