I need to take some advice from the Architectural community out there, as much of the discussion to date appears to focus on an application hosting the WWF engine and exchanging events in a fairly self contained fashion.
Scenario
Consider...< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Many instances of a windows forms client application communicate with a server application via web services. Traditionally the server side business logic contains set workflow. With WWF this is extracted (abstracted) to allow a richer design environment, etc.
Our intent is to run a (single not sure how workflow scales yet) server side workflow Host that implements a number of workflow designs. At runtime many instances of these workflow designs will be executing concurrently...ie as an actor engages a workflow it is instantiated and executed and so many instances of the same workflow may be executing and/or many instances of different workflows may be executing. Is this best practice for this type of enterprise application
A couple of questions that remain unanswered, or perhaps unclear, to me:
1. What is recommended best practice in terms of event exchange between server side activities and a client Web service activity direct (not sure if this is possible at an activity level) or event activity fronted by web methods outside the workflow host
2. As workflows change ie activities are added/deleted what would be best practice in terms of updating the client UI. Perhaps custom controls are associated with an activity As new activities are developed these custom controls are pushed to the client and are somehow self registering perhaps through visual studio click once deployment
Some discussion around < xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />
using WWF with SOA
Cees Versteeg
Actually each event is raised to a specific activity, it would be the activity that's waiting for that type of event in the workflow instance.
Do keep asking these types of questions, and ask more as you learn more about WF.
Regards,
Paul
Bontempi
Yes, a server hosting the WF workflow runtime for purpose of starting a large number of concurrent workflow instances on behalf of clients is a good scenario for Windows Workflow Foundation.
1. From the client you need to route an event somehow to the server abd specifically to the workflow runtime. The workflow runtime will identify the correct workflow instance and pass the event to it. For the case of web services we have a wizard which will generate code for the web service and sends the event to the workflow instance. Try it out.
2. WF is about abstracting the business process and business logic in your application. In your scenarion you are considering representing the user interface business process in WF. You still have to build your user interface component using traditional techniques. What I mean is that WF doesn't provide anything new for building user interface - excepting a method for separating the business logic out of the user interface.
Regards,
Paul
naxtell
Thanks for your immediate response! It's reassuring to know we are on the right track.
Further to point 1:
I take it the event cannot be raised directly on an activity, under this scenario, but must be passed to the workflow host which may well rehydrate the instance (according to workflowID) and pass the event to the appropriate activity.
Regards
Greg