Runtime Services

The workflow runtime engine supports the concept of external services. Services are class instances that you create and register with the runtime during application startup. Each service fulfills a defined purpose. Services come in two varieties: core and local. The functionality provided by core services is defined by Microsoft. In some cases, the workflow runtime will register its own default implementation of a core service if you don’t provide your own.

Runtime Engine

WF includes a core runtime engine that is represented by the WorkflowRuntime class (found in the System.Workflow.Runtime namespace). The workflow runtime is not a self-contained application. Instead, an instance of this class must be hosted by your application in order to execute and manage workflows. You host the workflow runtime and the runtime hosts the individual workflow instances. The workflow runtime is the component that provides an execution environment for the workflow instances.

Workflow Types

        <h4>
        Sequential Workflow
        </h4>

Workflow basic

Workflow is simply an ordered series of steps that accomplished some defined purpose according to a set of rules. By that definition, what I just described is a workflow.

System.Transaction

You code can be scoped within a scope or no scope at all. If there is not scope wrapping your code directly, your code will follow its caller’s transaction scope. If there is no scope from above, then there is no transaction control in the .net domain.
If there is scope directly scope your code, your code behaves based on the TransactionScopeOption.
If it is TransactionScope.Required, then join the scope above, it is not null, or create scope if it is null.
If it is TransactionScope.RequiresNew, then always create a new Scope.
If its TransactionScope.Suppress, your code will not be part of transaction scope above. This means that if your code execute succesfully, even an error occurred afterward, and the error can rollback ambient transaction, but will not roll back your code. This is different from “no scope” case, in that case your code can be roll back if there is ambient transaction.
When to use what? First you don’t care about your caller, your never know who is going to call your code.
If your code require transaction within(for example you have multiple insert/update/delete inside your code), and your code could be part of outer ambient transaction scope, use TransactionScope.Required. If your code require transaction within, but the transaction is independent from existing ambient transaction(outer transaction), becuase your does not want to be affected by the ambient transaction, you should use TransactionScope.ReqiresNew These two options are similar.
The difficult thing is when to use suppress and when to not use scope at all.
If your code do not want to affect by the ambient transaction, and there is only single insert/update/delete, you should use Transaction.Suppress. If there is only single insert/update/delete, and you want to be part of ambient transaction, do not use scope. Below is chart to help you how to use TransacationScope.


<img style=”cursor:pointer; cursor:hand;” src=”http://bp1.blogger.com/_yUba7cqllFE/RuqOabGkdII/AAAAAAAAACA/SMs3-8ob8Fo/s400/transaction.png” border=”0” alt=”“id=”BLOGGER_PHOTO_ID_5110053311808304258” />