Today I’ve started learning about Windows Workflow v4.0, I’m hoping that it will help out with a current project. The original requirement was for mapping real-world business processes to what would normally be complex long-running computer tasks. Whilst investigating what it could do I’m beginning to think there could be real value using it for any task that requires process flow logic, even extremely short-lived ones. This could be controlling page flow through a web application, or even defining the complex logic that can sometimes end up making MVC controller actions fatter than they really should be.
As well as just learning the basics of Workflow; what really interests me is how it should be architected in a real-world LOB application; taking into account the usual “-bility” issues, Scalability, Maintainability and Reliability.
- The biggest challenge will probably be understanding how to manage multiple long-running workflows that have many external dependencies inside a service that can be paused, stopped, restarted and on a server that can obviously be rebooted or even crash. How does the server restart and reload all the workflows it was managing.
- Building from that, how would this all work in a load-balanced environment where you may even have 2 or more of these services running sharing the load – may be a workflow that is started on one server will be persisted/unloaded when it becomes idle and then restarted on another server.
- How can a workflow task be passed between different layers of a system, so it may be started on as part of a web request from a user and passed to a service to be completed a long-running task?
As I start investigating each of these issues I’m hoping that this group of MSDN articles might be a good starting point.
As part of his fantastic ‘What is .NET standard‘ presentation at DDD12, Adam Ralph provided an amazing amount of detail in such a short amount of time. One of the most valuable points, which is completely obvious when you think about it, is how you should work with .NET standard when creating libraries. NET standard now comes in a multitude of flavours: currently 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6 and 2.0. When starting out . . .
If you’re trying to access a class library (.NET Standard) from a traditional console application (in VS2017 those can be found under ‘Windows Classic Desktop’) you will run into problems; which can feel a little strange for something that was pretty simple in VS2015 and earlier. You can add a reference to the class library project (Resharper will even volunteer to add the dependency / namespace reference if you don’t already have it). But the . . .