As a an avid NServiceBus admirer my curiosity about the testability of Workflows in .NET 4.0 led me to ask the question in a group setting recently. One of the responses was “why would you want to test a workflow”? The respondent continued with “surely you would only unit test the components leveraged inside a workflow”? I have to disagree with this assertion! I do want to test my workflows because of reasons such as:
These kinds of concerns when dealing with long running processes in my services really do matter – the business requires such co-ordination to work or fail as described by specification and business workflows inherently contain testable logic - think of your average state machine or consider SLA’s where a de-hydrated (persisted) workflow has passed an acceptable time boundary, raising events commensurate with that business condition. Sure I need to test my business components too but the story is bigger than that!
NServiceBus Sagas are probably the closest correlation to a workflow in the WF stack and Sagas are eminently testable with a baked in testing API designed for the purpose. I guess it’s time to check what WF 4.0 has to offer and see what the story is for myself. More on that a bit later.
Quick answer IMO is no. Some of the known issues with the current version of WF are related around performance, long running hydrated workflow’s and persistence / rehydration and friction with real XAML activation. Because Workflow foundation suffered from some of these design problems it became difficult to deal with and the net affect was that the WF team decided to revamp the technology stack (build a new runtime) to the point where in order to use the next version side by side with the current version, required they build an interop activity to bridge the two. In other words, when we see the next version of WF it will contain a component designed to deal with interop between versions. The key factors for me to consider here are, the period of time between now and the next version release and the time investment to learn any new technology stack meaningfully and it’s my opinion that people will be best served by waiting and moving forward with the next version of WF when it arrives and in spending whatever time they can afford now in becoming familiar with the product whilst it moves through CTP, betas to RTM. See the PDC video’s for more info.
One of the long time criticisms of WCF and ASMX web services has been the lacking of support for Publish / Subscribe. Yes I know that WS-* includes specification(s) to enable this, however if you can show me where on this wonderful planet of ours exists some decipherable prescribed guidance on putting together a store and forward architecture with durable messaging and discoverable endpoints with pub / sub capabilities, I would be very grateful. In the meantime, something that some of my colleagues and I are now considering is how we can leverage the little known and equally poorly documented System.Net.PeerToPeer library in helping us put a reliable messaging framework together that will carry messages over any of the WCF transports available. Now it’s true that WCF includes a Peer to Peer binding that leverages this library, however I have something else in mind.
At this stage we envisage a design where we can deploy WCF endpoints across our network and have them use PNRP to advertise message contracts that they publish for other peers (services) to subscribe. This is very exciting and potentially removes any need to use a registry like UDDI or some home baked thing.
This wont be enough by itself however, issues such as durable messaging, the ability to support idempotent message handling and long running correlated workflow’s, all will require some more infrastructure code that we are going to have to write. The good news is that with some considerable work all these things are possible. My friends and I are planning on using SQL Server Express (Service Broker for it’s queue’s only) at the endpoints to serve a durable store, this also doubles nicely with smart client requirements should they exist in any applications that leverage such a framework. We also plan to utilise Workflow Foundation to manage the long running processes (state machine’s) inside the service. By service I am NOT referring to the WCF endpoints. The endpoints are simple entry & exit points for messages and it’s the services that host the endpoints and their message handlers that we consider make up our services.
This is what an endpoint might look like:
What this diagram doesn’t show is that there is quite a bit of infrastructure code required to glue all this together, perhaps a Bus like API where messages are published and subscribed to and where this ‘Bus’ persists it’s messages to it’s local queue. All messages will be read, sent and removed from queue to discovered endpoints inside a transaction, therefore if any transport of messages from point to point fails the transaction will rollback and return the message to the queue. I have previously defined what the WCF endpoints would potentially look like (at a very rudimentary code level) in a previous post.
To sum up, unless Oslo has something special in store that isn’t making itself plainly obvious then I am quite up beat about this design providing some value as a lite weight framework. Counting down the days but I am not holding my breath, perhaps somewhere deeper in the products release cycle.
As a an avid NServiceBus admirer my curiosity about the testability of Workflows in .NET 4.0 led me to ask the question in a group setting recently. One of the responses was “why would you want to test a workflow”? The respondent continued with “surely you would only unit test the components leveraged inside a workflow”? I have to disagree with this assertion! I do want to test my workflows because of reasons such as:
