3:23 a.m.
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