Hi Mark, I did not want to continue our discussion on "[rules-dev] Bugs/Problems with 3.1.0M1"; because the conversation would become out of context and abuse the thread subject so creating this one. At a microscopic level it may not be still clear why I'm resistant to the idea of not having access to the WorkingMemory of a StatelessSession. So let me take it one level higher; of something that may be interest to you guys. Philosophy ========== According to a domain, it is possible to know from your data what you want from the system. Example 1: {See http://permalink.gmane.org/gmane.comp.java.drools.devel/1984 on conflict resolution options} Point 1 Example 2: {See http://permalink.gmane.org/gmane.comp.java.drools.devel/1984 on conflict resolution options} Point 2 E.g. 2 - Work-Around: ..To be honest I have achieved it 'functionally' with a work around at the rule level itself, which is: Keep a initialization variable. Once the most significant rule fires first, un-initialize the Business Object and modify (Object) {If not in Auto mode}; to prevent other rules from firing. E.g. 2 - Limitation I forsee: The problem with this is the R.E. has already spent time in creating an Agenda and then we are able to limit the engine in firing other rules is only a patch in a way. Also, not sure how well this approach will scale because I assume here that making modifications to objects while run time once agenda was created is possible. (It works in 3.X atleast and I'm greatful for it; please dont remove it!) {Similarly I have solutions and work around for 1} Back to our general discussion... So, there can be a need to have a service layer that extends the default service layer to write smart services which call allow for assumptions about a domain and reduce overhead on 'Rule Developers'. Writing DSL that looks like english is is not the main problem. Where I see people sruggling with Rule Engines is: 1. 'Black Box problem'(How to build a business rules engine - Chapter 6; While it may not be a rule engine I think I share his view 100% from my own experience) 2.Because the logic is abstracted to a higher non-engineering level and is not just propositional logic which makes it hard for engineers to initially understand, so it affects their ability to design good rules with lesser effort (the format helps bt is not your bang for the buck). ==================================================== An out of context example: In a Object/Relational mapping and persistence framework 'Ibatis', I once experienced a problem that because of a bug in the code, it was not possible to persist a CLOB onto Oracle. Now we know in JDBC we can do that, so if we could get access to the connection and then write native JDBC code we would be saved!? Right?! Guess what, it was 'private'. I'm sure he made it private with the intention of not having people abuse it, but hey its Open source and we never know when we can get a fix for it and to modify the code directly is disaster because you dont know if it will find its way in the future... well 'necessity is the mother of Invention' :o), the solution is not in context. Design ======= Comming back to the problem of 'StatelessSession'; Sure I understand why we dont want to make the WorkingMemory visible. Infact a problem I faced with previous WM in 3.X is that after assertion I'd have to retract facts. But If I want to build an intelligent service layer that at runtime wants to decide what sort of a session it requires, I must build a service over common types (polymorphism compared to writing dirty 'if' statements), I have 3 options: 1. Have StatelessSession also extend WorkingMemory --> NO WAY, this defeats the purpose of segragating the two and promotes abuse (I agree). 2. Have a public method that exposes the working memory --> NO, this again promotes abise 3. Have the 'WorkingMemory' as 'protected' in the default implementation. You may ask, why not write ones own implementation of 'StatelessSession', its an interface right?! Please see option 4. 4. Sessions come from 'RuleBase' and the 'RuleBase' (again an interface) come for 'RuleBaseFactory'. I see 'RulebaseConfiguration' but this does not solve my purpose. Theoretically, extend 'RulebaseConfiguration' and do what?! :o) And its crazy going on and on. ... So 3 seems to be reallllllllly easy and practical. But you may want to work a little from on RuleBaseFactory to allow for greater things. Please let me know if you have alternate paths or ideas. I'm very open and still learning. It's not about just re-factoring code, about writing services that can have adapters and be extended for domain specific reasons. Thanks, Arjun