Last post Aug 17, 2009 08:38 AM by mahmud05
Aug 17, 2009 04:16 AM|mahmud05|LINK
I am going to start a very lare scale project life cycle management project for a critical client. We are thinking of using WF for this. It woul be great if you please share your experiences in using WF. Specifically please alert me if there is any negative
issues invloved in using WF. The issues could be:
2. Performance related
3. Time related
5. Any other
WF Risk Factors
Aug 17, 2009 07:34 AM|Maate|LINK
There was a great PodCast on WF in the .NET Rocks show a few months ago. In general, as I remember, there is some performance issues to look out for, and a major refactoring to .NET 4.0 which you might consider waiting for. It will break backwards compatibility
to .NET 3.5 implementation of WF and include some major performance improvements. Also, the state machine workflow will
not be included, but it will be replaced by a flow chart workflow.
Anyway, dotnetrocks WF 4.0 show:
Aug 17, 2009 07:40 AM|shabirhakim1|LINK
Hi Great Man,you are luck if you got opp. to work on WF.
I think Windows Workflow is going to be the execution engine. There's certainly the ability to write a lot of code inside of a Workflow, to actually put implementation code inside of a Workflow. I don't think that is going to be the most flexible approach,
it's not going to be the best architecture. Workflow has the ability to communicate back to the host process and receive events from the host process during the lifetime of a Workflow through well defined interfaces. You literally define an interface that
has public methods and the public events and you tell the Workflow "this is what you're going to be working with
As you told that it is big contract then,writing enough XAML, something has to take the XAML and generate some code; all the code has to go through the C# compiler, BB compiler, so ultimately those workflow definitions are in assemblies. The one exception
is when you write workflows in pure XAML just XML, no code behind, you can actually feed those to the workflow engine and have it go through a process called activation. So you don't have to compile those workflows, it can just read the XAML definition and
conjure up a new instance of that workflow.
here is the interview
Windows Workflow with Scott Allan
Go through it
Aug 17, 2009 08:02 AM|shabirhakim1|LINK
i feel like it is best piece of middleware that Microsoft has released since the Distributed Transaction Coordinator. Almost every program encodes some type of workflow; there's some type of process involved that has rules and conditions. I think its going
to be very useful in a lot of different types of architectures.hope people will realize it only once Biztak storm is there in future..
Aug 17, 2009 08:38 AM|mahmud05|LINK
Basically I have not started the workflow architectural design yet. I will do that soon. but before that I wanted to know if there is any known issue that I should consider during architecture specification. Thanks guys for your answers and useful links.
Please continue your feedbacks on what are the checkpoints, alerts and worries I need to consider during the archtectural design and also during development.
I heard from few of my peers that WF kills performance and it is not wise to use it. That is why I have come to you guys to have discussion on this.