I have been making a prototype to evaluate the new incarnation of the Windows Workflow Foundation (WWF 4 beta 1), which will be part of the .Net 4 release. I’m glad of the new changes so far, asynchronous operations are now much easier, and this also applies to activities authoring too. I’m not so happy with the designer, it’s still a bit slow, although it is not an issue for me right now.
Workflow isolation has also been left behind. Running untrusted code can completely break the engine wich will also stop the other workflows running in parallel along with the faulted one. This is a big issue when running unmanaged code, where memory access violations or any other severe exception will crash the process. Writing the correct infrastructure to handle this situation is not trivial.
Many business problems are easily modeled using workflows, specially now that asynchronous transactions have been improved in this beta release. And WWF supports many (if not all) of the common workflow patterns. State machine workflows seems to be hard to implement with this release but I haven’t look into this yet.
You can find more info at the Windows Workflow Foundation for .Net 4 developer center: http://msdn.microsoft.com/en-us/netframework/aa663328.aspx
More on workflow patterns here: http://www.workflowpatterns.com/patterns/index.php
I was reading the SOA pattern – Reservations from Arnon Rotem (blog) I found it quite interesting. You can see it as a mix of optimistic resource locking with expiration time, where the service itself can revoke the lock in the first place due to some internal reason.
Although this pattern may not be applicable in all scenarios due to the fact that the reservation may not be effective when the transaction is committed, making this assumption more restrictive (resources are guaranteed until the expiration time) makes this pattern more widely usable.
By providing several levels of guarantee the service can offer its resources to more consumers if some of them doesn’t require a high level of guarantee because they can compensate for ineffective reservations. This also adds another order of complexity in logic though.
You may already know Aspect-oriented programming and how further decouple non business logic from the model. .Net has been using this paradigm across various frameworks like WCF by using attributes. Reflection has been for me the only reasonable way to exploit these attributes so far, which means the behavior is changed in runtime (which also added complexity). You also had to write down how this attributes are handled which didn’t help concentrating code.
PostSharp is a true AOP helper here, letting you completely describe the business and adorn the fields, methods and classes with .Net attributes. During a post-build step, the assembly is injected with some code based on those attributes. The aspects are encapsulated as attributes freeing the team from writing tons of repetitive lines. Decoupling aspects from the main logic also encourages code reutilization and increases maintainability by unifying scattered code in just one place. Although sometimes finding current crosscutting concerns in the code, or taking the effort to re-implement them as aspects can be overwhelming at first.
PostSharp 2.0 has gone even further allowing dependency solving which is something very promising (although its license may change).