Well now, this was a fine how-do-you-do on a Wednesday morning...

http://footheory.com/blogs/bennie/archive/2007/05/12/simple-application-extensibility-with-wf-rules.aspx

Holy cow!  Turns out the rules engine that ships with WF is usable in your own application, even if you're not using workflows at all!  This is incredibly cool.  A little background for the uninitiated...

Windows Workflow is a technology that ships with .NET 3.0.  It enables you to express program logic and control flow visually, in what looks a bit like a Visio diagram.  It directly enables things like continuations and passivation in your software.  It is, in general, a Very Big Deal... though it usually plays second fiddle to WPF and WCF when folks start discussing .NET 3.0.

One of the features of WF is a business rules engine that can be used to author and execute rules against workflows in your application.  The rules work against internal workflow state, and produce side effects during execution to modify that state in some meaningful way.  For example, your workflow might expose properties such as AccountName or OrderAmount, so a simple rule might be (in pseudo-code):

if this.OrderAmount > 100

then this.Discount = 10%

else this.Discount = 0%

The idea is that you express such rules out-of-band from your code, which provides really nice maintenance and visibility benefits.  Since rules tend to be the core value of a software system, they're best not buried inside layer after layer of C# code where only a programmer can maintain them.

You get an out-of-the-box editor with Intellisense for rule authoring.  In addition, there are standard hooks in WF (through the use of PolicyActivity, typically) for invoking the rules at runtime.  This all works great assuming you're authoring and using workflows in your application.

Okay... so here's the neat part.  You can use this rules engine even if you aren't using workflows.  There's a great sample on the WF community site that demonstrates how to re-host the rules designer in your own application, as well as how to use alternate storage mechanisms for rules (by default, rules are saved to a file in your workflow project, and the file is compiled as a resource).  But, that code is still relying on workflows and custom policy activities to execute rules.  So the code from this sample is used in the other sample found at the link I mentioned at the top of this post to demonstrate rule execution without workflow involved at all.  I also re-purposed the base sample code to whip up my own demo app.

Here's a screenshot of rule authoring against my own "User" type (which has properties like Name and Age):

Notice the full Intellisense support for my custom type... this makes rule editing a breeze.

Once you edit and save your rules (storage is just a single table in the SQL database of your choice), you can then reference the rules (sets of rules, actually) by name at runtime, for execution.  Here's a code snippet:

// create my user object...

User joe = new User();

joe.Name = "Joe";

joe.Age = 35;

joe.Valid = false;

// next several lines execute the ruleset called "User2"...

RuleSetService svc = new RuleSetService();

RuleSet ruleset = svc.GetRuleSet( new RuleSetInfo( "User2" ) );

RuleExecution exec

    = new RuleExecution( new RuleValidation( joe.GetType(), null ), joe );

ruleset.Execute( exec );

// okay, ruleset has executed, let's see what the outcome is...

Console.WriteLine( joe.Valid.ToString() );

And that's it... about 4 lines of code to invoke a ruleset at runtime.  And again... no workflow in sight.  Not that I have anything against workflows, it's just nice to know you can use the rules engine by itself if/when needed.

I've uploaded my own sample application here.  Grab it, unzip, restore the database backup, check your config file connection strings, and party on.  There are 5 VS.NET 2005 projects included... 4 of them are modified versions of the code found in the previously mentioned WF community site sample, the other (called "Tester") is my own sample that exercises some rules I created through the designer.  So just to be clear... most of this is not my own code.  But that also speaks to the beauty of this approach... most of the heavy lifting is done for us already, so it's easy to get up and running.

Enjoy!

In an earlier post, I discussed my interest in Silverlight as a means to off-load CPU-intensive processing to web client machines, which are often just sitting around parsing angle brackets and not much else.

The idea is to do some work on background thread(s), so your Silverlight-enabled browser UI remains responsive, but you still get the benefits of doing less work on the server.

Turns out you can indeed spin up background threads in the Silverlight CLR, but there's currently no good way to marshal UI updating behavior from a background thread to the UI thread... ala Control.Invoke() in Windows Forms.

The "best" solution for now seems to be to maintain some shared (non-UI) state between your threads.  You update the state from a background thread upon completion of some long-running task; meanwhile, from the main UI thread, you periodically check (through use of HtmlTimer, a decidedly low-rez timer component) if the state has changed and when it does, update your UI.  It's inelegant and tedious, but it more or less works. 

I worked up a quick demo... you can get it here.  Note that you'll need Orcas Beta 1, Silverlight 1.1 alpha, etc. to make this work.

I've heard that the Silverlight team plans to provide a high-resolution timer in a forthcoming release... this will help, but frankly I think they should go one step further and implement some type of thread dispatching behavior, so we can avoid these kinds of hacks.

Silverlight isn't just about UI glitz and glamour... we can get some Real Work Done with this thing, given the right tools.  C'mon, Microsoft... help us out!

...to my faithful readers (all 3 of you, including Mom ).  I've had to undertake some major blog surgery this weekend... switched hosting providers AND blog engines... now running on dasBlog.  Community Server is nice enough, but it was getting in the way of me getting stuff done.

Links and URLs and feeds are pretty hosed right now... we've got our best man on it, I promise.

Your patience is appreciated... and, assuming you're gonna stick around, mandatory. 

I couldn't help but chuckle at the installer for the WF-based ASP.NET Pageflow sample.  It first asked me for installation directory, etc. and THEN presented the software license page and asked for my consent.

Um, isn't that supposed to be the other way around?  Does the Pageflow installer need, well, better Pageflow???

NEVERTHELESS... interesting application of WF.  Might be useful on some stuff I happen to be working on right now, in fact.  I'm particularly interested in exploring the new NavigatorWorkflow base workflow type that drives the whole thing.  WF comes with support for sequential workflows as well as state machine-based flows; I knew the support for additional base types existed, but this is the first time I've seen it used in the wild (maybe MOSS 2007 workflows use a custom base type too?  Not sure...).

Been a long week... I'm a little punchy.  TGIF. 

I've been poking around with the Silverlight 1.1 alpha release bits lately. My interest is probably a bit different than most folks... the whole RIA thing is certainly very interesting, but I'm exploring the idea of using .NET in the browser to enable background processing scenarios for web apps.

My company builds financial apps that do long-running, CPU-intensive calculations. These are typically rich client, Windows-based applications. Recently, we've begun exploring how to move some of our core processing functionality into web applications, and distribute it to a larger audience. Now, it's one thing to scale server software (even with CPU-intensive work) for a few users... it's another thing entirely to have hundreds of users hammering away on your server infrastructure.

I've explored some options for scaling our processing out, using dedicated server farms and well-known distributed processing architectures... there are caching and latency issues there, as well as deployment and configuration concerns. But those are solvable problems.

But once I saw Silverlight, I immediately started thinking beyond the fancy UIs and about how we can leverage that browser-based runtime for doing real background work. This allows us to offload work from the server, and localize it to its point of origin... so users who initiate lots of processing through their own actions are themselves paying the "CPU tax", and users who do little processing don't pay the price.  Woohoo server scalability!

Okay... so I started working on some simple Silverlight prototypes for doing background processing. System.Threading is there in almost its entirety... this is a Good Thing.  Very easy to spin up a thread, do some work, then synchronize back to the main UI thread. But now we've got a problem.

In Windows, you can't update your user interface from a background thread. Many windowing primitives (textboxes, etc.) use thread local storage to hold their state... so the thread the controls are created on (i.e. the main UI thread) is the only thread that has access to that state. This is a known problem that has existed in Windows programming for years. In .NET, we have a few mechanisms for dealing with it... BackgroundWorker is one, and the Control.InvokeRequired/Control.Invoke pattern is another. (As an aside, if you want to learn how to use these properly, you should sit in on DevelopMentor's Essential .NET class, which I happen to teach ).

So... back to the problem. I don't see BackgroundWorker or Control.Invoke/Required defined anywhere in the Silverlight version of the CLR! BackgroundWorker isn't really expected... it's fairly WinForms-specific. But no Control.Invoke and friends is a problem. So even though I can spin up a thread to do background processing in the browser, I can't update my UI as a result of that processing without resorting to hacks like this. Bah.

I know, I know... it's an alpha release. But System.Threading in Silverlight becomes significantly less useful without some easier means of accomplishing this. Anyone got any better ideas?

I've been busy at work for the last several weeks, and haven't had much time with the blog lately. But I noticed that the spammers found me, so I've had to disable comments for now. I hope I can turn them back on soon.

More to come on what I've been digging into... SharePoint 2007 and AJAX-ilicious web parts, Silverlight and DLR stuff (woohoo!), LINQ and C# 3.0 enhancements (double woohoo!).  Oh, and I'm gearing up to teach DevelopMentor's WF course in late July, as well!

Hope I get to go fishing sometime soon... 

Great advice.

Last weekend, Cary and I spent a few hours hiking the Benton MacKaye Trail in the north Georgia mountains, near Skeenah Gap.  We climbed Rhodes Mountain, to the point at which the BMT meets up with the Duncan Ridge Trail.  It was just under a 1000 foot elevation gain over a few miles, so nothing too strenuous (especially since we left the girls with Grandma this time ).

No pictures unfortunately, but nevertheless a great walk in the woods.

Saw this post today describing basic guidance for when to use the different numeric data types available in C#, apparently from someone on the C# compiler team.

It's amazing how many developers go through life lacking even a basic understanding of the appropriateness of one numeric data type vs. another, for a given situation. I've found this to be especially true for financial applications... if I had a dollar for every time I saw floating point datatypes used in database schemas or source code to represent employee salaries, or bank account balances, etc., I'd own a ski house in Park City, like I'm always dreaming about. 

For the sake of completeness... if you're modeling flocks of birds or something, go ahead and use floating point types. But please do our collective profession a favor and use fixed point data types (that's System.Decimal in .NET, or decimal/money/smallmoney in SQL Server) if you're doing calculations involving money, or in general when rounding errors are not tolerable in your problem domain (like, you know, with money and stuff  ).

One more thing... the last line of advice reads this way:

Byte, sbyte, short, ushort, uint, and ulong should only ever be used for interop with C code. Otherwise they're not worth the hassle.

I'm pretty sure I can't agree with this, in particular for unsigned types. The author explains that unsigned types can be confusing, if you're not expecting values to wrap around from the lowest possible value to the highest. For example:

// some C# code...
uint x = 5;
uint y = 6;
uint z = x - y; // hmmmm...

Debug.Assert( z == uint.MaxValue );	// evaluates to true...

It's true that this will surprise some people the first time they see it. And I suppose with the unsigned types you're more likely to encounter this issue than with the signed types, since values close to zero occur more naturally "in the wild" (I guess)... but the fact remains that the signed data types work this way, too...

// more C# code...
int x = int.MaxValue;
int y = 1;
int z = x + y;

Debug.Assert( z == int.MinValue ); // again, true...

So I'm not sure what avoiding the unsigned types buys you, from the standpoint of avoiding this potential confusion. At the end of the day, it's probably best to simply understand how this stuff works, and don't arbitrarily limit your use of some language or platform feature only because someone else tells you it might be confusing.