Finding an instance of an object, s= uch as an Abstract Factory implementation, is a common task. Early in a software product’s life, we tend to use a static factory method. It works but, it creates a depende= ncy chain from the assembly containing the consumer of a service and the assemb= ly containing the supplier of a service.

There are a number of ways of breaking that dependency chain. One of the more flexib= le solutions is to dynamically load the assembly and use reflection to instant= iate a service provider. This is t= he solution that Common Components provides.

One of the easiest ways to break the dependency betwee= n the consumer and provider of a service is to inject and abstract type, such as = an interface, in between the two. The consumer, then references only the interface, and we are free to make chang= es to the implementation as needed.

If you go only that far, you’ve done yourself a = great service. Inverting dependenci= es is one of the more important kinds of encapsulation. You’ll find that most of the Design Patterns employ this principle to realign the forces at play in your favor. However, you can go on= e step further and, at Hexagon Software, we choose to do so.

Inverting Binary Dependencies

Inversion of dependency, alone, is not sufficient to b= reak the binary dependency between a consumer and a provider. A dependency between binaries works pretty much the same as a dependency betw= een types: a change in the dependency object requires the dependent to be recompiled. So, if a type fro= m one assembly references a type from another, then there is a dependency from the former to the latter. Figure 1 depicts dependencies between a two binaries when a concrete type is directly consumed. Figure 2 depicts how those dependencies are impacted by injecting and interface betw= een the consumer and provider of a service.

Figure 1 – Dependencies before type-dependency inversion

Figure 2 – Dependencies after type-dependency inversion

The reason why simply inverting the relationship betwe= en a client and a server is not sufficient is that the server must still be instantiated. Even if youR= 17;ve encapsulated construction of the service, all you’ve really done, from the binaries’ perspective, is hide a reference to a concrete type. What you need to do is eradicate that reference altogether.

“Glue” Assemblies

One option is to move all of the references to concrete types into a third assembly. = This assembly can be thought of as a “Bootstrap” assembly which is responsible for brokering the connection between a client and a server. This is an excellent option when:<= /p>

· You want, or at least don’t mind, comp= iler involvement in controlling the relationship between consumer and provider objects

· Consumers do not initiate the construction of new providers (all of the required service providers can be predicted up fr= ont

· Changing service providers is simple or automatic – for instance when the difference between one service prov= ider and another is merely version and the compiler will maintain references app= ropriately

It has weaknesses, though:

· You have to deploy a new “glue” assembly whenever you roll out a new implementation

· Dynamism is difficult to effect

· It is hard to give the client an opportunity= to instantiate new services

· You have to have knowledge of your consumer – this is impossible in the case where you are a components vendor un= less you have an almost codependent intimacy with your customers

· You must deploy a new “glue” assembly whenever you change the client or the server

Figure 3 – Using a “glue” assembly = to invert binary dependencies

Using Reflection

A more flexible solution is to use reflection. Reflection allows you to, among ot= her things, dynamically load and instantiate types. This makes reflection a powerful t= ool in the War on Dependencies. Ther= e is really only one advantage of this type of design: it’s extremely flexible. You don’t hav= e to change any binaries in order to change the type used to provide a service.<= /p>

We’ll list the disadvantages below and then we w= ill see how easily they are mitigated:

· The compiler won’t check your referenc= es for you

· It can be cumbersome to write over and over<= /p>

Compiler reference checking is overrated. It does a good job of proving that= an interface is properly respected by either a client or a server but it is ju= st a hair shy of useless when it comes to proving your software behaves correctly. If you are interes= ted in this product, you are probably already using TDD anyway, which does a fine = job of implicitly checking your assembly references. After all: if you’re not loa= ding and instantiating your types correctly, how can any of the tests pass?

If something is burdensome to write and rewrite, the e= asiest solution is to just write it once in a way that will prevent is from having= to write something similar ever again. This is the solution we provide with the HexagonSoftware. Bootstrap.Contracts assembly. As of now, this is the only solution we provide that doesn’t span multiple assemblies.

There’s Always a Catch

There is a small irony surrounding this assembly in th= at it is designed to help minimize dependencies between concrete types and, yet, = in order to use it you must directly reference its concrete types. This has much to do with the way t= hat Microsoft’s configuration framework operates – it is very heavily concrete-type-centric.

We like to think of it as the Las Vegas of software development: It’s a focal point for the sin of concrete-type dependency. To an extent, it’s a necessary evil: = Using reflection to instantiate objects is not a very complex problem, we need a degree of certainty in the authorship of the code we use, and MicrosoftR= 17;s configuration mechanism (the natural choice for writing a configuration-dri= ven application) is not up to the challenge of dealing with anything more sophisticated.

The Key Players

What are the most important parts of the Bootstrappe= r?

Minimally, there are four players involved in breaking= the binary dependencies on any given service:

· The generic Service Locator (a Singleton provided by us)

· A configuration file (sometimes provided by = you, sometimes ambient)

· The service object provider (which you build= )

· The service provider (you build this)

Additionally, it is a best practice to encapsulate all= of this with a fifth entity. This simplifies the process of obtaining an object from the consumer’s perspective. We tend to name = this object <ContractOfWhatItFinds>Locator. So, if you are going to provide an object that implements the Factory interface, you would call the locator FactoryLocator.

The Assumptions

What are the basic operating assumptions of the Bootstrapper?

It is assumed that a software system has the following characteristics:

· Only minimal dependencies on concrete types = that you want to access via the Bootstrapper

· Abstract types (interfaces or base classes) = live in a separate assembly from their implementations

If you aren’t doing these things, it is strongly recommended that you consider them; if you like, you might keep reading jus= t to see what kind of benefits you stand to gain from adopting such practices.

The Simplest Case

What’s the shortest path I can take to start u= sing the Bootstrapper?

We’ll start with the simplest implementation possible. In sections to come= , we will find ways to make our design more tolerant of variation in our deploym= ent and consumption strategies. F= or now, we will assume that you are going to put the service provider in the Global Assembly Cache and that it is acceptable for consumers to directly access the generic Service Locator.

The first thing we will need is, of course, our service. We will make a small= class that serves up string messages for different cases. Listing 1 demonstrates how the contract and implementation of this service might be written.

Listing 1 – A service provider that hands= out strings

// Contracts.dll

namespace Contracts

{

pu= blic interface S= tringServer

{

string GetMaximumConnectionsExceeded();

string GetAccountExpired();

}

&nb= sp;

// Implementations.dll : Contracts.dll

namespace Implementations

{

pu= blic class Strin= gServer : Contracts.StringServer

{

private StringServer() { }

&nb= sp;

public static Contracts.StringServer GetInstance()

{

&= nbsp; return new StringServer();

}

&nb= sp;

public string GetMaximumConnectionsExceeded()

{

&= nbsp; return "We c= annot accept any more connections.";

}

&nb= sp;

public string GetAccountExpired()

{

&= nbsp; return "Our = records show that your account has expired.";

}

Now that we have a service, we need an Object Construc= tor that will provide an instance of it. The reason for this will become clear in future sections of this tutorial. Listing 2 shows what this looks like.

Listing 2 – An Object Constructor = of StringServer

namespace Implementations

{

using Bootstrap =3D HexagonSoftware.Common.Boot= strap;

public class = StringServerConstructor : Bootstrap.ObjectConstructor

{

= ; public object Create(Bootstrap.ObjectCreationArguments creationArguments)

= ; {

= ; return StringServ= er.GetInstance();

= ; }

}

Next we will need to register our service with the gen= eric Service Locator. Since this i= s the first time we’ve done this, we will have to both register the Hexagon Software configuration section. Listing 3 shows how to register the Hexagon Software Objects configuration section group. Listing 4 takes that one step further and registers our service provider.

Listing 3 – An example app.config = that registers the Hexagon Software Objects configuration section

<<= /span>sectionGroup name=3D"= HexagonSoftware">

&= nbsp; <section name=3D"= Objects"

&= nbsp; type=3D"= HexagonSoftware.Common.Bootstrap.ObjectRoleDescription= s, &= nbsp; &= nbsp; &nbs= p; HexagonSoftware.Common.Bootstrap"/>

</= sectionGroup>

</configSections>

</configuration>

Listing 4 – An example app.config = that registers our service provider

<<= /span>sectionGroup name=3D"= HexagonSoftware">

&= nbsp; <section name=3D"= Objects"

&= nbsp; type=3D"= HexagonSoftware.Common.Bootstrap.ObjectRoleDescription= s, &= nbsp; &= nbsp; &nbs= p; HexagonSoftware.Common.Bootstrap"/>

</= sectionGroup>

</configSections>

<<= /span>Objects>

&= nbsp; <Add Name=3D"= StringServer"

&= nbsp; ConstructorType=3D"

&= nbsp; Implementations.StringServerConstructor,

&= nbsp; Implementations,

&= nbsp; Version=3D1.0.0.0,

&= nbsp; Culture=3Dneutral,

&= nbsp; PublicKeyToken=3Dnull " />=

</= Objects>

</HexagonSoftware>

</configuration>

Now we are ready to start consuming the services of StringServer. At this point, = we have yet to add an encapsulation that hides the involvement of the Bootstrap assembly so we will have the consumers of our service directly interface wi= th the generic Service Locator.

When a request is made to the Service Locator, asking = for an instance of the object Named “StringServer,” the Service Lcoator will create an instance of StringServiceConstructor and ask it to make an object. Whatever StringServic= eConstructor produces will be returned to the consumer that initiated the request. We’ve intentionally left some details out, at this juncture, and we’ll get to them in the near futu= re but that’s how it works in the proverbial “perfect world.”= ;

The generic Service Locator is a Singleton. You reference it via its only stat= ic property: “Instance.” Once we have a reference to an instance of ServiceLocator, we use the GetInstanceOfObject method to retrieve an instance of StringServer as demonstrated by Listing 5.

Listing 5 – Using ServiceLocator t= o find an instance of an object

using HexagonSoftware.Common.Bootstrap;

StringServer stringServer =3D

ServiceLocator.Instance.GetInstanceOfObject<StringServer>("StringServer");

Note that the GetInstanceOfObject method is actually a “generic” method, mean= ing that it’s a parametricly polymorphic family of methods. The type parameter tells the ServiceLocator the interface to which you expect the resulting object to perform. While that provides = you with the “syntactic sugar” of not having to downcast, as we’ll see in later sections, there is more to it than just encapsulat= ing a cast.

We now have an instan= ce of StringServer and we did so without having to reference Implementations.dll. However,= it can get better. For instance,= we can hide the Bootstrapping process from our consumers for ease of use and to make it easy to provide a different solution should the need arise. This is what we will do next.=

Encapsulatin= g the Bootstrapping Code

How do I make it easy for clients to find my service= ?

This is a relatively short section. It is a best practice to encapsula= te anything that might change that includes the methods of construction. One could go so far as to say “that goes double for construction.” Even tho= ugh the actual construction of the concrete instance has been encapsulated, it = is still recommended that you create a static method, somewhere, that hides all Bootstrap code and any support code.

Beyond the fact that this will increase encapsulation = (and cohesion, for that matter): it also increases readability. Which is easier to remember or rea= d: the code in Listing 5, or “StringServerLocator.GetStringServer()?” Listing 6 shows how such a utility class might look.= As our example grows to be more sophisticated, you will find that th= is seemingly trivial addition to our family of classes will prove indispensabl= e.

Listing 6 – An encapsulation that = uses the ServiceLocator to find an instance of StringServer

namespace Contracts

{

us= ing HexagonSoftware.Common.Bootstrap;

&nb= sp;

pu= blic static class StringServerLocator

{

public static= StringServer GetStringServer()

{

&= nbsp; return ServiceLoc= ator.Instance

&= nbsp; .GetInstanceOfObject<StringServer>("StringServer");

}

Configurabil= ity

Can I make it so that configuration data impacts construction of my service?

It is cumbersome to have to vary certain things in code. Our string server is a perfect example. There’= s no reason why we need to write a new class for each set of strings. We definitely want to reserve the = right to do so. For instance: we ma= y, some day, want to draw from a resource file. Nevertheless, there is no reason we should have to write a new class every time we want to change our strings.&= nbsp; …so, let’s go ahead and change how that works. The Bootstrapper gives us the abil= ity to vary data through XML as part of our configuration data.

This time, we’ll start with the configuration fi= le because we already have a basic understanding of the Bootstrapper’s larger moving parts. The Bootstrapper’s configuration schema allows for a free-form XML snippe= t to be added to the configuration of any object. Listing 7 shows how we’ve modified our configuration file to contain the strings served up by StringServer.

Listing 7 – How our configuration = with some object-specific data in it

<<= /span>sectionGroup

&= nbsp; name=3D"= HexagonSoftware">

&= nbsp; <section

&= nbsp; name=3D"= Objects"

&= nbsp; type=3D"=

&= nbsp; HexagonSoftware.Common.Bootstrap.ObjectRoleDescription= s,

&= nbsp; HexagonSoftware.Common.Bootstrap"/>

</= sectionGroup>

</configSections>

<<= /span>Objects>

&= nbsp; <Add Name=3D"= StringServer"

&= nbsp; ConstructorType=3D"

&= nbsp; &nbs= p; Implementations.StringServerConstructor,

&= nbsp; &nbs= p; Implementations,

&= nbsp; &nbs= p; Version=3D1.0.0.0,

&= nbsp; Culture=3Dneutral,

&= nbsp; &nbs= p; PublicKeyToken=3Dnull"

&= nbsp; >

&= nbsp; <ConstructorConfiguration>

&= nbsp; <MaximumConnectionsExceeded= >The maximum number of connections has been exceeded.</MaximumConne= ctionsExceeded>

&= nbsp; <AccountExpired>Your account has expired.</AccountExpired>= ;

&= nbsp; </ConstructorConfiguration>

&= nbsp; </Add>

</= Objects>

</HexagonSoftware>

</configuration>

The next step is to get our service (StringServer) to recognize, and vary with, these data. We are going to change StringServer so that it accepts the relevant strings as part of the constructor and then, from that point on, those stri= ngs are read-only.

As a general rule, the first time you change a signatu= re, you should refactor that signature to use the Value Object pattern. This will encapsulate the signatur= e of the method in that object and give you control over how future changes to t= hat signature impact your code. T= his is what we will do to StringServer and you can see an example of this change i= n Listing 8.

Listing 8 – StringServer with a Va= lue Object creation signature

namespace Implementations

{

pu= blic class Strin= gServer : Contracts.StringServer

{

internal class ConstructionArguments

{

&= nbsp; private string _MaximumNumberOfConnectionsExceeded;

&= nbsp; private string _AccountExpired;

&nb= sp;

&= nbsp; private ConstructionArguments() { }<= /span>

&nb= sp;

&= nbsp; public string MaximumNumberOfConnectionsExceeded

&= nbsp; {

&= nbsp; get { return _MaximumNumberOfConnectionsExceeded; }

&= nbsp; set { _MaximumNumberOfConnectionsExceeded =3D <= span style=3D'color:blue'>value; }

&= nbsp; }

&nb= sp;

&= nbsp; public string AccountExpired

&= nbsp; {

&= nbsp; get { return _AccountExpired; }

&= nbsp; set { _AccountExpired =3D value; }

&= nbsp; }

&nb= sp;

&= nbsp; public static= ConstructionArguments GetInstance()

&= nbsp; {

&= nbsp; return new ConstructionArguments();

&= nbsp; }

}

&nb= sp;

private readonly string _MaximumNumberOfConnectionsExceeded;

private readonly string _AccountExpired;

&nb= sp;

private StringServer(ConstructionArguments arguments)

{

&= nbsp; _MaximumNumberOfConnectionsExceeded =3D

&= nbsp; arguments.MaximumNumberOfConn= ectionsExceeded ??

&= nbsp; "We cannot accept any more connections."<= /span>;

&nb= sp;

&= nbsp; _AccountExpired =3D

&= nbsp; arguments.AccountExpired ??

&= nbsp; "Our records show that your account has expired.";

}

&nb= sp;

internal static Contracts.StringServer GetInstance(ConstructionArguments arguments)<= /span>

{

&= nbsp; return new StringServer(arguments);

}

&nb= sp;

public string GetMaximumConnectionsExceeded()

{

&= nbsp; return _MaximumNumberOfConnectionsExceeded;

}

&nb= sp;

public string GetAccountExpired()

{

&= nbsp; return _AccountExpired;

}

At this point, StringServer will accept data that driv= e it to vary the messages it will yield. However, our program no longer compiles, because our Object Construc= tor does not supply an instance of ConstructionArguments to StringServer. Listing 9 shows how we do this.

Listing 9 – StringServerConstructor after being upgraded to respect static configuration data

namespace Implementations

{

us= ing Bootstrap =3D HexagonSoftware.Common.Bootstrap;

&nb= sp;

pu= blic class Strin= gServerConstructor : Bootstrap.ObjectConstructor

{

public object Create(Bootstrap.ObjectCreationArguments creationArguments)

{

&= nbsp; StringServer.C= onstructionArguments arguments =3D

&= nbsp; StringServer.C= onstructionArguments.GetInstance();

&nb= sp;

&= nbsp; arguments.MaximumNumberOfConnectionsExceeded =3D

&= nbsp; GetMessage(creationArguments.StaticArg= uments, "MaximumConnectionsExceeded"= );

&nb= sp;

&= nbsp; arguments.AccountExpired =3D

&= nbsp; GetMessage(creationArguments.StaticArg= uments, "AccountExpired");

&nb= sp;

&= nbsp; return StringServ= er.GetInstance(arguments);

}

&nb= sp;

private string GetMessage(System.Xml.XmlElement eleme= nt, string messageName)

{

&= nbsp; try

&= nbsp; {

&= nbsp; return element.SelectSingleNode("./" + messageName).InnerText;

&= nbsp; }

&= nbsp; catch (NullRefere= nceException)

&= nbsp; {

&= nbsp; return null;<= o:p>

&= nbsp; }

}

Now our service is sensitive to static configuration data. If you make a change to= the dictionary of strings in your app.config and restart your application, StringServer will start serving up different strings. This is a significant improvement = over what we had. If our applicati= on were a web server, a systems administrator could quickly change a message without exposing the application to significant risk.

Yet, we can do better still. What if we wanted the ability to s= tore multiple profiles and bind an instance of StringServer, upon creation, to o= ne of those profiles? Of course,= we could just create a new object description for each profile and use some name-mangling scheme to find them but that is unsavory for many reasons. One such reason is duplication. While the XML blurb for an object = role is fairly small, now, we will soon see how it can balloon.

It is best to find a way to create one role and allow a certain degree of runtime parameterization…

Runtime Parameterization

Can I vary my services by arguments passed in at run= time?

We’ve come far from “new StringServer()= 221; and the changes we’ve made have introduced a lot of flexibility into = our application. There’s mo= re to be done, though. One of the Lean principles is “defer commitment.” In that sp= irit, we are going to refactor StringServer et al to accept a parameter at the mo= ment of instantiation (which is fairly late, when compared to “at compile time” or “at test time”) that allows us to bind a StringServer object to a “profile.” The set of profiles might consist = of localized strings, strings specialized for different classes of customer (imagine a rule such as “Our Gold customers may call the 800 support number 24x7”), the Cartesian product of the previous two examples, or anything else along those lines.

Since configuration is, again, at the heart of this ch= ange we will start by changing our configuration file. Please refer to Listing 10 for an example of the updated configuration file.

Listing 10 – A configuration file w= ith a parameterized definition of the StringServer object

<<= /span>sectionGroup name=3D"= HexagonSoftware">

&= nbsp; <section name=3D"= Objects"

&= nbsp; type=3D"=

&= nbsp; &nbs= p; HexagonSoftware.Common.Bootstrap.ObjectRoleDescription= s,

&= nbsp; &nbs= p; HexagonSoftware.Common.Bootstrap"/>

</= sectionGroup>

</configSections>

<<= /span>Objects>

&= nbsp; <Add Name=3D"= StringServer"

&= nbsp; ConstructorType=3D"

&= nbsp; Implementations.StringServerConstructor,

&= nbsp; Implementations,

&= nbsp; Version=3D1.0.0.0,

&= nbsp; Culture=3Dneutral,

&= nbsp; PublicKeyToken=3Dnull">

&= nbsp; <ConstructorConfiguration>

&= nbsp; <Profile name=3D"en-US">

&= nbsp; <MaximumConnectionsExceeded= >The maximum number of connections has been exceeded.</MaximumConne= ctionsExceeded>

&= nbsp; <AccountExpired>Your account has expired!</AccountExpired>= ;

&= nbsp; </Profile>

&= nbsp; <Profile name=3D"fr-FR">

&= nbsp; <MaximumConnectionsExceeded= >Le nombre maximum des raccordements a été excédé.</MaximumConnectionsExceeded>

&= nbsp; <AccountExpired>Votre compte a expiré.</= AccountExpired>= ;

&= nbsp; </Profile>

&= nbsp; </ConstructorConfiguration>

&= nbsp; </Add>

</= Objects>

</HexagonSoftware>

</configuration>

We also need to add an overload of our GetStringServer method that accepts the profile name. Once we have the profile name specified, we also need to communicate= it to StringServerConstructor and StringServer. We do this by passing it in as an argument to ServiceLocator’s GetInstanceOfObject method. Listing 11 shows what the StringServerLocator class looks like when we are done.

Listing 11 – A parameterized encapsulation of the Bootstrapper

namespace Contracts

{

us= ing HexagonSoftware.Common.Bootstrap;

&nb= sp;

pu= blic static class StringServerLocator

{

public static= StringServer GetStringServer()

{

&= nbsp; // Ethnocentric... we know...

&= nbsp; return GetStringServer("en-US");

}

&nb= sp;

public static= StringServer GetStringServer(string profileName)

{

&= nbsp; return ServiceLoc= ator.Instance

&= nbsp; .GetInstanceOfObject<StringServer>("StringServer", profileName);

}

StringServerConstructor still doesn’t know what = to do with the profile name, so we will have to make a few changes there. We replace our use of ObjectCreati= onArguments.StaticArguments with the selection and consumption of a subnode. Please see Listing 12 for an example of the change we made.

Listing 12 – A “profile-sensitive” StringServerConstructor

namespace Implementations

{

us= ing Bootstrap =3D HexagonSoftware.Common.Bootstrap;

&nb= sp;

pu= blic class Strin= gServerConstructor : Bootstrap.ObjectConstructor

{

public object Create(Bootstrap.ObjectCreationArguments creationArguments)

{

&= nbsp; string profileName =3D creationArguments.DynamicArguments[0].ToString();

&nb= sp;

&= nbsp; StringServer.C= onstructionArguments arguments =3D

&= nbsp; StringServer.C= onstructionArguments.GetInstance();

&nb= sp;

&= nbsp; System.Xml.XmlElement element =3D

&= nbsp; (System.Xml.XmlElement)creationArguments.StaticArguments=

&= nbsp; .SelectSingleNode("./Profile[@name=3D'" + profileNam= e + "']");

&nb= sp;

&= nbsp; arguments.MaximumNumberOfConnectionsExceeded =3D

&= nbsp; GetMessage(element, "MaximumConnectionsExceeded"= );

&nb= sp;

&= nbsp; arguments.AccountExpired =3D

&= nbsp; GetMessage(element, "AccountExpired");

&nb= sp;

&= nbsp; return StringServ= er.GetInstance(arguments);

}

&nb= sp;

private string GetMessage(System.Xml.XmlElement eleme= nt, string messageName)

{

&= nbsp; try

&= nbsp; {

&= nbsp; return element.SelectSingleNode("./" + messageName).InnerText;

&= nbsp; }

catch (NullRefere= nceException)

&= nbsp; {

&= nbsp; return null;<= o:p>

&= nbsp; }

}

Now we are “profile sensitive.” Our StringServer instances can be = bound to profiles, which are defined statically but selected dynamically. Old consumers that can still use t= he en-US profile need to change.= Existing consumers which are requi= red to become profile sensitive can switch over to the appropriate overload of StringServerLocator.GetStringServer(…). New consumers should probably be directed to the newer overload.

Backward Compatibility

What happens when I roll out a new contract for my service?

So we have a robust string server in production and a = number of clients have grown to depend upon it.&n= bsp; The clients are on different release schedules but they all share on server. We’ve chosen to deploy our StringServer to the GAC and register it at the machine level (in machine.config). Things have = been running smoothly except that, now, some of our clients need another string: they need to tell their customers when their servers have been taken down f= or maintenance.

It’s an easy feature to add: you just extend the interface with another method. This does introduce a problem for us, though:&n= bsp; How do we release the new, extended interface without breaking clien= ts that have a binary dependency on our old interface?

It would be disruptive and unnatural to try and force a massive upgrade across all of our clients.= Everyone would have to synchronize their release schedules. If one of the clients was late, al= l of the others would have to wait. In the mean time, those other clients would probably be trying to sneak featur= es into their products which would increase the risk of further delays.

Assembly binding redirection is another option. In this extremely narrow case, it = will work. Generally, assembly bin= ding redirection is a poor route to take. It blurs the lines between one version of an interface and another (= see Figure 4). This means that it erodes cohesion= in your code base by making implementers of an interface both play the role they were intended to fulfill and pretend to be adapters to the = old interface.

Figure 4 – Assembly binding leads= to expectations which, ultimately, spin out of control

The best option that we know of, at Hexagon Software, = is to use the Adapter Pattern to make objects which implement a new interface consumable by o= lder clients. If you are careful to couple your adapters to the new and old interfaces, rather than to the new service and the old interface, you will be able to create a chain of adapte= rs that persist for as long as possible. This creates a flow (depicted in Figure 5) which is permissive not only of interface extensions, but also of refinements.

Figure 5 – How adapting to old interfaces creates a flow

The ability to make refinements is important because, = as you learn more and develop a more sophisticated set of contracts between client= and server, you don’t want to be saddled with an interface that embodies = the ignorance of our past. Here&#= 8217;s an example: What if you find that a method is no longer necessary? Perhaps, you’ve got another = method that does the same thing and only 3% of your clientele are coupled to the method slated for obsolescence.

It’s probably easy to write an adapter that maps= the old method to the new one. On= ce you do so, you are then free to blast the less correct method from your publish= ed interfaces. This is because c= lients coupled to the old interface don’t have to change, even if they upgra= de to a newer version of your service, because they know your service will res= pect the interface to which they are coupled.&n= bsp; Likewise, your service doesn’t have to respect the old interfa= ce because it knows there is an adapter that does that. If it changes interfaces, in the f= uture, another adapter should be written. In this way, your service can feel free to evolve: constantly sheddi= ng old interfaces and growing into new ones, leaving behind adapters like the = molted skins of a snake.

Using Bootstrapping to Support Multiple Inter= faces

Our circumstances prohibit writing a repeatable test s= uite that uses multiple versions of an interface with, otherwise, the same identity. We will simulate th= is, instead, by putting interfaces with the same friendly name (namespace + type name) in separate assemblies. So, instead of having a Contracts.dll that represents version 1.0.0.0 and one t= hat represents version 2.0.0.0, we will have a Contracts.dll – which has = the version 1.0.0.0 – and a Contracts.2.dll – which has the version 2.0.0.0. Supporting interface= s from completely different assemblies is a superset of supporting interfaces from= two assemblies that differ only by version and content, so this will not dimini= sh the potency of our example.

Since a change in interface is at the heart of the mat= ter, here, we will start with the new interface. Listing 13 shows what the new interface looks like.&n= bsp; StringServerLocator does not change (see Listing 11 for a refresher), except that it exists in Contracts.2.dll, instead of Contracts.dll.

Listing 13 – V2 of the StringServer interf= ace

// Contracts.2.dll

namespace Contr= acts

{

public interface StringServer

{

= ; string GetMaximumConnectionsExceeded();

= ; string GetAccountExpired();

= ; string GetUnderMaintenance();

}

An upgrading to support the new string goes much as you would expect. We add a new implementation method to our implementation of StringServer in Implementations.2.dll (Listing 14). Then, we add support for that stri= ng to our StringServerConstructor (Listing 15).

Listing 14 – V2 of the StringServer implementation

// Implementations.2.dll

namespace Implementations

{

pu= blic class Strin= gServer : Contracts.StringServer

{

internal class ConstructionArguments

{

= ; <= /span>private string _MaximumNumberOfConnectionsExceeded;

= private string _AccountExpired;

&= nbsp; private string _UnderMaintenance;

&nb= sp;

&= nbsp; private ConstructionArguments() { }<= /span>

= ; <= /span>public string MaximumNumberOfConnectionsExceeded

&nbs= p; = {

&nbs= p; &= nbsp; get { return _MaximumNumberOfConnectionsExceeded; }

&nbs= p; &= nbsp; set { _MaximumNumberOfConnectionsExceeded =3D value; }

&nbs= p; = }

&nbs= p; = public string AccountExpired

&nbs= p; = {

&nbs= p; &= nbsp; get { return _AccountExpired; }

&nbs= p; &= nbsp; set { _AccountExpired =3D value; }

&nbs= p; = }

&= nbsp; public string UnderMaintenance

&= nbsp; {

&= nbsp; get { return _UnderMaintenance; }

&= nbsp; set { _UnderMaintenance =3D value; }

&= nbsp; }

= ;

= ; <= /span>public static ConstructionArguments GetInstance()

&nbs= p; = {

&nbs= p; &= nbsp; return new ConstructionArguments();

= }

}

= ;

= ; private readonly string _MaximumNumberOfConnectionsExceeded;

= private readonly string _AccountExpired;

private readonly string _UnderMaintenance;

&nb= sp;

private StringServer(ConstructionArguments arguments)

{

= ; <= /span>_MaximumNumberOfConnectionsExceeded =3D

&nbs= p; &= nbsp; arguments.MaximumNumberOfConnectionsEx= ceeded ??

&nbs= p; &= nbsp; "We cannot accept any more connections.";

&nbs= p; = _AccountExpired =3D

&nbs= p; &= nbsp; arguments.AccountExpired ??

= &nb= sp; "Our records show that your account has expired.";

&nbs= p;

&= nbsp; _UnderMaintenance =3D

&= nbsp; arguments.UnderMaintenance ??

&= nbsp; "Under maintenance.";

}

= ;

= ; internal static Contracts.StringServer GetInstance(ConstructionArguments arguments)<= /p>

&nbs= p; {

&nbs= p; = return new StringServer(arguments);

&nbs= p; }

&nbs= p; public string GetMaximumConnectionsExceeded()

&nbs= p; {

&nbs= p; = return _MaximumNumberOfConnectionsExceeded;

&nbs= p; }

&nbs= p; public string GetAccountExpired()

&nbs= p; {

&nbs= p; = return _AccountExpired;

= }

&nbs= p;

public string GetUnderMaintenance()

{

&= nbsp; return _UnderMaintenance;

}

Listing 15 – V2 of StringServerConstructor

// Implementations.2.dll

namespace Implementations

{

using Bootstrap = =3D HexagonSoftware.Common.Bootstrap;

&n= bsp; public class = StringServerConstructor : Bootstrap.ObjectConstructor

&n= bsp; {

&n= bsp; public object Create(Bootstrap.ObjectCreationArguments creationArguments)

&n= bsp; {

&= nbsp; string profileName =3D creationArguments.DynamicArguments[0].ToString();

&= nbsp; StringServer.ConstructionArguments arguments =3D

&= nbsp; StringSe= rver.ConstructionArguments.GetInstance();

&= nbsp; XmlElement element =3D

&= nbsp; (XmlElem= ent)creationArguments.StaticArguments

&= nbsp; &nbs= p; .SelectSingleNode("./Profile[@name=3D'" + profileName + "']");

&= nbsp; arguments.MaximumNumberOfConnectionsEx= ceeded =3D

&= nbsp; GetMessa= ge(element, "MaximumConnectionsExceeded");

&= nbsp; arguments.AccountExpired =3D

&= nbsp; GetMessa= ge(element, "AccountExpired");

&n= bsp; arguments.UnderMainte= nance =3D

&n= bsp; GetMessage(element, "UnderMaintenance");

&= nbsp; return StringServer.GetInstance(arguments);

&n= bsp; }

&= nbsp; private string GetMessage(XmlElement element, string messageName)

&= nbsp; {

&= nbsp; try

&= nbsp; {

&= nbsp; return element.SelectSingleNode("./" + messageName).InnerText;

&= nbsp; }

&= nbsp; catch (NullReferenceException)

&= nbsp; {

&= nbsp; return null;

&= nbsp; }

&n= bsp; }

}

Finally, we= add the string values to our configuration file.&n= bsp; More importantly, we register what we call an “interface override” for our object constructor. (Listing 16) Note that th= is override refers to our adapter constructor, rather than the regular object constructor.

Listing 16 &#= 8211; Our addition to the configuration file to support GetUnderMaintenance()

&nbs= p; <configSections>

&nbs= p; <sectionGroup name=3D"HexagonSoftware">

&nbs= p; = <section name=3D"Objects"

&nbs= p; &= nbsp; &nbs= p; type=3D"

&nbs= p; &= nbsp; &nbs= p; &= nbsp; HexagonSoftwar= e.Bootstrap.Contracts.ObjectRoleDescriptions,

&nbs= p; &= nbsp; &nbs= p; &= nbsp; HexagonSoftwar= e.Bootstrap.Contracts" />

&nbs= p; </sectionGroup= >

&nbs= p; </configSections>

&nbs= p; <HexagonSoftware>

&nbs= p; <Objects>

&nbs= p; = <Add Name=3D"StringServer"

&nbs= p; &= nbsp; &nbs= p; ConstructorType=3D"

&nbs= p; &= nbsp; &nbs= p; Implementations.StringS= erverConstructor,

&nbs= p; &= nbsp; &nbs= p; Implementations.2,

&nbs= p; &= nbsp; &nbs= p; Version=3D2.0.0.0,

&nbs= p; &= nbsp; &nbs= p; Culture=3Dneutral,

&nbs= p; &= nbsp; &nbs= p; PublicKeyToken=3Dnull&q= uot;>

&nbs= p; &= nbsp; <ConstructorConfiguration>

&nbs= p; &= nbsp; <Prof= ile name=3D"en-US">

&nbs= p; &= nbsp; &nbs= p; <MaximumConnectionsExceeded>The maximum number of connections has been exceeded.</MaximumConnectionsExceeded>

&nbs= p; &= nbsp; &nbs= p; <AccountExpired>Your account has expired!</AccountExpired>

&nbs= p; &= nbsp; &nbs= p; <UnderMaintenance>The system is currently down for maintenance.</UnderMaintenance>

&nbs= p; &= nbsp; </Pro= file>

&nbs= p; &= nbsp; <Prof= ile name=3D"fr-FR">

&nbs= p; &= nbsp; &nbs= p; <MaximumConnectionsExceeded>Le nombre maximum des raccordements a été excédé.</MaximumConnectionsExceeded>

&nbs= p; &= nbsp; <AccountExpire= d>Votre compte a expiré.</AccountExpired>

&nbs= p; &= nbsp; &nbs= p; <UnderMaintenance>The system is currently down for maintenance.</UnderMaintenance>

&nbs= p; &= nbsp; </Pro= file>

= &nb= sp; </ConstructorConfiguration>

&= nbsp; <InterfaceOverrides<= span style=3D'mso-bidi-font-size:8.0pt;color:blue'>>

&= nbsp; <Add

&= nbsp; ConstructorType=3D"

&= nbsp; &= nbsp; Implementations.StringServerV1AdapterC= onstructor,

&= nbsp; &nbs= p; Implementations.2,

&= nbsp; &nbs= p; Version=3D2.0.0.0,

&= nbsp; &nbs= p; Culture=3Dneutral,

&= nbsp; &nbs= p; PublicKeyToken=3Dnull"

&= nbsp; InterfaceType=3D"

&= nbsp; &nbs= p; Contracts.StringServer,

&= nbsp; &nbs= p; Contracts,

&= nbsp; &nbs= p; Version=3D1.0.0.0,

&= nbsp; Cultu= re=3Dneutral,

&= nbsp; &nbs= p; PublicKeyToken=3Dnull">

&= nbsp; <ConstructorConfiguration>StringServer</ConstructorConfiguration>

&= nbsp; </Add>

&= nbsp; </InterfaceOverrides<= span style=3D'mso-bidi-font-size:8.0pt;color:blue'>>

= ; <= /span></Add>

&nbs= p; </Objects><= /p>

&nbs= p; </HexagonSoftware>

</configuration>

Now we have implemented a fully functional service that conforms to both the new and old interface. Clients are permitted to upgrade t= o our latest service without being required to do so.

Conclusion

What did we learn?

In this tutorial you have seen how to write a service = in a way that makes it “bootstrappable.” You have also seen how to make a bootstrapped service configuration-driven and parameterized. Finally, you saw how to build a sustainable chain of adapters that allow you to evolve your interface witho= ut interrupting service to older clients.&nbs= p; We hope you’ve enjoyed reading this and encourage you to conta= ct us if you have any questions.

Legal

Who owns what?

The Bootstrapper is the sole property of Harbinger Sof= tware Corporation. It is marketed u= nder license by Hexagon Software LLC.