[rules-dev] Designing Service Layer issues

[Arjun Dhar]

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).

>From a Code Perspective; Design - To Err is human
====================================================
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