1. You only need one instance of the workflow runtime for each process, and you are not allowed to have more than one instance for each AppDomain. The best thing you can do here is to create the required instance directly in the form's constructor. The same runtime object can take care of a variety of workflow instances. The runtime distinguishes instances based on their GUID, and receives private data for each specific instance.
2. There are two general approaches for receiving data into a workflow from the host application when it is instantiated;—parameters and events.
3. Two Type of Workflows: Sequential and State Machine - A sequential workflow is a predictable workflow. The execution path might branch, or loop, or wait for an outside event to occur, but in the end, the sequential workflow will use the activities, conditions, and rules we've provided to march inevitably forward. The workflow is in control of the process.
A state-machine workflow is an event driven workflow. That is, the state machine workflow relies on external events to drive the workflow to completion. We define the legal states of the workflow, and the legal transitions between those states. The workflow is always in one of the states, and has to wait for an event to arrive before transitioning to a new state. Generally, the important decisions happen outside of the workflow. The state machine defines a structure to follow, but control belongs to the outside world.
We use a sequential workflow when we can encode most of the decision-making inside the workflow itself. We use a state machine workflow when the decision-making happens outside the workflow. In this chapter, we will take a closer look at how state machines operate. Read More here.
4. When you create a new Sequential Workflow Console Application project. The Visual Studio 2005 Solution Explorer will contain two files—workflow1.cs and, initially hidden from view, workflow1.designer.cs. These two files represent the workflow being created. A Windows Workflow Foundation workflow consists of the workflow model file and a code file class. The workflow1.cs class is the code file class where you can write your own workflow business logic. The workflow1.designer.cs class represents the description of the activities map. This file is managed automatically by Visual Studio 2005 in much the same way it happens with forms in a Microsoft Windows Forms project. As you add activities to the workflow, Visual Studio 2005 updates the designer class with Microsoft C# code that programmatically builds the map of activities. To continue with the Windows Forms analogy, a workflow is like a form, whereas activities are like controls.
You can choose another form of persistence for the activity layout—the XML workflow markup format. To try this approach, you delete the workflow1.cs file from the project and add a new workflow item “Sequential Workflow (with code separation)”
Now your project contains two files—workflow1.xoml and workflow1.xoml.cs. The former contains the XML workflow markup that represents the workflow model; the latter is a code file class, and contains source code and event handlers for the workflow.
5. At run time, changes to the collection of activities are also possible, and give you the ability to make changes to a running instance of a workflow.Workflow changes are motivated by business changes that were not known at design time, or by the need for business logic that modifies and then completes the business process. In any case, it should involve limited changes;—perfecting rather than redesigning.
6. Workflow can be exposed as a webservice. The Windows Workflow Foundation framework supports Web service interoperability, which includes the ability to expose a workflow as Web service to ASP.NET clients and to other workflows. Windows Workflow Foundation supports publishing a workflow as an ASP.NET Web service on a Web server or server farm running ASP.NET on Microsoft IIS 6.0. The Windows Workflow Foundation framework activity set contains the WebServiceReceive and WebServiceResponse activities, which enable a workflow to be used as Web service endpoints.
In a real time application, it may take weeks or more for workflow to reach a final/complete state. Fortunately, state machine workflows can take advantage of workflow services, like tracking and persistence (both described in Hosting Windows Workflow). A persistence service could save the state of our workflow and unload the instance from memory, then reload the instance when an event arrives weeks later.
No comments:
Post a Comment