Develop Reference

Dynamic Business Rules

I am creating an interface where users can build their own business rules out of domain specific objects at runtime, have those rules persisted in the database and then used by the application. Some of these are complex predicates and others require combinations of domain objects in what seems fairly complicated relations. So far I have looked into GoF, dynamics with eval, and CodeDom. Does anyone have suggestion on what should be used?

Actually, you can just develop your application with WF rules engine API without using WF. http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/08/09/WF-Rules-Engine-without-Workflow.aspx This will save you from a lot of work.

Kaizen, depending on the scope and kind of your dynamic rules you could eventually use a workflow engine, like MS WF to define the rules as workflow activities for example... in this way you isolate the logic and do not need a full rebuild of the application when you need to change anything in the workflow.
This might not be the best solution but could be an alternative...

Having spent a year building a rules engine and fighting on approaches I can tell you its not easy. Especially when you focus on what your goal is. If its to get users to write the rules for the system, you really need to focus hard on that area. Whats easy for a developer is perhaps much harder for most business users. We built a rules authoring platform in Excel that was compiled into C# and run dynamically ... problem was users found the spreadsheets and flow of logic too complicated and hired ASp.NET contractors to do build the rules.
BizTalk has an engine that I believe can be used for .NEt apps
http://www.microsoft.com/biztalk/en/us/business-rule-framework.aspx
Have fun!

How often do the rules change? Building a system that let's the business build (and version) their own rules is significantly more challenging than building a system that lets a programmer update the rules dynamically.
When a similar requirement came up in a past project, the business admitted that while yes, the rules will change; they won't change so often that it has to be them making the updates.
We ended up using IronPython for the dynamic parts and storing the code in the database and the system would pull up the appropriate rules on load. The rest of the app was written in C#. A win for us and for the business.

rules engine design & examples in c#

I am currently writing a .net application with c# and want to check a number of rules and based on passing or failing the rules, perform an action. So I am looking to implement a generic solution that I can reuse adhering to good oop principles. This has lead me to the conclusion that I need to write a rules engine.
I have good knowledge of c# but this is the first time I have needed to write a rules engine so as part of my research in to the design and development of such, I am looking for any tips regarding the creation of such an engine. What would be great further would be any examples out there that I could look at? Any c#/.net rules engine applications? What layer in a typical 3 tier architecture should such reside at? I had a quick look on the codeplex and google code but none jumped out at me! So some direction would be great.

Actually .NET has a top-notch rules engine meant to be used with workflows (as it is designed to be) but can be used outside of workflows easily: You should see "Windows Workflow Foundation Rules Engine" and inspect the System.Workflow.Activities.Rules namespace.
Learning how to use rules outside of workflows takes only a bit of googling.
Edit: If you want to inspect the architecture, here is two open-source prebuilt engines:
NxBRE
.NET Application Block for Validation and Business Rules

Building and implementing your own rules engine can be a very difficult task with many things to consider. The biggest problem you will face is trying to decide which rules to fire and when. Not giving this the proper care can lead to performance problems within the implementation. I would highly recommend focusing in on the business problem and providing your subject matter experts (SME’s) with the ability to define and maintain their own rules. There are many good commercial products that do this; the one I have successfully implemented multiple times is www.inrule.com. They have a nice set of products that can help solve simple and complex problems. Hopefully this helps.

To Workflow or Not to Workflow?

I am responsible for a team of developers who will are about to start development of a light weight insurance claims system. The system involves a lot of manual tasks and business workflows and we are looking at using Windows Workflow (.NET 4.0).
An example of the business domain is as follows:
A policy holder calls the contact centre to lodge a claim. This “event” fires two sub tasks which are manually actioned in parallel and may take a lengthy time to complete;
Check customer for fraud – A manual process whereby an operator calls various credit companies to check and assess the potential of a fraudulent customer. From here the sub task can enter a number of sub-statuses (Check in progress, Failed Reference Check, Passed Reference Check, etc)
Send item to repairs centre – A manual process where the item for which the policy holder lodged the claim is sent the repairs centre to be fixed. From here the sub task can enter a number of sub-statuses (Awaiting Repair, In Progress, Repaired, Posted, etc).
The claim can only proceed once the status of each sub task has reached a predefined status (based on the business rules).
On the surface it seems that Workflow is indeed the best technology choice; however I do have a few concerns in using WF 4.0.
Skill set – Looking at the average developer skill set I do not see many developers who understand or know Workflow.
Maintainability – There seems to be little support within the community for WF 4.0 projects and this coupled with the lack of skill set raise concerns around maintainability.
Barrier to entry – I have a feeling that Windows Workflow has a steep learning curve and it’s not always that easy to pick up.
New product – As Workflow has been completely rewritten for .NET 4.0 I see the product as a first generation product and may not have the necessary stability.
Reputation – Previous versions of Workflow were not well received, considered difficult to develop with and resulted in poor business uptake.
So my question is should we use Windows Workflow (WF) 4.0 for this situation or is there an alternative technology (e.g., Simple State Machine, etc) or even a better workflow engine to use?

I have done several WF4 projects so lets see if I can add any useful info to the other answers.
From the description of your business problem it sounds like WF4 is a good match, so no problems there.
Regarding your concerns you are right. Basically WF4 is a new product and is lacking some important features and has some rough edges. There is a learning curve, you do have to do some things differently. The main point is long running and serialization, which is something the average developer is not used to and requires some thought to get right as I hear far too often that people have problems serializing an entities framework data context.
Most of the time using workflow services hosted in IIS/WAS is the best route when doing these long running type of workflows. That makes solving the versioning problem not to hard either, just have the first message return the workflow version and make that a part of each subsequent message. Next put the WCF router in between that routes the message to the correct endpoint based on the version. The basic is never to change an existing workflow, always create a new one.
So what is my advise to you?
Don't take a big gamble on a unknown, and for you unproven, piece of technology. Do a small, non critical, piece of the application using WF4. That way if it works you can expand on it but if it fails you can rip it out and replace it with more traditional .NET code. That way you get real experience with WF4 instead of having to base a decision on second hand information and you learn a new and powerful technology in the process. If possible take a course on WF4 as that will save you a lot of time in getting up to speed (shameless self plug here).
About the Simple State Machine. I have not used it but I was under the impression it was for short running, in memory, state machines. One of the main benefits of WF4 is the long running aspects.

I have come to this dilemma couple of times and I had chosen not to use Work Flow foundation. Some of considerations (similar to yours) were
Involved work flows were lot simpler (a combination of state machine and sequential actions) and doing it in WF seems to overkill for efforts involved.
Learning curve for developers to understand and to use WF effectively was considered high. Status transition table describing valid transitions and actions to be taken are used for additional flexibility and developers were comfortable with it, easily understanding the concept and purpose.
Chances of business process changes were slim and rudimentary changes were easily possible with help of transition table. A change in transition would mean a database script while change in actions would result in new release/patch. However, probability of such occurrence was deemed to be low.
Looking back after 13-14 months, I still think that decision of not using WF was correct. IMO, WF makes sense where there is strong likely hood that work flow can change and/or business rules can change. WF allows to isolate workflow in separate file and so making it configurable by users will be simpler.

We have been using WF 4.0 the last couple of months. I have to say it's challenging to think the Workflow way. However, I can tell you it's worth it. We knew very little when we started. We've bought a beginner and professional book for WF 4.0 that helped. I, myself, watched many videos online and followed PDC 2009 for their breaking news about WF 4.0 and how it's different from the previous somewhat sucky versions.
One major thing that we had to propose a solution for is the way we can deal with In/Our Arguments in a workflow without bounding our custom activities to certain data types and how to pass parameters between activities. I have come up with a good solution for that, and the workflow experience that we have so far is not bad at all. Actually, we have a workflow-intensive application that is getting bigger and bigger and I really cannot imagine myself solving it in a different environment. I love the visual effect that it has: it keeps me away from the details of if/else etc constructs and makes the business rules apparent in a way that doesn't make you forced to dive into lines of code to know what's going on or how to fix some bug.
By the way, the project that we worked on is very similar to what you described and it's a medium-sized project.
You can tell from my words that I like it and I do recommend it although is incorporates some risks as it's a new technology and you have to come up with some innovative ideas.
my 2 cents...

I did three projects in WF 3.5 and I have to say it is not easy. It force you to think in the whole new way especially when persistance is used. Updating the application which contains hundreds of incomplete persisted workflow is challenging. Single breaking change in serialization crashes them all. Introducing multiple versions of the same library to support new and old running workflows is common. It was challenging.
I haven't tryed WF 4.0 yet but based on experience from BizTalk and WF 3.5 I think it will be similar.
Anyway the best approach you can take is to do Proof-of-Concept. Take single WF from your requirments and try to implment it in WF 4.0. You will spend some time with it but you will prove if you are able to do that in WF 4.0 and if there are any visible benefits.
If you decide to use WF 4.0 I insist that you check possibility to run WF as WCF service hosted in Windows AppFabric. AppFabric provides some out of the box functionality for hosting WFs.

I think it does not really make sense today to talk about Workflow in WF4 as a technology choice for this kind of problem. What is really appropriate, as mentioned by Ladislav Mrnka above, is WCF WF Services hosted in AppFabric.
My experience with this is that it pays great dividends and is very enjoyable, but problems arise in the beginning because it is not properly appreciated that for many programmers this is a methodology shift more than a technology shift. On the other hand, generalists and those with a problem-solving mindset saw WCF WF AppFabric as a set of exciting opportunities. So if the mix of people on the project are fairly conservative C# devs attached to their daily set of OO and patterns, it will be hard to introduce. If the team is more innovative, then adoption will be much easier because the potential and new doorways multiply with each discovery.
Two main conceptual problems programmers had in moving to this technology was:
a) Message correlation and messaged exchange patterns
b) Workflows and unit testing
In standard systems in C# for example a workflow is rarely explicit and therefore rarely unit tested. The overall workflow is left for testing by acceptance scenarios or integration. Introduce an explicit WF as a software artifact and suddenly standard devs want to try and unit test it, which is usually not worth doing.
The message correlation aspect of it is a bit of mindset shift for those not familiar with message exchange patterns. Most devs have dealt with in process and remote calls, web service and SOAP, and usually focussed on one or two of those. To abstract above it all and work with a general message based system can be confusing at first.
On the positive side though, the end result is something that saves a lot of time and creates a lot of opportunities. One main thing is that the worfklow, if visually clear, is something that can be worked on by end user, developer and analyst together, eliminating unnecessary steps in the development lifecycle and focusing the parties on one artifact. Further, it discourages islands of functionality in dedicated apps, with dedicated glue layers, by encouraging a suite of business processes in WF per business domain. Further, with AppFabric, the plumbing for persistence, logging, and waking up scheduled activities is all done for you. WF4 performance is outstanding too.
My recommendation would be to find the most innovative or explorative team member do the initial scouting to discover the tricky parts, get the core functions working, and have that initial person be responsible for then compartmentalising the remaining work.

In order to do an insurance claim system of any complexity that involves roles and "sub-tasks" you really need an BPM solution, not just workflow. Workflow Foundation 4.0 is slick but it really doesn't not come close to the functionalities of a BPM product.
BPM solutions, like Metastorm BPM, Global360, and K2.NET, provide human centric workflow, tasks, roles, and system integration that can model and streamline the business processes like your insurance claim system. Use ASP.NET to build the interface that integrates with the BPM workflow engine as their built in designers are usually limited and force you to use their custom built web control which usually are not as full featured as the ASP.NET web controls.

Go with the technology your team knows and feels comfortable with. Workflow Foundation is not a product that you can use straight away - it's rather a set of pieces you can embed in your application in order to build a workflow system. IMHO the workflow logic is the least important piece of technology, first of all you have to concentrate on the GUI because business owners will not see anything but the GUI. But if your system is a success then you have to be prepared for neverending change requests and new requirements so you have to implement your business logic so that it's easy to change and easy to divide into separate processes to suit different user needs (sometimes contradicting). BPM helps in this task because it allows you to have separate, multiple versions of business processes suiting various business needs. You don't need full fledged BPM engine for that but it's useful to code your business logic so that it can be versioned and divided into individual business processes - the worst thing to have is an unmantainable and intertangled blob of code that handles 'everything' and that no one can understand. There are many ideas for that - state machines, DSLs (domain specific languages), scripts etc - you decide what the implementation should be. But you should always think in terms of business processes and organize your logic accordingly so that it reflects these processes.
And be prepared for coexistence of many variants of business logic and data structures - this is the most difficult design task imho.

I'm in a situation where I have to use 4.0 as .NET 4.5 isn't accredited for use in our prod environment yet. I had major pain understanding generally how to get long running workflows going to suit our business need but eventually found an elegant solution. It's not something which just anyone coming later to support can just pick up with ease because there's so much to think about, but I do believe in WF as a tool for managing workflow states.
One big thing I take issue with WF 4.0 though is Maurice's comment:
The basic is never to change an existing workflow, always create a new one
That's great if you just want a new version, but what if you have 50,000 persisted workflows and realise at some point that there's a bug in the workflow? You need to be able to update the xamlx and still be coupled to the existing instances. I've tried ungzipping the various metadata columns in the SQL Server instances table to find something that ties the instance to the workflow definition without any luck.
I did write a synchronisation application for importing data from an old system into our new WF 4.0 driven one. We basically load the data into the system, then run the process which goes about automatically calling into the workflow steps and calling validation methods, essentially mocking user interaction. This only really worked well with us due to the architecture we implemented for access to the workflow service host. It's great as a one off, where after running you can go through and do checks to ensure consistency of the data migration process, but having to use this approach for potentially hundreds of thousands of cases once a system is live isn't really an approach that instills confidence and over burdens the process of integration simple bug fixes.
My recommendation is that you avoid WF 4.0 altogether and just go straight to 4.5 if you're environment supports it. The Dynamic Updates and Side by Side Versioning it provides caters for bug fixing and WF versioning all out of the box. I've still yet to investigate exactly how as 4.5 still isn't accredited for use by our client, but eagerly awaiting this opportunity.
What I'm desperately hoping for is that our client doesn't request changes to policy (and therefore workflow adjustments) and that the current workflows hold up without any bugs. The latter being a vain and empty hope as bugs always pop up.
I really can't understand what was going through the WF dev team's heads to release a system where out of the box you can't fix bugs easily. They should have developed a technique for re-binding an instance to new xamlx.

Choosing CMS vs Portal vs MVC+Components?

I need some help figuring out whether it'd be a good idea to use a CMS or portal solution for my latest project, which is (currently) an ASP.NET MVC application that must serve multiple customers (being a company or some other entity with a list of users) from a single installation (that is, a SaaS solution).
In addition to the core functionality, which includes document management/publishing, I also need to provide basic social features (such as blog, forum, gallery, polls, etc.). However, it is imperative that content is only visible for the customer to which it belongs, and my evaluation of a bunch of CMS and portal solutions has shed little light on whether they support this. They're pretty focused on single-user installations, and documentation on how to integrate with an existing MVC solution is pretty thin.
Essentially I'm looking for some guidance to help me discard dead-end options (the product does not meet requirements, imposes too many restrictions, is not mature, etc.) and find unexplored options before getting too far ahead with the project.
My requirements for the architecture include:
Multi-site support (using a single domain for hosting)
Watertight separation of content between customers
Full integration across components/features
SSO (single-sign-on)
Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
Ease of development and deployment
Custom logic will be written using C# and ASP.NET MVC and any products should support this
I want to stay in control
Solution should offer features but otherwise stay out of the way (for example, not force stupid idioms on me, like insisting on GUIDs for primary keys)
Active development community
No single-man efforts
Recent source control activity
Reasonable levels of documentation and maturity
Does not have to be open source
I have spent a fair amount of time evaluating products and components, which I'll briefly share here:
Umbraco
Does not support ASP.NET MVC (yet, as someone is bound to otherwise comment)
Great community support, active development
Seems to be lots of work to get started
Kooboo
No source activity (no updates for almost two months)
GPL licensed? (need something that allows for closed source applications)
N2CMS
Partial ASP.NET MVC support
Every customer must have a separate domain
Limited source activity (not dead but not vibrant either)
Orchard
Microsoft-sponsored (which means it's likely to be over-architected, code-bloated and slow, although it does have some well known and respected contributors/leads)
Built using ASP.NET MVC
Looks promising feature-wise (but is unlikely to be stable at this stage)
AtomSite
Feels reasonably mature and has decent documentation, albeit with holes
Built using ASP.NET MVC
Limited source activity, single developer
MojoPortal
Looks good for a portal, but probably requires custom logic to be built as modules around the product (I was hoping to avoid that kind of lock-in if possible)
DotNetNuke (DNN), CommunityServer and Microsoft Office SharePoint Server (MOSS)
Definitely not my cup of tea ;)
BlogEngine.NET
Mature and feature-complete
No ASP.NET MVC support
Integration possible but not without lots of Web.config voodoo
Not sure if it supports customer separation
Given the list above I'm leaning towards AtomSite, N2CMS, Orchard or BlogEngine.NET. If I go with the latter I'll be using jitbit AspNetForum, which is a great match for my needs.
I'd probably prefer to use a custom ASP.NET MVC solution and individual components as this is likely to give me the greatest amount of control, but on the other hand, it'll make site theming and integration harder. What combinations have you tried, what worked well and what didn't? Anything important I'm leaving out of my evaluation? Any other relevant advice?
I'd appreciate it if the answers were not simply endorsements of your favorite product or way of doing things, but something that would help me choose or eliminate solution candidates given the requirements outlined above.

With the level of requirements you've specified, I'm personally going to have to lean towards the custom approach. You can hire someone to do the design (view) portion of the site for you, or you can buy a theme off the internet from site designers and customize it to your liking. (Sometimes just having somewhere to start is enough for intermediate level customization).
Multi-site support (using a single domain for hosting)
You're probably going to want to have control of your hosting environment, either a VPS (Virtual Private Server) or a dedicated box. This is still possible on shared hosting but not reccomended.
Watertight separation of content between customers
You'd probably have to spawn a unique app-pool for each customer with thier own services user for 100% seperation.
Full integration across components/features / SSO (single-sign-on) /Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
This is going to be the tricky part. This Example may have some useful insight for you in the development process, but you're going to want a unified login service and have all sites use it or link to it.
Ease of development and deployment
This is where it gets tricky. Development ease comes from your background I think. MVC is definately the right choice in this respect then, knowing a lot about the right ways of going about building a site in MVC will aid in this process. Keep up to date by reading community blogs and listening to podcasts like Hanselminutes or DotNetRocks will help keep you in touch with the newest and greatest tools/technologies for making your site get off the ground quickly and effectively.
Deployment is the tricky spot. MSDeploy still isn't quite there. But if you can you probably will want to come up with a Dev -> Staging -> Release publish structure so you can test your code in a staging (mimiced production) environment.
Custom logic will be written using C# and MVC and any products should support this
I want to stay in control
If you develop the site in ASP.NET-MVC, you'll be able to build common libraries that you can use not just in your site, but also in your custom tooling. This will greatly reduce your code duplication and helps make sure operational unity is achieved. (Everything works the same way).
Solution should offer features but otherwise stay out of the way (e.g. not force stupid idioms on me, like insisting on GUIDs for primary keys)
While you'll have control in this situation, I'd strongly reccomend GUID Primary Keys. This allows Merge Replication, which can help you easily restore backups or use failover DB servers when things go awry.
Active development community
.NET has a great community out there, (including this one) and you should get lots of support if you ask for it politely.
No single-man efforts
Not sure what you mean here, You'd be the Single-Man unless you hire help, but even 2 people can do great things given a little time. Even one-man can do great things, but the framework you're running on here is backed by a commercially funded huge team.
Recent source control activity
Doesn't really apply to .NET, but a lot of the libraries that you may use (NHibernate, MVC Contrib, AutoFac, Etc...) will have lots of activity and constantly being improved.
Reasonable levels of documentation and maturity
.NET and most of the production level libraries developed for .NET (Mentioned above) actually have a pretty good degree of documentation. There's multiple paid & non-paid sources of information for .NET alone, and most libraries (are well supported by the community and known on StackOverflow)
Does not have to be open source
Look for support libraries that are LGPL (i.e. you can use it in commercial software, but if you modify the library you have to release the new library code if you release the binary.) You're pretty safe here, your site dosen't have to be open source if you use these libraries to support your development.
Well, that's my 2cents. The project you've described is no small job, you're looking at a considerable amount of work even if you go with a pre-built solution (mainly hacking it to work the way you want). I imagine your biggest hangups would be SSO & Security for the pre-done solutions. Not to say it's impossible, just tricky and the end result may not be exactly what you're looking for.
Also, look into OpenID, it may be the best solution for linking all your sites together and most pre-built systems can easily be ported to use it.

Take another look at MojoPortal. The CMS is awesome and the main developer , Joe Audette, is very responsive. I'm have several installations of the CMS running single and multiple sites.

I would lean towards a CMS based solution. Having a tested and production ready software not only reduces the development time but also helps in continuous upgrade and reduced bug count.
If you go down this route, you may want to also consider Sitefinity. Not only does it support all the features required by you, but also is built on .NET and supports MVC development. The product is built by Telerik, the makers of UX tools.
Disclaimer: I am employed by Telerik.

I've recently come across phpFox which is a social networking/forums/community site CMS. This may be of use to you and is fairly inexpensive.

The solution for the site of our company has become EBIZ CMS: full-featured site that includes social networking, online store, features a presentation, a forum, create HTML pages and much more, including the maintenance of professional technical support, so we do not even need help for installing by a programmer, and it is only US$ 9/month!

Example of c# based rule language?

Can you provide a good example of rule definition language written in C#.
Java guys have JESS, is there anything good for C#?

This page shows some examples of open-source rules engines in C#: http://csharp-source.net/open-source/rule-engines

You can use the forward chaining inference engine that is part of Windows Workflow Foundation (.NET 3.5 and higher) The best part is that this has a free runtime licensing.
You can use the Rule Manager from Acumen Business and install the Windows Workflow Foundation adapter. Once installed, export the rules as WFRules (*.rules).
A visual studio .NET solution will be generated that shows how the rule engine can be invoked standalone (no workflow is necessary)
See also http://bizknowledge.blogspot.com/search/label/Windows%20Workflow%20Foundation

Try http://rulesengine.codeplex.com
It has a fluent-interface wrapper for creating rules.
It's lightweight and simple to use.

You could use Windows Workflow Foundation's (WF) workflow engine with C#. I'd started a small and simple project using WF as the workflow engine, it's actually quite straightforward to use. Check out the first part entry I've been developing on this here.
What is interesting about WF is that you don't have to use the whole thing if you want to - if you only want to write some custom rules against some entities or objects, you can - quite ingenious! Also, it's a lot less to take on board than BizTalk's BRE (and no licensing cost).
You need to add a reference to the following .Net assemblies, available in the .Net Framework v3.0 and onwards:
System.Workflow.Activities
System.Workflow.ComponentModel
System.Workflow.Runtime
Check out the article for more info.

There is the Microsoft Business Rules Engine: http://msdn.microsoft.com/en-us/library/aa561216.aspx. Not sure if it can only be used inside Biztalk - it does says it is a .Net Class Library.

Microsoft Business Rule Engine(BRE) is quite nice. But(and that's a big BUT) you'll need a BizTalk Server license to use it.

Take a look at Jetfire on codeplex. It supports forward chaining 'rules'.