What do you mean, you want a Business Rules and Workflow Application Block?
Thanks to everybody who has already responded to the Enterprise Library v3 Feature Prioritization Survey. There have been 200 responses in just the first day! We'll wait a bit longer to give even more people a chance to respond before we analyze the results in detail, but we are already starting to get a great picture of what you would like to see in the next release.
From a quick look through the responses we've received so far, one thing which took me a bit by surprise was the number of votes for new application blocks to be added to the library. We're definitely open to doing this, but before we can thnk about what's involved we need to get a better picture of what scenarios you need to support and what functionality you need.
In particular, there seems to be a huge demand for a Business Rules Application Block and a Workflow Application Block. For all of you who voted for these (you know who you are!) we have a few more questions for you. Feel free to respond as comments on the blog, or if you'd prefer you can e-mail me.
If you'd like to see a Business Rules Application Block: How would this application block relate to BizTalk Server's Rules Engine? Does it address the same or a different scenario? Would it be completely distinct from the BizTalk Rules Engine, or would it provide additional functionality that layers on top of it? What are the key features you would like to see in such a block? How would you imagine this block would integrate with other Enterprise Library application blocks?
If you'd like to see a Workflow Application Block: How would this application block relate to Windows Workflow Foundation (or WF for short - if you call it something else they will set their pandas on you)? Would it leverage WF or be competely distinct? Are the important workflow scenarios that WF doesn't address that you would like to see in the block? How much have you looked at WF? How would you imagine this block would integrate with other Enterprise Library application blocks?
We're really interested in finding out more about what you're looking for around these scenarios. We can't promise to deliver anything at this stage, but we will promise to listen!
Comments
- Anonymous
August 30, 2006
The rules engine in Biztalk is ok, but the rule editor is lacking in several areas (search feature, inability to determine dependencies between rules, decision tables, etc), which makes products like Ruleburst and InRule so attractive. I know I can use it outside of Biztalk, but Microsoft is still going to charge a Biztalk license even if I'm only calling the rules engine (they've told me so).
It's great that WWF is coming along, but it is mind boggling to me that there isn't a "Business Rules Foundation" in the works. As an enterprise developer, rules and workflow are the two most important things for me. I want a rules framework that doesn't require that I have a biztalk CD. WWF won't be as useful to me without a corresponding rules framework. - Anonymous
August 30, 2006
biztalk rules are still "so" oriented to developers. I like the idea of having these blocks - but would prefer to see them more oriented to building "plugs" so that rules and workflows can be changed outside of the application (aka - true enterprise class level abilities). - Anonymous
August 30, 2006
The comment has been removed - Anonymous
August 30, 2006
The Business Rules Block must be independant of BizTalk server. I tend to build programs for small clients where BisTalk server isn't even an option. There should be a way to build a rules engine for a program that can be maintained by the end administrator of the program. Some rules may be changed by an end administrator, some cannot. It must be capable of being externalised so that the same, simple, rules engine can be shared among more than one program.
It must be simple! - Anonymous
August 30, 2006
Workflow Application Block should be simple and should not require WCF! - Anonymous
August 31, 2006
I second (or third) the comments above on both blocks:
Having a business rules engine that doesn't depend on BizTalk opens it up to a much wider range of developers and projects. It would be very useful to have a rules engine in web apps without requiring BizTalk.
On WF, I can see the usefulness of a wrapper that implements best practices in the same way the Data block does. I haven't used WF enough yet to know whether it already has what Brad Abrams calls the "pit of success". My guess is that, like System.Data, you can do things a million different ways, many of them not so good. In that case, a workflow block that "standardizes" the best practices like the Data block would be nice. - Anonymous
August 31, 2006
BizTalk should not be required, both because it is "so" heavyweight and because it really isn't necessary. WF has a rules engine in it. The problem with the WF rules engine is that attempting to use it outside of a workflow is cumbersome (exactly why a new block would be helpful). - Anonymous
August 31, 2006
I disagree on some of this . . . this is the "ENTERPRISE LIBRARY", so the focus should be on writing functionality that is not already available - like Key Management for server farms - for the ENTERPRISE. - Anonymous
August 31, 2006
Also, what about configuration that comes from multiple sources? In an Enterprise environment, I may have several different databases and I may want logging configurations to be different for each database - in this case, you may want to store the logging configuration in each database, while having a default or standard as part of a system database. Enterprise applications do not follow the multi-tenancy db scenario. - Anonymous
August 31, 2006
I have been searching for a freeware rules engine for the past few months, and the few that I've found are ports form java implementations (drools,nxbre) with limited functionality and /or lacking a GUI tool.
To me, a rules engine in an enterprise level application is essential. And BizTalk is not always an option due to licensing. The WCF rules are not robust enough.
If a rules engine is added, please support not only field-wide and entity-wide rules, but multiple-entity rules. (Common Ex: The gold customer upgrade, depending on order items ordered).
Also an interesting thought would be allowing the rules to be hosted within SQL Server 2005 (because of CLR support). This way data intensive rules can be executed faster without network activity. - Anonymous
August 31, 2006
Personally, I think the workflow support in WCF is acceptible. I feel it would be redundant to replicate the functionality when .NET 3.0 is slated in a few months. Perhaps some recipes and guidance on the usage, maybe integration with the Enterprise Library Config GUI would be enough. - Anonymous
August 31, 2006
I thougth of Business Rule Application Block in same way as Data Access: multiple destinations, one interface. That is, at work we have available Fair Isacc's Blaze Advisor and in one project was used NxBRE. Isn't almost the same as with RDBM's? Write the Business Rule Application Block based on BizTalk's Rule Engine and provide the infrastructure and examples so is possible to "attach" some other Rule Engine. - Anonymous
August 31, 2006
Workflow application block should have the best practices for workflow foundation(WF) for creating and hosting the WF runtime which is easy to use and learn. Enterprise Library Way.
Probably few scenarios like ASP.NET page flow , similar thing in CAB, and few examples using state machine workflow etc would be nice. - Anonymous
August 31, 2006
Most enterprise customers I talk to need a rules engine, but don't necessarily want to buy a BizTalk license just to get its rules engine. The BTS rules engine is actually pretty nice in its own right, but apart from only shipping with BTS, it also suffers from the limitation that rules can only be defined in a database (and so you need SQL Server to access the rules).
An Enterprise Libarary rules engine should, IMO, be the same basic forward chaining rules engine used in BTS, but with a provider-based store model, and the possibility to invoke the engine from any managed app.
An API for editing rules would also be preferrable. - Anonymous
September 01, 2006
Most everyone on here responded and said give us a Rules Block that was seperate from Biztalk and most agree that a Workflow block should just wrap WF just as the Datablock does. This all makes sense.
Here's some "why" reasons though. Most of us that use and preach EntLib have become comfortable with the console to configure our apps so the attractiveness of doing a Rules block is something we can foresee using in the future. We could open the console configuration tool and re-configure our Web.Config file in our services layer and change the business rule on the fly and away we go.
Then, by having a Workflow block, we could configure the workflow to use the business rules and vice versa (same way as the logging block uses the data block today). - Anonymous
September 02, 2006
I'd look at the rules capability in Windows Workflow (the Policy activity) before writing a rules block. (http://odetocode.com/Articles/458.aspx) - Anonymous
September 02, 2006
I'd layer both on top of WF.
For Workflow, I think a very common scenario would be to have an 'Inbox' of pending tasks for a user. Perhaps you could work in that scenario.
For rules, perhaps focusing in a better authoring experience for web apps could be worth.
I don't think it's worth to create a pluggable Business Rule implementation.. - Anonymous
September 08, 2006
In my point of view a future Business Rules Application Block should be a free and open source alternative to the really best .NET rules engine from ILOG. - Anonymous
September 20, 2006
Consider that Business Rules in Web App are parented by Vignette - Anonymous
September 21, 2006
NxBRE, Drools.NET seems to be a good starting point
By the way, about the xml integration ab, it would be very interesting to consider an xquery, xslt, xproc? approach.
the long-time promised xquery has grown up recently (last 12 monthes). it is present (as as subset) on sql server, time has come to give it a larger place IMO
the ado xml group (blogs.msdn.com/xmlteam) knows certainly a lot about it
the www 2006 event also has a good talk about it
Olivier