Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

  • Inside Architecture

    How to get rid of circular references in C#


    A refers to B, B refers to A, Why can't we all just get along?

    Every now and again, I see a posting on the newsgroups where someone has created a circular reference in their code structure, and they can't figure out how to get out from under it.  I'm writing this article for those folks (and so I have some place to send them when I run across this problem repeatedly).

    Let's start by describing a ciruclar reference.  Let's say that I have a logging layer that is useful for recording events to a log file or a database.  Let's say that is relies on my config settings to decide where to log things.  Let's also say that I have a config settings library that allows me to write back to my config file...

    //calling app:
    Logging myLogObject = new Logging();
    myLogObject.WriteToLog("We are here!");
    MyConfig cnf = new MyConfig();
    cnf.SetSetting("/MyName","mud", myLogObject);

    The class may look like this:

    public class Logging {
     public Logging()
       MyConfig cnf = new MyConfig();

       LoggingLocation = cnf.GetSetting("//Log/Location");
       if (LoggingLocation == "File")
          // save logs to a file
            // save logs to a database

     public void WriteToLog(String LogMessage, int Severity)
       // write the log message


    If you notice, my little logging app refers to my config file library in the constructor of the logging object.  So now the logging object refers to the config object in code.

    Let's say, however, that we want to write a log entry each time a value is changed in the config file. 

    public class MyConfig
       public MyConfig() { }
       public string GetSetting(string SettingXPath)
          // go get the setting
       public void SetSetting(string SettingXPath, string newValue, Logging myLog)
          // set the string and...
          myLog.WriteToLog("Updated " + SettingXPath + " : " + newValue);

    OK, so I removed most of the interesting code.  I left in the reference, though.  Now the config object refers to the logging object.  Note that I am passing in actual objects, and not using static methods.  You can get here just as easily if you use static methods.  However, digging yourself out requires real objects, as you will see.

    Now, compile them both.  One class will require the other.  If they are in the same assembly, it won't matter.  However, if they are in seperate DLLs, as I want to use them, we have a problem, because neither wants to be the one to compile first.

    The solution is to decide who wins: the config object or the logging object.  The winner will be the first to compile.  It will contain a definition of an interface that BOTH will use.  (Note: you can put the interface in a third DLL that both will refer to... a little more complicated to describe, but the same effect.  I'll let you decide what you like better :-).

    For this example, I will pick the config object as the winner. In this case, the logging object will continue to refer to the config object, but we will break the bond that requires the config object to refer to the logging object.

    Let's add the Interface to the Config object assembly:

    public interface IMyLogging
       void WriteToLog(String LogMessage, int Severity);

    Let's change the code in the call to SetSetting:

       public void SetSetting(string SettingXPath, string newValue, IMyLogging myLog)
          // set the string and...
          myLog.WriteToLog("Updated " + SettingXPath + " : " + newValue);

    You will notice that the only think I changed was the declaration.  The rest of the code is unchanged.

    Now, in the Logging object:

    public class Logging : IMyLogging {
    // the rest is unchanged

    Now, the Logging assembly continues to rely on the config assembly, but instead of just relying on it for the definition of our config class, we also rely on it for the definition of the IMyLogging interface.

    On the other hand, the config class is self sufficient.  It doesn't need any other class to define anything.

    Now, both assemblies will compile just fine.

  • Inside Architecture

    On Security in Workflow


    It's been ages sinces I've blogged on workflow.  I've been wildly busy implementing a workflow engine in C# that will ride under any .Net app while providing a truly light and easy to understand modeling language for the business user.

    One business modeler is now able to go from inception to full document workflow implementation in about 20 hours, including creating the forms, e-mails, model, staging, debugging, and deployment.  The only tools that need to be installed on the modeler's PC are Infopath (for forms, e-mail, and model development) and our custom workflow management tool that allows management, packaging of a workflow and remote installation to the server.

    One problem that we've been solving has to do with security.  Just how do you secure a workflow.

    For those of you who live on Mars, Microsoft is very heavily focussed on driving security into every application, even ones developed internally.  Plus, workflow apps need security too.

    Thankfully, the first "big" refactoring we've done to the design of the workflow engine was in the area of security.  I'd hate to have added workflow security later, after we had a long list of models in production.  As it stands, we only have a handful of models to update.

    So what does security in a workflow look like?  Like security in most apps, (common sense) plus some interesting twists. Here are some of the most salient security rules.

    a) We have to control who can submit a new item to the workflow. In our models, all new items are added to a specific stage, so you cannot start "just anywhere" but we also have to be cognizant that not all workflows may be accessed by all people.  There are two parts to this: who can open the initial (empty) form and how do we secure submission to the workflow?  We solved both with web services that use information cached from the active directory (so that membership in an AD security group can drive permission to use a form).

    b) Once an item is in a workflow, we need to allow the person assigned to it to work on it.   There are two possibilities here.  Possibility 1 states: There is no reason to set permission on each stage, because the system only works if the person who is assigned to the item can work on it. Possibility 2 states: a bug in the model shouldn't defeat security.  We went with the second one.  This means that the model can assign a work item to a person only if that person will have permission to work on the item (in the current stage for entry actions or in the next stage for exit link actions).

    c) Each stage needs seperate permission settings.  A person can have read-only permission in one stage, read-write in a second, and no permission at all in the third. 

    d) It is rational to reuse the same groups for permission as we do for assignment, since they are likely to coincide.  Therefore, if we assign an item to a group of people (where any one of them can "take the assignment", then it makes sense that the same group of people will have permission to modify the work item in that stage.  Two purposes, one group.

    If you have opinions about the proper rules for managing access to workflow stages and the document they contain, post a response to this message.  I'd love to hear about it.

  • Inside Architecture

    C#: a way to get around the lack of multiple implementation inheritance


    I run across this question from time to time: why is there no multiple inheritance in C# like there was in C++.  Personally, I've never needed it, but I do see a value to it, and there are some times when it would appear to be handy.

    There is a workaround to this problem that is not difficult to do.  You get some of the same abilities as multiple inheritance, with a few structural advantages.  Before I describe the solution (below), let me frame the problem so that we are all using the same terms.

    We have two concrete classes.  They are both derived from different base classes (not interfaces).  You want to give both of them a set of common methods and properties that meets a defined interface or base class (multiple inheritance).

    Note: if you just want to inherit from an interface and implement the properties and methods directly in the class, you can do that now.  That does not require a workaround.  In other words, it is perfectly acceptable to do this:

       public class MyClass : System.Web.UI.Page , MyNewInterface
       { ... }

    So the problem only really arises if you have two or more BASE CLASSES that you want to put on that line... something you cannot do in C#.  I will treat one base class as "given" and one as "add-on".  It really doesn't matter, structurally, which one is which.  There is only one "given" class.  There can be as many "add-on" base classes as you want.

    So, you use a simple composition pattern (that I cannot find the name for... if someone knows the name, please send it to me).

    Step 1) you need an interface.  This defines a single getter property with a name derived from the base class name of the class you want to add on.

    interface IAddOn
        // define a getter to return one "AddOnClass" object
        AddOnClass GetAddOn
        {   get;   }

    Step 2) insure that your concrete object inherits from IAddOn

    public class MyMultiConcrete : MyBaseClass, IAddOn
    { .... }

    Step 3) Create a factory object that will return a class of type 'AddOnClass'  (optional, but good practice). 

    public class AddOnFactory
       public static AddOnClass NewAddOnObject()
       {   return new AddOnClass();   // factory method


    [edited] I want to add one comment here.  You don't have to return a type 'AddOnClass.'  In fact, if the add on class is an abstract class, you cannot.  You would need to derive a class from AddOnClass and then instantiate one of those types.  If you created this class specifically to be called from your new type, then you have a pair of classes that work together.  The derived add-on has access to the private and protected members of the add on type. 

    In this case, you can pass in a reference to the calling class:

        public static AddOnClass NewAddOnObject(IAddOn Caller)
        {   return new ConcreteAddOnClass(Caller);   // factory method }

    This gives the concrete add on the ability to directly manipulate the 'container' when you call a property or method on it, as shown below.  [end edit]

    Step 4) Declare, in your concrete classes, a private property to hold the reference:
          private AddOnClass _AddOn;

    Step 5) In the constructor for your concrete class, call your factory object to return an object of type AddOnClass.  Assign the reference to the private _AddOn property.

       public MyMultiConcrete() : base()
       {    // do normal constructor stuff here...
             _AddOn = AddOnFactory.NewAddOnObject();

    Step 6) Define the property that returns the add-on object
         public property AddOnClass GetAddOn
         {   Get { return _AddOn; } }

    /// you are done ///

    Now, every place in  your calling code, where someone needs a method or
    property from the add-on type, they will reference it this way:

    One nice thing to consider, we can do this for as many types as we want within a class.  Therefore, we could theoretically inherit from dozens of base classes. 

    I hope you have as much fun using this pattern as I have had describing it.  I doubt that I'm the first person to identify this pattern, so if someone can send me a link to another name or description, I will be grateful.  If not, perhaps I'll go to ChiliPLoP and present it :-).

  • Inside Architecture

    How is workflow different from a Finite State Automata?


    After showing a workflow diagram to a co-worker, he asked me if I could tell him how this is any different from basic Finite State Automata (FSA).  To be honest, I had to think about it for a few minutes to get my thoughts around this, but there is a fairly big difference.

    For those of you who aren't familiar with FSA theory, this is a segment of computer science that goes back to the earliest days of computing.  The idea is this: arrange your input into a stream of tokens of the same size.  Then, keeping a state, read each token.  The token will dictate the state you move to next.  Side effects could be added to a transition.  These side effects, taken together, were the actual functional code of the system.

    In a strange way, we've all moved to FSA programming when we moved to event driven application programming.  The event handler is essentially a place to put logic for reacting to an input (the event) in a state (the global environment).  It's a bit different, though, in the sense that our input isn't in a stream.  We can't look ahead at the next token or move in the other direction over a series of tokens (important parts of compilier design).

    In that respect, Workflow modeling is closer to event driven programming than it is to FSA theory, because we don't have that input stream.  We can't look ahead. 

    On the other hand, unlike event driven programming, most workflow systems use the FSA approach to modelling, where you look at the behavior of the system by creating a graph showing the stages of work, and the transitions from stage to stage. 

    However, what really distinguishes Finite State Automata from workflow programming, in my mind, are the three layers of abstraction inherent in Workflow analysis. 

    Finite State Automaton development requires a pre-processing step, where you take the input and interpret it as a series of tokens in a language.  In compiler theory, we call this lexical analysis.  This analysis happens at only one layer of abstraction (usually at a very low level: character sequences).  Therefore, the structure of computer languages has to be represented as a parse tree: a complicated heirarchical structure that "represents" the analyzed token stream.  The FSA is done when the parse tree is done.  It isn't involved in actually using that tree to create the target code.

    With workflow analysis, there are three layers of abstraction: Business unit level, Business process level, and Workstep level.  All three are distinct (but related).  All can be described with rules and constraints.  All have a specific purpose, and each one can be represented as a state graph.  The mathematics are considerably more complex.  (Only the lowest level has to be deterministic).   There are many PhD level practitioners of workflow modeling who can attest to the fact that workflow is much more complicated and complex than the fundamental concept of a Finite State Automaton.


    Because FSA's interpret logic... nothing more.

    Workflow modeling deals with human behavior.

  • Inside Architecture

    On XML Models of Process


    XML is an interesting language, but is it a useful one for describing a process?

    We have multiple competing standards for workflow and collaboration.  We have BPEL, XPDL, SWFL, XRL, XScufl, and custom XML workflow models developed for the XFlow, AntFlow, Agile, YAWL, and OpenWFE tools.  (If anyone is looking for a good idea for a masters thesis in Workflow, they should create a comparison of these different languages, catalog features, and create a roadmap for the rest of us).

    Just to add to the fun, rather than learn an existing modelling language, I wrote my own for an internal tool I'm working on.  Wise?  Probably not.  In keeping with the philosophy of the project?  Yes.  Most of the languages I mention above are the creation of committees and have many features designed for multiple vendors to extend the core set.  I needed less (features demanded by existing Java projects) and more (features specific to my Microsoft-based solution).

    I also needed a language feature that I didn't see anywhere else, including on the workflow patterns homepage: native support for ad-hoc workflow.  This means allowing a user the right to change the routing rules in the middle of a workflow process, while the engine maintains managability.  No mean feat. 

    So, inspired by YAWL, and angry at the limitations of the competing partner products that we evaluated, our team wrote another XML based workflow model structure. 

    I learned a few things that I want to share:

    1. XML is an interesting language, but not a forgiving one.  It is easy to create bugs by making small errors in the specification of a schema, where the downstream ripples can be quite large.  If I had to do this all again, I'd better appreciate the time it takes to create and debug the schema itself.
    2. I am far from the first person to tackle the idea of Workflow.  Perhaps it would have been better to start with XPDL (or a subset thereof).  My customers would have a better ability to switch away from my project later, which is one of the stated goals of the project.  I, on the other hand, could have leveraged the built-in workflow experience that comes from leveraging a schema that comes from workflow experts.
    3. XML is an old-fashioned declarative language.  It is about as advanced as C (not C# or Java).  Therefore, while there are many things you can do in XML, you have the freedom to do some pretty stupid stuff.  In addition, you don't have the constructs to do some elegant stuff.  By comparison, XML is an infant.  The effect: the resulting code is difficult for a human being to create, read, follow, analyze, debug, test, or support.
    4. XML parsers are touchy.  They remind me of Fortran-77 compilers.  First error and they are done.  You can't count on an error message from a parser to be all that helpful. 
    5. Tools for generating XML are new, but getting better.  Two commercial tools worth mentioning: Microsoft Infopath (the most underrated, creative, well-built, xml forms system I've seen), and Altova Stylevision (an interesting product that suffers primarily from the lack of imagination of its original designers, not the details of the implementation).  Add Visual Studio for Schema generation and you have almost everything you need.
    6. Automatic mapping between XML and databases: a new and immature field.  The current bits in SQL Server 2000 are OK, but I'm looking forward to better capabilities in Yukon and other tools.  Right now, I wouldn't count on using automatically generated or automatically parsed XML as a way of reducing struggle and pain on a development project.  You will only replace one kind of agony with another.
    7. Like any code-based method, process declaration in XML inherently describes only one aspect of a process: the static connectivity between pre-declared states.  The dynamic aspect is not well described or modeled when you focus on the static.  Some folks have tried to focus on a dynamic model exclusively, but the resulting description was even harder to understand (refer: Biztalk HWS).  In other words, the model, in XML, isn't clean enough to provide to business users.  A LOT of translation is required.  XSLT comes in very handy.
    8. Even with these drawbacks, I can't imagine a better way.

    So, XML it is.   And for now, I'm still using my proprietary schema for workflow models.  Perhaps, someday, I will switch over to BPEL or XPDL.  But not this day.

  • Inside Architecture

    steps to transition a client server VB6 app to .Net


    Every now and again, I get a question that I've seen many times before.  I saw this one recently and thought I'd record the answer, so I can refer to this in the future.

    Question: Our company develops and markets a client/server application which is
    written in VB6 as a rich Win32 Client/Server application. For a variety of
    technological reasons we are looking to migrate toward the .NET environment.  How can we best migrate our VB6 app to the .Net.  We are planning to add a new feature.  Can we plug in the new feature into existing code and maintain a seamless U/I.


    When it is time to add a new module, this may not be the best time to move
    to .net.  I guess it depends on how independent the new module is.  If you need a new module, see step 4. 

    • Step 1: Spend a few days getting used to your code again.  Like an old
      friend that you've lost touch with, code tends to deviate from the design
      during development and maintenance.  Take a fresh look.  Consider this
      If I was to write an altogether new interface, could I use the same objects
      I currently have?  Would I?
    • Step 2: refactor the existing code, in the existing language.  Clean up any
      of the partitioning problems you saw in step 1.  Some things will still
      creep up in the development later, but taking a little time now to clean up
      the objects can really make a difference in your ability to deliver on a
      predictable basis.
    • Step 3: Create an ENTIRELY NEW USER INTERFACE.  This is not for the faint of
      heart.  However, VB6 has a few advantages that your ordinary application
      doesn't have.  For one thing, all of it's objects comply with the COM
      interface.  Therefore, you can create an entirely new interface in .NET
      without actually removing the old one.  You can pop back and forth, validate
      functionality, and even refactor the old code while writing the new
      interface.  Here is where the work done in Step 2 really pays off.  If your
      business object layer was actually designed to be independent of the U/I
      layer, you will appreciate it today.  If not, you will need to make it
      independent.  There is no way around it.
    • Step 4: retire the old user interface and release the code to business users
      or beta testers.  It takes time to create the new interface.  Someone always
      adds an "innovation" or two.  Start collecting feedback now.  Depending on
      your business, it is perfectly acceptable to actually release the code at
      this stage.  If there are new features to add, do it using the OLD code base
      and the OLD language, called from the new interface.  In other words, keep
      the layers intact.
    • Step 5: Create a parallel data access layer.  This will be used by the .NET
      business objects that you write.  You will continue to use the VB6 Data
      access layer while you still have VB6 components in play.  You will use the
      .NET data layer for .NET objects.  Don't plan on mixing these two... it
      isn't worth it.  (take that from experience and pain... trying to use the
      VB6 data layer from .Net, or vice versa, is a doorway to undue delay and
      gnashing of teeth.)
    • Step 6: Pick a relatively self-contained set of business objects.  Something
      achievable.  Don't go to the biggest, but don't pick the smallest either.
      Give yourself a chance to succeed and still learn.  Recode those business
      objects to .Net.  Have your GUI call them instead of calling the VB6
      objects.  Have the .Net objects call the parallel data access layer.  Learn
      from the experience.
    • Step 7: refactor everything.  Literally, take an entire dev-test cycle to
      just fix the stuff you need to fix.  This could be a month or several
      months, depending on the size and complexity of your app.  Be specific.
      Plan your refactoring.  Do this only to improve structure.  Apply lessons
      learned to the new code, as well as fixes to the interface into the old
    • Step 8: Release.
    • Step 9: Recode another set of business objects.
    • Step 10: Repeat steps 8 and 9 until all business objects are recoded in
      .NET.  Retire the old VB6 data layer.  Release.
    • Step 11: buy champagne.  Give everyone a week of skiing or windsurfing.
Page 103 of 106 (634 items) «101102103104105»