When Written: June 2010
Microsoft Workflows enable business logic to be designed rather than just coded
When developing large scale line of business web applications one of the very important things is to be able to handle long running transactions. For example a user may submit a web form which sends a response to another user which will then require a response and this response needs to update the first user on the result. A typical scenario is on-line shopping where keeping track of a user’s shopping cart is very important even if the user gets distracted and their session times out you still don’t want to lose their information or custom.
A shopping experience should even survive a disruption to the service and be able to rollback and recover to the last complete action. Whilst it is quite possible to write such code yourself, I would suggest that you take a look at Workflows in Visual Studio 2010.. I must make it clear here that Workflows are not new but their implementation in Visual Studio 2010 has been improved considerably. Workflows are a particular type of project which enable you to graphically design the flow of your web application and each step will become a transaction that can be monitored within IIS.
Should any one step fail it will not cause the whole transaction to fail and will resume the rest of the transaction once the reason for the fail is resolved. Workflows also require a plug into the management console to IIS so that the various stages can be monitored and restarted, should that be necessary. So what is it like to develop a workflow? Whilst my initial reaction was a very favourable one with a nice graphical representation of the workflow, looking a bit like a normal flow chart, it is when one comes to have to fill in the various parameters is where things get tricky.
So with an aim to try and get my head round this seemingly useful technology I took a look at some of the on-line training videos on the Microsoft site. These help videos that Microsoft provide are the sort that so often start nice and slow showing you how to open a project in Visual Studio, which let’s be honest if you didn’t know how to do that then you don’t stand a chance with the rest, and then the instruction speeds up providing very little explanation as to the reason for each of the actions of the demonstrator. So unless you are trying to rebuild exactly the same application as the demonstration, the video ends up being of little help in explaining the how to use Workflows in detail. I am still battling with writing some real-world code using workflows and will report back when I have cracked it., but the whole concept and resultant strengthening of your web application looks to me worth the effort.
The disappointing training videos for Workflows are not an isolated problem in my opinion. This is so often the case as I’m sure that the demonstrators are under enormous pressure to get these examples out, in an effort to keep up with the each release of a new technology. In fact I came across a forum posting on the Microsoft developers forum that made the call for the developers of .NET and Silverlight to now slow down and consolidate and improve the often buggy demonstration code and poor videos.
This thread became quite active over a couple of days including a posting by yours truly, so it seemed to have hit a nerve, and the response from Microsoft was that they were taking the comments on board. We shall see if things change, but with the never ending pressure to stay ahead of the competition I suspect that there is little chance of any of the big companies slowing down development so that their training resource teams can catch up.
Article by: Mark Newton
Published in: Mark Newton