This project is read-only.
1.2 release
Added logging to the sequential workflow class using the open source log4net library.

1.1 release
Workflow assembly no longer references any WPF assemblies. This makes it possible for non-WPF applications to use Samurai.Workflow without referencing PresentationFramework. It now uses reflection to check for the existence of the UI thread dispatcher if any workflow steps are told to execute on the UI thread.

Sequential Workflow

The sequential workflow in Samurai.Workflow is not designed to replace long running workflows like those built upon Windows Workflow Foundation, but rather to make smaller, short running operations easier to maintain, test and synchronize It's simple to use and allows multi-step processes to operate on different threads. Steps in a workflow can execute on different threads and a common context will be passed between the steps to ease synchronization.

Workflow in WPF Applications

Windows® Presentation Foundation (WPF) is a great technology for creating compelling user interfaces, but certain operations can make your WPF application seem unresponsive. The simple fact is, no matter what type of long-running processes are involved—whether getting large results from a database, making asynchronous Web service calls, or any number of other potentially intensive operations—making your application more responsive is guaranteed to make your users much happier in the long run. To achieve this, long running processes should be done in the background to free up the UI thread to respond to user actions. When the process has finished, the UI must be updated with the UI thread. WPF requires that most of its objects be tied to the UI thread. This is known as thread affinity, meaning you can only use a WPF object on the thread on which it was created. Using it on other threads will cause a runtime exception to be thrown.

The scenario above can be made much easier by using the Samurai Workflow framework. First, create a workflow and define steps for each operation. Each operation can execute a different thread and still be managed by the overarching workflow, which will dispatch data between workflow steps.

Last edited Jun 23, 2010 at 4:36 AM by akilhoffer, version 8