*Words of Wisdom From The Elder

A few weeks ago we launched a new feature for one of our internal applications that leveraged Workflow Foundation extensively.  When working through a new technology you will always find curve balls along the way.  I like to call these shiny pennies and rusty washers.  For example, something may seem like a shiny penny when you first see it in a demo.   After much consideration of weighing the features vs the learning curve of the new technology you decide to use it a production environment.   Once something goes into production the game changes.  This is the point where you are going to be held accountable by the business or your client for the technology you chose to use.   This is the point where you have to go deep with the new technology because you have to support it once the “copy to production” button is pressed.  It is during this phase you find some of those shiny pennies are actually rusty washers. 

You will always find rusty washers when you work through a new technology.  There are even some recent examples of this I ran across in blog posts.  For example Jeff Barnes has a blog post about how WCF proxies can only fault once. If you’ve done ASMX proxies you know we don’t have to deal with this.  With WCF apparently the game has changed.  It is an example of a rusty washer with WCF that you wouldn’t know until you tried to put it into production.  Another example of recent that comes to mind is Ayende’s post about NHibernate one-to-one mappings.  Again, another example of something you wouldn’t find out when watching a demo.

To help you limit the amount of rusty washers you will run into with Workflow Foundation, I wanted to share our team’s experience in working through Workflow.  In this multiple part series we’ll look at some of the challenges the team faced and how we solved some of these.  I say “some” of these because we took side steps around the rusty washers we found due to our short time frame.   Hopefully this brain dump of information will save others time who are about to start using Workflow Foundation.  I’ll cover some of the in and outs where you will want to look into workflow and some of the pitfalls we had to work around (the rusty washers). 

First let me say that all in all we are extremely happy with the end product after launch.  We are going to be able to easily modify business rules and adjust quickly for the business.  As a matter of fact we have already had to modify our business rules and add new features.   Our end goal for selecting workflow foundation for this particular project was future agility.  Using Workflow allowed us to hit this mark, but not in the way we originally intended.  If we would have had more time we could have worked through the rusty washers and turned them into shiny pennies.  This brings me to my first point of this series.

It is just an API

The first thing I think everyone needs to understand about Workflow Foundation is it is just an API.  Or to borrow the word from its own name, a foundation to build upon.  It is really no different than building a house whereby you first pour the foundation and then you build something on top of it.    A lot of experienced .Net developers (including myself) think of Workflow Foundation as more of an extension to the core .Net 2.0 framework although it was released with .Net 3.0.  Technically this is true since .Net 3.0 is just that, an extension to the .Net 2.0 framework release whereby WPF, WCF, and WF were added. 

The reason I point out that WF is just an API is to set the initial expectation.  A lot of people I’ve come in contact with seem to think Workflow Foundation is in fact a shiny penny that will magically solve all of their problems.  I’ve heard them say, yeah it is cool, you just drag and drop and you’ve got workflow.  This is where I have to jump in.  The reality is it a core framework for building workflows and Microsoft provides several key components with the workflow framework.   Out of the box you get a:

1. Runtime – the brain of the workflow engine that is constantly running in memory and processing workflows
2. Component model – the pretty user interface that let’s you build workflows within applications or visual studio
3. Rules engine – well, it really isn’t an engine (it is just an API) but a processing mechanism to process business rules against workflows or use as a stand alone rules processor
4. Services – they provide various things such as how workflows should be processed (manual or default) and also things like persistence and tracking.   Services allow you to customize and tweak how Workflow Foundation works.  Example, if you don’t like the built-in persistence table structure you can create your own service and persistence store.

As you can see you get a lot out of the box.  All for the low low price of $0.00.  Not a bad investment huh? 

Question:  What do I do with all this?
Answer:  Anything you want that fits this tools job description.

The point I am trying to make here is Workflow Foundation provides a base model to build anything on top of it.  Take Winforms for example.  Microsoft didn’t ship a collection of pre-built out of the box applications.  Instead they provided the base framework so you, the developer, can build any type of Winform application you need.  Please don’t think of Workflow Foundation in any other way.    In other words, leveraging Workflow Foundation should be treated like an infrastructure investment, not an application investment.   In part two we’ll cover some of the key points you should focus on when building out your workflow infrastructure.  See you in part two!

It is easier to modify a workflow than it is to modify thousands of lines of C# code.

Like this post? 

Don’t you love it when you predict or speculate on something in technology and it comes true?

Before Mix 07 Scott Hanselman and Carl Franklin on Hanselminutes did a show about Silverlight.  During the podcast they mention my blog post whereby I speculated how Microsoft could get WPF/E running on a Windows Mobile device.  Turns out, I was right!.  Here is a little back story for those coming into the game a little late.

Early in January ScottGu and Rory did I a Channel9 video about different things.  After watching it I started putting two and two together and predicted that Microsoft had already solved how they were going to compete with the Apple iPhone and what they were planning.   A few weeks later I was at Codemash and was in an invitation only lunch with ScottGu, other MVPs as well as several Microsoft Developer Evangelist.  Off the record one of the DE’s said my blog post was spreading throughout Microsoft and even ScottGu read the article.  All they could say was it was a “great” idea.  Obviously I was onto something. 

Fast forward a day or so later I got word that I was officially on the right path. 

At Mix 07 Silverlight was officially announced / released and the very early prototype of Compact Silverlight was shown at Mix 07.   Yep, there you go, I was right!  If you want to see it in action download this video  and fast forward to around the 14 minute mark for the Windows Mobile version.  Also check out Rob’s blog post about the Compact Silverlight Framework. 

Obviously this opens up a whole new realm of possibilities on the mobile platform.  Just think what Windows Mobile 7 will bring to the table.  It could be earth shattering UI on a mobile device that will finally bring a true user experience to the mobile platform.  I’m in! 

Thank you for those who believed in my previous speculation, I’ll be here all week.  Tips your waitresses.

Yesterday was the Day of .Net hosted in Ann Arbor.  It was great to see tons of people I haven’t seen in years.  I went to several talks including Dustin Campbell’s talk on Reflection.  I learned more about reflection during Dustin’s talk than I ever wanted to know.  I also went to Dan Hibbitts talk on Mobile Software Factory.  Rounding out the day I went to Mark Miller’s talks on WPF and WPF/WCF.  I have to hand it to Mark, he did a really good demo of WPF and WCF whereby he built a hockey game whereby one could be the server and the other the client.  Moving the mouse on one application moved it on the other.  From the gaming industry standpoint this is nothing new since network games have done this for awhile.  However, it was a great WPF and WCF demo to show tcpBinary messages being sent from application to application. 

As Dan has already vocally exclaimed on my other post I killed the projector during my talk.  My talk was scheduled during the last session of the day and I was ready.  What I wasn’t ready for is about 45 minutes into the session, right before I got into the really cool demos of deploying the application using ClickOnce, I kicked the power cord out of the socket and took down the projector.  If you know projectors at all you know they don’t like being shut off without warming down so essentially I took the projector out for the remaining of the talk.  Let me apologize to everyone for robbing you of what was going to be the best most well thought out earth shattering demo you would have seen the entire day.  🙂 

For those that are in the area I promise to makeup for it Wednesday when I speak at the Ann Arbor .Net User Group.

One of the engineers that works on the same team I work on blogged about his trials and tribulations of using Enterprise Library 3.0 with Environmental Overrides.  Last week I checked in Enterprise Library 3.0 into team foundation server and he got assigned the task of re-configuring all of our config files to use the new feature of environmental overrides.  Currently we have test, beta and prod environments for our main application so this was something we thought we could immediately benefit from. 

His review it turns out is less than shiny based on how environmental overrides were done in EntLib 3.0 which I found somewhat surprising.  When he called me over the weekend complaining about how stupid he thought the implementation of it was the first words out of my mouth were, I can’t wait to read the blog article.

He got it posted this morning, you can read it here.  Anyone else agree with Morlock or have a different opinion?

For the past several days I’ve spent a lot of time trying to get up to speed using Windows Communication Foundation.  I’ve seen or watched enough “Hello World” demos of WCF over the past year to choke a good mule to death but I haven’t had a chance to write anything using WCF for real world experience.  I knew I’d get around to it eventually.  This is the point where you actually learn how to use a technology anyway.  Having done large scale applications with Asp.Net web services for quiet sometime I honestly didn’t figure it would be that difficult.   I was wrong.  My first real world venture into WCF left me scratching my head and feeling like a 12 year again. 

My reason for using WCF is I’m staring a new project which will be a Smart Client application used to build and manage business rules for different .Net applications leveraging the Windows Workflow Foundation rules API.  Since I was leveraging the .Net 3.0 framework anyway, I thought now was as good a time as any to jump into WCF. 

Once I defined my database structure and calculated which web service methods I was going to need, I created my ISomethingInterface contract which defined my methods.  I then implemented those methods in my service.  Very simple stuff at first, then I pressed F5 in Visual Studio and I was greeted with errors because my web.config file wasn’t configured.

I knew I had to configure the service and so off I went researching how to write the web.config file to expose my service.  I went to MSDN only to learn that I was going to spend the next several hours reading all of these different configuration options (WCF is flexible, but with flexibility comes more to read).  I gave it a college try trying to configure the web.config by hand and then eventually got frustrated because it wasn’t working.  Finally after doing some other searches I see a screen shot of a new item menu in the context menu when you right click the web.config file called “Edit WCF Configuration”.  I click it and get this:

If I’d only know this was there earlier.   After I got my service configured so it gave me a result other than an error page I *thought* I was going to get the same type of page you get with normal Asp.Net web services which is a page that shows you the methods available.  I was wrong.  I got this:

Where’s my list of web methods!?  Not there.  Again different from what I was expecting.  By this point I had resigned myself to throwing everything I knew about ASP.NET Web Services out the window because obviously previous knowledge was not really helping. 

I decided to absorb my new service in my client.  Since I had gotten burned by the right mouse click thing earlier I decided to see if the WCF CTP put a menu item in my project so I could generate the class file with svcutil.exe instead of wsdl.exe. Sure enough it was there.  This was the only thing that left me warm and fuzzy, something I had done before.   I then wrote a quick line to leverage the service (which I had placed in a separate Class Project) and it didn’t work.   The app.config file generated was placed in the project file where the service was generated, but not in the project the application was going to run from.   Luckily I was smart enough to just copy the one created for me and it worked.  Again, different. 

Feeling I had made progress I made the methods I wrote work, wrote unit tests for them and then baked them into the user interface of the application.  Then it hit me that I needed to call these services asynchronously.  So I typed “service.” and waited for intelilsense to see what the async calls were named.  They weren’t there!  Uh oh.

Doing some more digging I learned the svcutil.exe has a switch to generate asynchronous calls. The switch is /async.  Reading further there are different types of async calls and this is where I am currently at, trying to figure out what I really need to do and all the ins and outs of async calls in WCF.  Obviously lots of differences as I move further into WCF.

I did find a really good article which tells the developer what the differences between the two are, you may save yourself some headaches.  There are also some other documents nearby this one in the menu on MSDN that you may want to read as well.