locked
WF4 Application Architecture RRS feed

  • General discussion

  • Hi

     

    I've been having a play with WF4, and have a few architectural questions.

     

    We currently have a pretty typical architecture - a Silverlight/ASP.NET application that communicates with its Business Logic Layer (BLL) via a WCF Service layer. A simplified representation of it might be:

     

     

    +-------------------------------------+

    |    Browser / third party clients    |

    +-------------------------------------+

                      |

                      | HTTP

                      |

    +-------------------------------------+

    |        ASP.NET Web Application      |

    +-------------------------------------+

                      |

                      | WCF

                      |

    +-------------------------------------+

    |              Services               |

    +-------------------------------------+

                      |

    +-------------------------------------+

    |                BLL                  |

    +-------------------------------------+

                      |

    +-------------------------------------+

    |                DAL                  |

    +-------------------------------------+

                      |

    +-------------------------------------+

    |              Database               |

    +-------------------------------------+

     

     

    We're adding WF4 to this architecture, and to me it seems natural that the workflow should sit within the BLL. However, I'm a little concerned that this would add another level of WCF and serialisation overhead to exchange messages between the BLL and the Workflow. This feels a bit slow and clumsy to me.

     

    I was initially excited when I read about passing data into WF4 instances via bookmarks, but it appears there is no equivalent mechanism for returning data to the BLL from the WF4 instance, and the data that can be passed into a bookmark is not strongly typed. Is that correct? If so, it appears WCF Send/Receive activities are the communication mechanism of choice.

     

    I've seen that it's possible to create a local Workflow Management Endpoint, and this sounds promising as I presume it wouldn’t need to use TCP or HTTP transport – is it possible to do something similar for other types of endpoints?

     

    Or am I thinking about this the wrong way? Is it intended we should replace our service layer with Workflow Services, and drive the BLL fully through WF4? This feels a little clumsy too, because:


    • There will be some services that shouldn't be controlled by the workflow (for example, lookup items for populating drop down lists).
    • We don't appear to have much control over the WCF service contract that is generated by Workflow Services, so it'd be tricky ensuring our API remains consistent for third parties. (Will contract-first development be re-introduced?)
    • I envisage that there would be situations where the BLL would need to drive the workflow, instead of vice-versa.


    I'd appreciate any advice you might have in this area.

     

    Cheers,

    Andrew
    Tuesday, October 6, 2009 1:35 AM

All replies

  • Hi

    Further to this, I've just come across System.ServiceModel.LocalBinding, which is described as a "binding used for communication between a service and a client that are in the same application domain." This sounds pretty exciting, but Google/Bing isn't helping me find out any more about it - is there any more information available about this?

    Cheers,
    Andrew 
    Wednesday, October 7, 2009 2:10 AM
  • Hi Andrew,

    In most of the cases that I've seen, the architecture is that the BLL is a workflow.  Using the Send & Receive activities should allow you to effectively merge the Services & BLL layer into one layer of Workflow Services. 

    Based on what you said in point #1, it sounds like you'll probably still want other static web services at that layer that expose other business data (i.e. your lookup items for drop-down lists).  Effectively, you'll have a combination of WCF and WF services at this layer that all expose WSDL to the ASP.NET layer in the same way you are used to. 

    Regarding your point about contract-first development, the short answer is that .NET 4.0 RTM will not have an experience for re-using WCF ServiceContract definitions, but it's a feature on the top of our list for the next release, and we're looking at other ways (e.g. out-of-band releases on CodePlex) to supplement the experience.  We're aware this is a current shortcoming and hope to remedy it as soon as we can.

    Regarding the local binding, it will also not be present in .NET 4.0 RTM, but we have tons of customer demand for this feature and hope to add it in the next release.

    Hope that helps,

    -- Dave
    Wednesday, October 7, 2009 10:27 PM
  • Hi Dave

    Thanks for getting back to me - add my vote to those who are asking for localBinding and contract-first development!

    I've been further thinking through your assertion that in most cases the BLL is the workflow. That sounds fair enough, and in the absence of local binding, the logical conclusion is that it would also have to be the service, to prevent the overhead of a second layer of WCF serialisation.

    I like the simplicity of XAMLX workflow services, but I've got another question to help clarify my thinking in this area.

    We're keen to provide users of our application with the ability to make limited changes to workflows through a custom UI. It would make sense to store the XAML of these customised workflows in a database, so we can retain old versions, etc. The WorkflowXamlServices.Load() facility was obviously designed with this sort of thing in mind, as it allows us to load a workflow from a stream.

    Is it possible to somehow dynamically load XAMLX workflow services from a stream in the same way? Or would we need to implement our own custom workflow host to host streamed workflows under IIS?

    Cheers,
    Andrew

    Friday, October 9, 2009 2:18 AM
  • Further to that: if we did need to implement our own custom workflow host under IIS, would that still allow us to take advantage of the upcoming "Dublin" fuctionality?

    -at
    Friday, October 9, 2009 2:24 AM
  • Yes Dublin will be add in on IIS.
    The web download will be installed on top of IIS.
    You would be able to use Dublin for several functionality like monitoring, persistence, messaging, reporting, etc.although you host your workflows in IIS.
    Regards
    Suds
    Friday, October 9, 2009 6:43 AM
  • Hi Suds

    Yes, I realise that Dublin is built on top of IIS/WAS. I was wondering if we'd still get the benefits of it if we implement our own custom workflow host under IIS to allow us to dynamically load XAML workflows.

    I'd prefer to use XAMLX workflow services, which I assume will be supported by Dublin, but I'm wondering if there's any way to dynamically load them from a stream?

    Cheers,
    Andrew
    Monday, October 12, 2009 12:00 AM
  • hi Andrew

    XAMLX workflow services can be hosted in Dublin.
    Persistence and Dynamice Loading is also supported through Dublin.

    Regards
    Suds

    Thursday, October 15, 2009 6:49 AM
  • "Dublin", now Windows Server AppFabric, is designed to work with the default service hosts that you get when you host your services in IIS. If you create custom hosts you may lose AppFabric functionality, particulary if you don't store your service configuation is web.config files.

    Try out your solution on AppFabric. There is a Beta 1 release available at http://www.microsoft.com/downloads/details.aspx?FamilyID=0bd0b14f-d112-4f11-94bf-90b489622edd&displaylang=en. AppFabric Beta 1 works with .NET 4/Visual Studio 2010 Beta 2.

    Try out AppFabric and give us feedback or ask questions at our forum: http://social.msdn.microsoft.com/Forums/en-US/dublin/threads/

    Friday, January 22, 2010 1:33 AM
  • Hi Dave,

    We're actually struggling with the same issue: our existing WF 3.5 system (large enterprise) is built on the WCF contract-first principles all over the place, and we're really missing this feature in WF 4.0.

    We need to be able to "import" contracts into WF WCF Send and Recieve activities, rather than define them manually. Absense of this feature prevents us from migrating to WF 4.0 currently.

    Please let me know if there's a plan to include this experience (for re-using WCF ServiceContract definitions) into the ongoing .NET 4.0 and VS 2010 release on April 12. If not - is there an estimate when it might be available, in one or another form?
    If it takes too long, we may need to write something custom, since we need to migrate from WF 3.5 to 4.0 within the next two months.

    Thank you,

    Igor Pasechnyk

    Akanda Innovation Inc, www.akanda.com

    Wednesday, March 3, 2010 8:05 PM
  • Hi Andrew,

    In most of the cases that I've seen, the architecture is that the BLL is a workflow. Using the Send & Receive activities should allow you to effectively merge the Services & BLL layer into one layer of Workflow Services.

    Based on what you said in point #1, it sounds like you'll probably still want other static web services at that layer that expose other business data (i.e. your lookup items for drop-down lists). Effectively, you'll have a combination of WCF and WF services at this layer that all expose WSDL to the ASP.NET layer in the same way you are used to.

    Regarding your point about contract-first development, the short answer is that .NET 4.0 RTM will not have an experience for re-using WCF ServiceContract definitions, but it's a feature on the top of our list for the next release, and we're looking at other ways (e.g. out-of-band releases on CodePlex) to supplement the experience. We're aware this is a current shortcoming and hope to remedy it as soon as we can.

    Regarding the local binding, it will also not be present in .NET 4.0 RTM, but we have tons of customer demand for this feature and hope to add it in the next release.

    Hope that helps,

    -- Dave

    Now I understand more about it, Thanks for your explanation!
    Friday, February 11, 2011 9:49 PM