Tom, Well I just spent two hours responding in the forum point by point to your comments on my last email, only to have the page go away when I hit Preview. So now I have written this up in a separate doc and copy and paste.d So if the tone of this is too terse, it is the result of having lost that first response. Short answer is that I believe the use cases that I have described are valid - that is real customers do use BPM products and production rules engines in the manners that I have described (including jBPM and Drools!). They are based on real-life customer engagements, both as a JBoss consultant and my past consulting experience. For a quick example however, just think of credit scoring within a lending process. Lenders have been using production rules technology to perform credit scoring for years. From a process perspective, it could be modeled as a separate node in the process graph, or as a "decision node" to approve or reject. Either will work and deliver the same result, but one process design may be more expressive to a given customer than the other. As for task assignment, think of the example I gave before and then add skill level, procedure code, availability, and three or four other constraints and you can understand why an insurance company might want to use a rules engine to determine which user (or set of users) they might want to assign the task to. As opposed to writing some complex, un-manageable SQL query. Clearly the issue with asserting a large organizational model needs to be addressed as part of the design, but that is a rules design issue. Also, to clarify, that a set of rules might be satisfied by multiple objects is not a detriment to their use; another rule can then determine which of multiple objects should be selected if the business case only requires one. In task assignment, it is legitimate to set multiple users via the setPooledActors interface, if this supports the business model. As for some of the other ideas being discussed, I don't understand the need to persist Rules or RulesBases inside the jBPM database, as long as there is a BRMS to manage these objects. I also don't agree with the need to manage rules, process definitions, and java all from within CVS either. This works for simple scenarios (like the examples I create) but would not support a production environment very well. I think a BRMS requires a separate "rule repository" to manage rules and rules bases, and process components should go to the BRMS when they need to run some rules. Users do require rules to be updateable by non-developers to a certain extent without the need to change the process definition or the code, and without having to re-deploy either the ear or the process definition. It is up to rule authors to create rules that allow some flexibility in this regard. An example of this is relaxing the number of years at the same address from three years to two in some credit scoring rules. Since the domain model is not changing (i.e., numberOfYearsAtCurrentResidence is already an attribute of the Applicant object), then this change can be made without re-compiling and re-deploying code. Clearly the BRMS needs to be able to have access to the latest Java from CVS in order to compile the rules, but that is a BRMS function. Finally, I don't understand the use case for "changing process variables causes the rules to fire", so I would be interested in discussing an business process example that required this in more detail. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964194#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...