Configurable logic via Windows Workflow foundation
Few years back (6/7 years to be specific) I wanted to separate the logic a certain application executes from the application itself, in a way that will allow me to call logic by name pass in parameters, get out parameters that allows development to the actual logic be late bound kind of approach a simple pseudo code for the approach is like
{
// app entity generation
Customer = new customer(); // for the same of the discussion, entity is called customer
// read entity from UI or database or any
Customer.FirstName = uiElement1.data;
Customer.LastName = uiElement2.data;
Customer.Email = uiElement3.data;
// Execute save to storage logic
LogicExecutorInstance = createNewLogicExecuterInstance();
// upon writing this code all we know that there is a block of logic that needs to be executed called “ProcessCustomer”, this takes care of
// customer process. This way, this current piece of code or component is no not one to one tied to this logic
customerProcessingResult = LogicExecutorInstance.ExecuteLogic(“ProcessCustomer”, Customer);
DisplayResult(customerProcessingResult);
}
The idea back then was very simple, logic blocks was represented as a pipeline sort of speak, each pipeline is:
- Name
- List of tasks
Each task is either:
- COM+ call (in this case you need implement a specific interface and this to be called), input parameter was always XML, output was either a specific interface implemented COM object, or XML
- A script call, in this case your script will be called XML will be passed in as a parameter
- XSLT call, which is a transform to execute
The whole configuration is saved in a SQL DB, the system also provide 2 ways to call into the system
- File watcher that has configuration of files to be picked and logic to be executed and then file out.
- API calls via COM object directly to call into the system which is the sample above illustrates
This is how it looked like 
The whole system took 3 days of development, never went to production as it was to slow no caching to was built in the API so every time a linked list of the tasks has to be built and executed, definitely the main reason was back then it was too scary to build and deploy and product even though the idea was successful back then, then BTS 2000 came out with application features like was too easy and hey somebody else wrote the same code and willing to support it.
Few days back flying back home from Seattle after SOA &BP conference obviously 20 hours of nothing to do other than sitting, the idea was recalled and I was thinking it might be needed somehow knowing that the implementation was needed in away in today’s development approaches, just image ASP.NET form that calls the logic without knowing the exact logic at the time of prototype development or the actual development itself, so I decided to put it together time myself on implementing the same approach on a deferent technology stack
So again:
- Pipeline list was configuration section in configuration file
- Each pipeline have
o Name – text key
o Workflow type – complete assembly & type name for a sequential WF that implements the logic
o Parameter type in
o Parameter type out
- A static library on top of all that takes care of loading WF executing it and return in it.
Configuration will look like:
<logicExecuter>
<logicItems>
<add mode="SyncInOut" name="default" type="WorkflowConsoleApplication1.Workflow1, WorkflowConsoleApplication1" inType="System.String" outType="”Assembly qualified name of the parater, you need a reference type" />
</logicItems>
</logicExecuter>
Providing 2 ways of calling the logic
- Fire and forget which is a one way call, the calling thread will not be stopped until logic is completed.
- Async in/out call which your thread will be blocked until logic is executed and returned with results
Rules:
- WF type will have to provide property that maps direct to “parameter type in” & “parameter type out” and has specific names
- WF type will have to provide one property of type “AutoResetEvent” used to lock current thread until WF executes. Which means you WF will work in synchronous mode until this event is signled, the reset of activities will be executed in async mode, powerful eih? :)
- Async calls should happen using external features like methodinvoker delegate or ASP.NET 2.0 async pages.
The system looks like that 
Calling code will look like
ExecuterEngine.startRuntime(); //optional the library will init the runtime if it wasn’t
string sOut = ExecuterEngine.Execute<string, string>("default", "sIn");
additional feature – my fav actually – is you don’t even have to have a type for each logic you need to have during prototyping your application, you do need that there is a logic block to be executed at this button click or so, so what you can do is to use this call
string sOut =
ExecuterEngine.ExecuteNone<string, string>("logicname", "someparmater in", "some value out");
This basically will execute an internal workflow that does nothing other than having one activity that signles the wait event, returning the 3rd parameter sent, during prototyping this will get you a sense of “connecting” logic together until you develop actual logic then use the original call
Attached is the code, I did some initial load testing and results actually impressive, got to love how WF is performing
- LogicExecuter.Core, c# class library is the static library that isolates you from internal working
- LogicExecuter.Tester, c# console to test the library
Enjoy