Bob, (James your response it below Bobs)
Thanks for the quick response. I am working on a number of projects
that could benifit greatly from a rule engine. I am working on a CRM for a
fortune 100 company that it is a requirement for to handle workflow. I am
also working on a Shipping system in which we are currently utilizing a
third party rating engine. In our upcoming version, which we are moving to
the .NET platform, we will be totally writing the third party component out
of the equation due to it's brittleness, inflexability, and maintance
headaches. I figured if we could base a rating engine on a Rule Engine, it
would make life much easier for us in terms of maintenance. It would also
allow us to bring new carrier definitions and rules online without having to
redistribute executable files. I am getting ready to start another project
for a chemical manufacturer in which one requirement is a chemical
interaction tracking mechanism. A rule engine would allow us to define
chemical interaction rules that could be built upon over time, while still
allowing us to get V1 out the door with an incomplete rule set. As more
interaction rules are identified it would be an easy matter to add new
rules, or one would hope so. This would allow the chemist to define rules
about the interaction, something that they know much more about than I do.
To do this in another manner seems like it would be a huge pain.
From what I was able to glean so far, DROOL's does not support weighting
rules. I know I am trying to mix two domains here, fuzzy and rule engines,
but I can see some very valuable qualities from a hybrid. But I know that
we must walk before we run. So I am quite content to work on a project
building a linear rule engine with the eye to improvements down the road.
As to the questions you posed, my thoughts are inline.
> drools is still trying to find its way, at this point.
>
> It started as an independant project, but now it's looking like
> (hopefully) my Day Job will buy into it also.
That sounds like very good news. Then you can work on it full time. If
you accept my help I would probably be able to put in 20-25 hrs a week.
> While the current code-base is 'from scratch', I may actually
> start over again, and base it upon the JEOPS rule engine.
> (http://sf.net/projects/jeops/).
> JEOPS seems to have stalled, and requires you to compile
> your rules into .java files, which you then compile into
> .class files. Which is a pain.
I realize that utilizing a pre-existing code base can get your to your
goals in a shorter period of time if your goals match what the code base is
trying to accomplish. What I mean by that is, is this. Generating rules as
code is one way to approach a rule engine, but requires a coder to do the
generation of the rules. Another method is by building a rule engine that
is based upon a pseudo-human readable language, and imho a XML based rule
definition file would be the way to go. Along the lines of RulesML (Rules
mark up language). This would allow for a UI layer that could output the
XML files so that a business analyst to generate the rules. This would
allow the code to spend there time doing what they do best, coding, and the
BA to what they do best, identifying and defining business rules with a tool
that would map that knowledge to a rule language.
> So, I may be looking to take JEOPS and...
>
> a) Make it compatible with JDK 1.4
> (rename 'assert()' method so as not to
> comflict with the new 'assert' keyword.
> Change usage of Vector ot ArrayList, etc)
>
> b) Make the rules themselves interpreted,
> instead of compile.
This goes back to what I discussed earlier on the approach. I see some
difficulties in you take the approach that the JEOPS engine takes, producing
java files and interpreting them, but this is still a surmountable problem.
C# has many of the same abilities as Java with a CodeDOM package that is,
from what all of my associates who work in Java tell me, quite a bit more
robust in scenerios such as this. It has packages that allow you to
dynamically emit IL code.
> c) Add time-knowledge components, so that
> you can perform time-based rules (ie,
> trouble-ticket escalation after X minutes).
Yes I agree. This is a capability found in some of the higher-end rule
engines and would be a very valuable capability.
> I have no clue about .Net really, but I have a feeling
> that the changes in (b) would make life difficult.
See b above. Also if you generalize the interpratation engine, you
could make it so that you could plug in different interpreters.
> Though, you may be able to 'port' it to the new
> .Net Visual J#, or something.
We all know where J++ got MS, no thanks. I don't want to walk that road
again.
> On Sat, 13 Oct 2001, James Strachan wrote:
>
> > Hi John
> >
> > Actually its Bob's project not mine, though I'm interested in drools and
am
> > tracking it closely.
> >
> > Just a thought; why not develop all the code as Java then just have a
> > bytecode / java transformer to turn it into C#? It seems to me that C#
is a
> > Java clone so why not just put some effort into a Java -> C# compiler
> > instead? That'd be much more useful to C# folks and would avoid dual
coding
> > on many projects.
> >
> > James
James,
you point out some very valid points. I know there is currently a project
,by MS and I forget it's name, that will allow a translation from Java ->
C#. But I have my doubts as to the effectiveness of it. I need to get my
hands on it and run it through it's paces. As long as we don't bring J2EE
or EJB's into the picture it looks like a very straight forward port.
By the way my contact info during the day at work is:
John P. Sheppard
divine, Inc.
[EMAIL PROTECTED]
(314) 655-7409
_______________________________________________
drools-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/drools-interest
