none
Does Windows Workflow Muddy The Water? RRS feed

  • Question

  • I have been trying to get excited about Windows Workflow Foundation from an architectural perspective but after having a conversation with one of my colleagues I sort of started to question the value of such a framework.  Here's why....

    1.  Does Windows Workflow run the risk of allowing line of business applications to deliver workflows that might actually be valuable to an entire enterprise?  In other words ... if I have a true workflow and I do all of my workflow management in BizTalk shouldn't I put it there?  What happens when a new project wants to use it?  What makes a workflow an 'application' workflow?

    2.  I know I have heard that Windows Workflow is the Intra-Application workflow tool and BizTalk is the Extra-Application workflow tool but that doesn't really complete the picture.  What about mobility from Windows Workflow into BizTalk ... does that exist?  If I have workflows with some level of redundancy don't I have to start maintaining multiple schemas?

    3.  Does Windows Workflow just provide an easy way for companies to do orchestration that don't have the need (or resources) to enable a full blown EAI infrastructure via BizTalk?

    4.  Is Windows Workflow just a model driven development tool?  I can certainly see how we can develop any code we want with it but we get the added benefit of a visual representation.

    I realize this post might make more sense at windowsworkflow.net but I wanted to start here and cross link it.  I'll be interested to hear everyone's thoughts.

    Sunday, January 29, 2006 5:54 PM

Answers

  • I jumped on my blog surf board and found a couple of things on BPEL and WF.  Looks like there are some mappings of BPEL activities to WF sequential workflow activities (http://blogs.msdn.com/alekseys/archive/2005/09/27/474696.aspx).  That tells me that there are ways to do the same things but it's not necessarily 'supported',  I also see quite a bit on BPEL4WS 1.1.  I also found this article from David Chappell where he gives us his opinion of BPELs value.  So do I care if it supports BPEL .... maybe not (http://www.davidchappell.com/HTML_email/Opinari_No14_10_05.html).

    Now to your other question, does WF help integrate workflow? I would say .... maybe.  I think there's nothing bad about applications starting to build workflows in WF as a best practice but my basic question is when would I do this with windows workflow and not BizTalk orchestration?  In a service-oriented world the concept of an "application" starts to get very blurry.  Are we not trying to deliver discrete business functions as services can then turn around and be aggregated into unique workflows.  Would I really do that inside of Windows Workflow?  If I do I will not get all of the other robust features available to me like activitiy monitoring,  broad adapter support, transformation and routing,  assured delivery, etc ... etc...

    I'm just trying to figure out where it makes sense for an 'application' to own some type of workflow and beyond just simple page flow examples I'm not seeing great architectural guidance on this topic.

    Sunday, January 29, 2006 7:46 PM

All replies

  • I have not checked but does WWF support BPEL? 

    Also, would you not say that WWF helps applications integrate workflow?  The application itself may only be only a part of an entire system workflow managed by Biztalk, Savvionn, iFlow or some other enterprise workflow.

    -Dave

    Sunday, January 29, 2006 7:06 PM
  • I jumped on my blog surf board and found a couple of things on BPEL and WF.  Looks like there are some mappings of BPEL activities to WF sequential workflow activities (http://blogs.msdn.com/alekseys/archive/2005/09/27/474696.aspx).  That tells me that there are ways to do the same things but it's not necessarily 'supported',  I also see quite a bit on BPEL4WS 1.1.  I also found this article from David Chappell where he gives us his opinion of BPELs value.  So do I care if it supports BPEL .... maybe not (http://www.davidchappell.com/HTML_email/Opinari_No14_10_05.html).

    Now to your other question, does WF help integrate workflow? I would say .... maybe.  I think there's nothing bad about applications starting to build workflows in WF as a best practice but my basic question is when would I do this with windows workflow and not BizTalk orchestration?  In a service-oriented world the concept of an "application" starts to get very blurry.  Are we not trying to deliver discrete business functions as services can then turn around and be aggregated into unique workflows.  Would I really do that inside of Windows Workflow?  If I do I will not get all of the other robust features available to me like activitiy monitoring,  broad adapter support, transformation and routing,  assured delivery, etc ... etc...

    I'm just trying to figure out where it makes sense for an 'application' to own some type of workflow and beyond just simple page flow examples I'm not seeing great architectural guidance on this topic.

    Sunday, January 29, 2006 7:46 PM
  •  Mr. SOAPitStop wrote:

    4.  Is Windows Workflow just a model driven development tool?  I can certainly see how we can develop any code we want with it but we get the added benefit of a visual representation.

    I guess Microsoft should comment on your other points - as it is mainly a positioning thing (and the performance/scalability of the final product)

    However, considering your 4th comment (above) - I would like to say that, while it is tempting to treat *any code* as a candidate for workflow - but the truth is that it is more complicated than it seems (to do right) - well, at least that's my experience

    Arnon

    Sunday, January 29, 2006 10:38 PM