Archive for the 'NServiceBus' Category
Why would you want to test your Windows Workflows and WF Services?
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:
- I’d like to know if a given message types and content cause my workflow to behave exactly as I expect.
- Did my order submission publish a message to any other endpoints interested in the state of the order submissions outcome?
-
If the current state of my workflow is about to be de-hydrated, what are my expectations after handling a given message, were the subsequent expected events raised and or messages sent?
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.
Subjugating Temporal anomalies to satisfy software’s Prime Directive
Having just read one of Howard Dierking’s latest posts regarding how we reason about time when it comes to software, I am reminded about the benefits that one way messaging and publish / subscribe can bring to the table. It stands to reason that we all want our code to execute faster and our applications to respond to their users in a timely fashion; ‘slow’ is not a word users or developers alike want to hear when discussing or describing their systems. Howard’s post is a discussion that came out of his reading a book by Steven Seow titled “Designing and Engineering Time: The Psychology of Time Perception in Software”. I personally haven’t read the book however my interest in doing so has certainly been raised. I am interested here in turning the architectural spotlight onto the strategies for managing time.
Howard includes the following table in his post (the first two columns), demonstrating how perceptions of time in software / human interaction can be managed effectively. As my mind turned to thinking about publish subscribe and one way messaging I decided to add another column to this table clarify my thinking.
| Performance Dimension | Management Strategy | One Way Messaging Pub / Sub Strategy |
| Actual Performance – the precise time durations for completing a task | Operational Management – purely technical strategy (e.g. change the way it works to make it faster) | Let’s push aside algorithmic tweaking designed to speed up computation for just a moment and consider this aspect from a scaling / throughput perspective. In systems that attempt to address this through stateless web services, the strategy is one of scaling out the web servers. If we bring durable queuing into the focus then we can rather more cheaply apply divide and conquer, with patterns such as ‘competing consumer’. In terms of NServiceBus the Distributor is an excellent choice here. Again this is looking at it from an architectural viewpoint. |
| Perceived Performance – the approximate duration for completing a task as experienced by the user | Perception Management – make the task feel like it takes less time (examples include distractions, progress indicators, etc.) | Sending commands or messages to the server for processing and distract the user by maintaining UI state as though the command had been processed. One example is showing blog comments to the submitting user only, whilst waiting for the moderator to approve it. |
| User Tolerance – based on expectations, the approximate duration threshold where anything beyond will be considered slow by a user | Tolerance Management – focus on making users more tolerant of a longer duration when it cannot be shortened or “disguised” | Initial immediate response followed by a subsequent response via a different channel than that sent the message / request. Examples such as Amazon purchases that provide an immediate response and then provides confirmation email. |
In request / response systems, often the focus goes into that described in row 1 column 2 above; that is we tend to narrow in on speeding up our code, substituting for faster implementation technologies or even scaling up our hardware. In the case of stateless Web Services it’s also common to scale out the web servers. With one way messaging and NServiceBus we can increase our throughput and speed (both real and perceived) by scaling out our services and what’s more this can be achieved relatively cheaply with commodity hardware.
It’s also worth noting that the effects of implementing durable queues play’s into the Reliability aspect of the system and when those queues are placed physically adjacent with task based smart client applications that both send and receive messages, then it’s possible to create the perception that work is submitted immediately; potentially it may be repudiated later if there is something wrong with the submission itself. Maintaining a low number of these repudiated work submissions (command / messages) can increase the tolerance levels and the perceived improvement in speed in getting through the work itself.
NServiceBus community support bumper sticker
Anyone who follows this blog or has occasioned to pop in have a look, will likely know that I am a keen advocate and exponent of the wonderful NServiceBus OSS messaging framework. So with an eye on trying to help raise the awareness I decided to quickly make a small textual addition to the logo and put it out here for others to make use of. If your part of the NServiceBus user community or an admirer of the framework, please take a copy of the bumper sticker and make appropriate use of it.
