You have reached the blog of Keith Elder. Thank you for visiting! Feel free to click the twitter icon to the right and follow me on twitter.

Enterprise Library Feedback – Integrate GAT and Workflow

Posted by Keith Elder | Posted in .Net, Programming | Posted on 22-06-2006

Tom Hollander, who is on the Enterprise Library team, posted to his blog the Enterprise Library team want everyone’s feedback for the .Net 3.0 framework release.  As I sat and thought about this in relation to .Net 3.0, the more I thought about it and started to write about it, it just all became crystal clear.  Here’s my wishlist for EntLib 3.0:

  1. $20 – Add the EntLib console configuration tool into Visual Studio IDE.  Lot’s of people mentioned this in comments, so it looks like this should definitely be on their list.
  2. $20 – Integrate GAT to assist setting up EntLib based on the best “patterns” and “practice”. 
  3. $60 – Workflow Block

Integrating GAT with EntLib
Number one above is is self-explanatory so let me first start with number two.  If you think about abstracting and best practices and patterns you think of EntLib, however, there is one missing piece of the puzzle.  That missing piece is there is a best practice and pattern for how to setup and use EntLib.  If you are starting out using EntLib you are more than likely not going to use an “established best practice or pattern” as to how you should use EntLib.  I’ve seen this over and over when you want to create a new application to use EntLib you wind up holding onto one configuration file that you are familar with and copying and pasting.  Wouldn’t it be nice to simply install EntLib and using the GAT (guidance automation toolkit) you could create an “Enterprise Library Web Service”.  The GAT would then guide you through a configuration wizard of best practices and patterns on the recommended configuration and setup for EntLib based on the chosen application.  At least this would provide a baseline, and I think, a higher adoption rate of Enterprise Library in the enterprise.  It would also make it easy for anyone to start using thereby eliminating lots of training overhead to get up and running.

Workflow Application Block
Let me explain my reasoning for the Workflow block and why I invested so much into it. First and foremost Tom asked what we would want in regards to the 3.0 framework.  One of the new features of the 3.0 framework will be Windows Workflow Foundation.  For developers, this simply means you have a new set of APIs namespaced as System.Workflow. 

If you look at the existing blocks of Enterprise Library ( data, logging, exceptions, etc) these are all derived from currently existing Namespaces within the framework. The goal of these blocks are to abstract, simplify and tie each block together so it can be used with one another.  This is where the power of Enterprise Library comes in.  Since this would be a 3.0 release of Enterprise Library, Workflow is a major new namespace that will be available to us in the .Net 3.0 framework.  Having an easy way to re-configure workflow through an application config file and/or manage workflows via an application block to me makes perfect sense. If you’ve played with Windows Workflow Foundation you realize a lot of things could be abstracted.  Really this abstraction is no different than how EntLib provides the data block today.

Here are a couple of scenarios how I would want to use the Workflow block.  For example, imagine being able to configure EntLib when an exception is raised to be processed through the Workflow block instead of how we do it today via Categories. So based on the exception type, time of day, user that created the error, what phase the moon is in and how the stars align at that given time, the error could be routed via the Workflow block to the appropiate place.  With place being an email, log to database, notify pager, create a support ticket in an internal helpdesk system, notify your helpdesk, whatever.   Essentially what we *try* to do with EntLib today a lot of the time is make our logging blocks do workflow by creating tons of different categories based on different rules.  We wind up with a HUGE config file that becomes, well, HUGE.  Instead of doing things the way were are today, just simply have a workflow that you can define to handle all logging, exceptions or whatever.   

That’s my $.02.  I’ll be here all week. Smile

Write a comment