Musings on Framework

Over the past 6 months we've seen a certain emergence of application knowledge in our framework that I'm not entirely sure I understand. Assemblies such as SOA and TitaniumDataAccess provide extremely usefull functionality but are deeply rooted in a number of applications which makes you wonder on how much they really should be in framework... after all Framework is about more than adding an assembly reference and having intellisense.

One area that has shown promise is the factory-style interface structure used in eSignature. We build our... ahem... ServiceContract assembly - which has no Framework references - inside the module, then copy the pre-compiled assembly to our consumer module, hard-referencing it. At runtime we create a module instruction which says, register this interface ICustomer with this class.

There are a couple of benefits to this style of communication. First, our current message based soa is pretty procedural, an interface based soa is more Object-Oriented which should make cross-module communication easier to use; think about the "conversationId" parameters we've had to add to ContactServices. Secondly, because this feels more Object-Oriented, it's easier to explain this type of communication to developers. Finally, it's easier to create mock handlers for our unit tests.

The only down-side is how do you introduce something like this without destroying our current communication scheme and blowing away advent integration. The only real feasible way is to attempt to use it in a "limited" mode with one module, maybe across the sales module in our next service pack.

One other idea would be to have the modules define their own resource strings and images with a similar "initialization" instruction. That way your globalization dll could change very little and if an invalid resource is requested it could return a "no smoking sign" and not break the module.

Couple big changes but worth looking at for future development.