Workflow Foundation (.Net 4.x System.Activities workflows) over Microsoft Orleans framework, providing stable, long-running, extremely scalable processes with XAML designer support.
Workflow Foundation (.Net 4.x System.Activities workflows) over Microsoft Orleans framework to provide stable, long-running, extremely scalable processes with XAML designer support.
Master: AppVeyor project feed (NuGet source)
Guidelines
This project is licensed under the Apache License.
Only in case of projects with designed XAML workflows!!!
Don’t use Microsoft.NET.Sdk, use old project format (Sdk has no XamlAppDef BuildAction)
Use at least VS 15.6 (older VS 15.x Activity designer crashes when Microsoft.Orleans.Core.Abstractions is installed via NuGet 4.x PackageReference tag)
The key concepts behind Workflow Foundation and Microsoft Orleans are very similar, but Microsoft Orleans solves the pain points of Workflow Foundation (WCF and SQL oriented, non-scalable).
Workflow Foundation | Microsoft Orleans | |
---|---|---|
✓ | Single threaded | ✓ |
✓ | Persistent reminders | ✓ |
✓ | Stateful | ✓ |
😐 |
Communication | ✓ |
😐 |
Storage | ✓ |
✗ |
Scalability | ✓ |
We kept only the the "good parts" of Workflow Foundation, the WorkflowInstance
(a mini Virtual Machine executing the Activities) and replaced everything else with Microsoft Orleans, ie. we replaced WorkflowServiceHost
with Microsoft Orleans Grains
(stateful actors).
Integrated:
A typical workflow grain ("domain service" grain) manages operations in other normal grains ("aggregate root" grains) and handles only the process specific data in it's own state.
This is a very high level view:
WorkflowGrain
is indistinguishable from a normal grain and backed by a WorkflowHost
.WorkflowHost
is responsible to handle the lifecycle of the WorkflowInstance
, mainly recreate it from a previous persisted state when it aborts.WorkflowGrain
and the WorkflowHost
is based on 2 developer defined interfaces for the incoming and outgoing requests (TWorkflowInterface
and TWorkflowCallbackInterface
).
TWorkflowInterface
and TWorkflowCallbackInterface
are independent from the grain's external public interface, you can merge different public requests into one method or vice versa. Or a reentrant grain even can execute (read-only) public interface methods independently from the current running workflow operations.The goal, is to keep the C# code in the grain, and use the workflow only to decide what to do next. This way we can avoid a steep learning curve to use workflows: the developer doesn't need to write or to understand anything about activities, he/she can build workflows with the provided activities in a designer.
Integrated:
Extra implemented features:
Under construction:
Not implemented, help wanted (for design and for implementation):
With tutorial level, detailed descriptions!
HelloWorld - How to communicate with the workflow through custom interfaces.
Arithmetical - How to execute the complete workflow like a method.
You don't need to understand this to use the project! This is for those who want to dig in to the source!
This is still an overview, all the details of the classes are hidden. The goal is to give a map to understand the relations between the classes.
The 2 generated proxies translate the calls between the TWorkflowInterface
and TWorkflowCallbackInterface
interfaces and the workflow's API, where the methods are identified by their names.
For more details see the detailed comments in the source!