end-user workflow design & compilation
In WWF, you compile a workflow, which I believe calls the workflow compiler wfc.exe, and then calls the C# compiler, which outputs a .NET assembly. What I'm wondering is how this will work for end-user workflow design, where I have re-hosted the designer in my own app.
Will this require me to output the workflow definition to a file on disk, call the workflow compiler, then generate a .NET assembly from that for a specific workflow ? Do I end up with potentially hundreds of compiled workflow assemblies in that case, if I have many workflows ? Or can I do all this compilation in memory ?
The idea of compiling a workflow seems somewhat strange to me - at least compared to "traditional" workflow products, where a workflow definition is stored in a database somewhere - and then effectively interpreted at runtime.
So, for end-user workflow creation - will I have to physically compile workflows to create .net assemblies that exist on disk ?
Andrew,
You do need to compile workflows into assemblies so that the workflow runtime can start the workflow based upon its compiled type. You wouldn't necessarily end up with hundreds of assemblies, because multiple workflows can be compiled into the same assembly. You can use the WorkflowCompiler class to do all of this programmatically, and the output assembly can be generated in memory as well.
For a nice simple example of all this put together, check out the code snippet at http://www.dharmashukla.com/2005/09/workflow-shell.html
Hope this helps!
Arjun
Arjun,
Sounds interesting. We are faced with the following architecture:
1) user saves the workflow to a database.
2) interaction with the workflows is via web services in a clustered web server environment.
3) instead of making sure a copy of each compiled workflow exists in each server, when a user attempts to call a workflow, we see if it exists in the loaded assembly, and if it does not, we compile it on the fly.
This seems entirely plausible given the scenario laid out in the workflow-shell. Is this realistic if we are talking about potentially thousands of workflows?
Thanks,
Alex
Arjun,
Can you please explain more the need for a compiled workflow?
Create a new sequential workflow with code separation. Add only self-contained activities (do not add activities that generate code like the Code activity). You’ll notice that the associated .cs file contains no code beyond the partial class definition. In this example, should it not be possible to start this workflow having the .xoml file only?
I must very strongly side with Alex and Andrew that the requirement of having compiled code for all workflows is bad. I know you mentioned we can use the WorkflowCompiler to generate a compiled workflow in memory. Perhaps you could consider an override of WorkflowRuntime.StartWorkflow that does this for us?
One issue to consider with the in-memory compiler is a multi-threaded and multi-user working environment like ASP.Net. ASPX files are compiled once when they are first requested by the application and then cached for future requests or until the aspx file is overwritten. If we want to use xoml-based workflows, especially in an environment like ASP.Net, the compiler would need to exhibit similar behaviors. I’m sure this is something we could create using WorkflowCompiler and FileSystemWatcher, but I would also think such functionality will be commonly requested.
I appreciate any thoughts on the matter.
Jared
 Jared Bienz wrote: |
|
One issue to consider with the in-memory compiler is a multi-threaded and multi-user working environment like ASP.Net. ASPX files are compiled once when they are first requested by the application and then cached for future requests or until the aspx file is overwritten. If we want to use xoml-based workflows, especially in an environment like ASP.Net, the compiler would need to exhibit similar behaviors. I’m sure this is something we could create using WorkflowCompiler and FileSystemWatcher, but I would also think such functionality will be commonly requested. |
|
Actually, in Dharma Shukla's presentation at the PDC he did exactly this. Basically they had an HTTPModule that compiled a XOML and the associated .cs file on the fly into a temporary assembly by using the WorkflowCompiler class. This behavior is not part of Windows Workflow Foundation, but something that you could do using the compiler example that Arjun mentioned.
James Conard
Architect Evangelist - Windows Workflow Foundation
http://www.WindowsWorkflow.net
http://blogs.msdn.com/jamescon
