Interested in learning how  business rules and workflow paradigms can be meaningfully combined to model flexbible business logic as well as to technically bring the conceptual model to execution using jBoss Drools? This tutorial is split up into multiple parts. In the first part, an exemplary realistic service request process is presented. In the subsequent parts, the focus is shifted on the different Drools technical details and give you step-by-step instructions on how you have to can realize the particular flexibility mechanisms.

Have a look at the tutorial http://www.markus-doehring.de/phd/index.php?option=com_content&view=article&id=46:servicerequest1&catid=34:droolshowtocategory&Itemid=53

Drools is nightmare for lot of folks.

From my personal experience - 

Drools has been taken over and rewritten many times AND broken into many parts/names just in last 3 years.  Before you launch a project with version 3, they had version 4 without any compatibility. And when you plan to move to 4, version 5 was also making rounds of beta version, And they are all so different that you cant say you know one version so new one wont be a problem. IT IS A BIG PROBLEM. Whats the future ? one more rewrite ? This product is not stable at all. The eclipse plug in is full of holes.

A sample war file of 25MB for guvonor (or whatever its called now) gives a "Error" message without any info many a times when i compile a new rule or update it. The jFaces or whatever "face of Faces" it uses is so badly written. The whole Drools  thing sounds scary to me.    

Also the documentation  - very vague, lots of errors , havent been kept up with latest version at all. One section is versio x another is version x.1 on same page creating massive confusion. I know its a JBoss thing, you got to pay for everything called "free". But still ... 

Anyway ... i mostly use open source for almost everything but I  keep away from Drools and wont mind paying for some commercial vendor.

What do you think about using JSR 94 ?
As you know, Drools Planner has same compatibility issues?

Thanks.

What do you think about using JSR 94 ?
As you know, Drools Planner has same compatibility issues?

JSR 94 is probably dead atm :( A common denominator standard at this point is probably to light to be usefull.

Diego, what kind of compatibility issues do you refer to in Drools Planner? There are none that I know of. The Drools Planner module is officially still beta because backwards compatibility isn't garanteed yet (which will happen once it's productized), but there is a well maintained UpgradeFromPreviousVersionRecipe.txt (no complaints about it yet) and it's already used in several production environments. More info in the detailed and up to date reference manual.

Drools is nightmare for lot of folks.

From my personal experience - 

Drools has been taken over and rewritten many times AND broken into many parts/names just in last 3 years.  Before you launch a project with version 3, they had version 4 without any compatibility. And when you plan to move to 4, version 5 was also making rounds of beta version, And they are all so different that you cant say you know one version so new one wont be a problem. IT IS A BIG PROBLEM. Whats the future ? one more rewrite ? This product is not stable at all. The eclipse plug in is full of holes.

A sample war file of 25MB for guvonor (or whatever its called now) gives a "Error" message without any info many a times when i compile a new rule or update it. The jFaces or whatever "face of Faces" it uses is so badly written. The whole Drools  thing sounds scary to me.    

Also the documentation  - very vague, lots of errors , havent been kept up with latest version at all. One section is versio x another is version x.1 on same page creating massive confusion. I know its a JBoss thing, you got to pay for everything called "free". But still ... 

Anyway ... i mostly use open source for almost everything but I  keep away from Drools and wont mind paying for some commercial vendor.

Drools has huge uptake and its obvious they bring value to the community or people wouldn't keep downloading and using it.  I think you need to give us some leeway to innovate and redesign between MAJOR releases.  A major release version change 1.0->2.0->3.0, etc... from any company, probably means that you will lose some backward compatibility.  If your projects are more mature and you're stuck on a specific release, this is what support contracts are for.  We support, patch and update older versions of our software.

Drools is nightmare for lot of folks.

From my personal experience - 

Drools has been taken over and rewritten many times AND broken into many parts/names just in last 3 years.  Before you launch a project with version 3, they had version 4 without any compatibility. And when you plan to move to 4, version 5 was also making rounds of beta version, And they are all so different that you cant say you know one version so new one wont be a problem. IT IS A BIG PROBLEM. Whats the future ? one more rewrite ? This product is not stable at all. The eclipse plug in is full of holes.

A sample war file of 25MB for guvonor (or whatever its called now) gives a "Error" message without any info many a times when i compile a new rule or update it. The jFaces or whatever "face of Faces" it uses is so badly written. The whole Drools  thing sounds scary to me.    

Also the documentation  - very vague, lots of errors , havent been kept up with latest version at all. One section is versio x another is version x.1 on same page creating massive confusion. I know its a JBoss thing, you got to pay for everything called "free". But still ... 

Anyway ... i mostly use open source for almost everything but I  keep away from Drools and wont mind paying for some commercial vendor.

Drools has huge uptake and its obvious they bring value to the community or people wouldn't keep downloading and using it.  I think you need to give us some leeway to innovate and redesign between MAJOR releases.  A major release version change 1.0->2.0->3.0, etc... from any company, probably means that you will lose some backward compatibility.  If your projects are more mature and you're stuck on a specific release, this is what support contracts are for.  We support, patch and update older versions of our software.

Honestly, these kinds of issues aren't unique. I know plenty of open source projects that have gone through the same growing pains. The right thing to do though is to be up front about it and provide clear guidence to users. Even commercial products fail to do this well. .NET comes to mind as an example of compatability issues.

The entire software industry needs to work on improving this type of compatability issues. It also helps if those selling the software tone down the hype. Tons of companies and projects made life worse for themselves by over-hyping the "latest and greatest" release.

With Tapestry any major release comes with serious backwards compatibility issues. Tapestry 3 was great then came Tapetry 4. There was zero backward compatibility between these 2 versions. And then came Tapestry 5. Tapestry 5 had also zero backward compatibility with Tapestry 4. Then Mr. Ship made a promise that Tapetry 5 was the last rewrite and there would never be a Tapestry 6. But what happened then? Current release of Tapestry is 5.2. Tapestry 5.2 has zero backwards compatibilty with Tapestry 5.1 as does 5.1 with 5.0. The whole Tapestry project is big mess and shambles. That is why the Tapestry project is dying a slow and a painful death. All the serious users have scattered away like bees. It's users are reduced to high school graduates and hobbyers writing Hello world programs.

If Drools too has chosen this path, then it won't live to bury Tapestry. As it might get a lethal injection to speed up it's death.

Jan

@spencer  We really love constructive feedback, thank you.  If you have found any holes in Drools, in the eclipse plugin or anywhere else, I welcome you to open up a JIRA issue or come to talk to us developers on our irc channel and we will try to fix any problems you might have discovered asap.  Unfortunately, I couldn't find any JIRA issues you reported.

I'm not sure what you are trying to prove but Drools has been almost 100% backwards compatible with previous releases, has not been rewritten in the last 3 years (but improved significantly) and the core team hasn't changed at all and has been around for ages.  I might even agree on not being stable if you mean we're not standing still at all, yes, we're moving forward in a rapid pace.  Anyway, feel free to contact us offline to discuss any issues you might have.

@Markus Thank you for helping out and extending our documentation to show how Drools can be used in complex environments where rules and process integration is essential !  Good work !

Kris

Drools is nightmare for lot of folks.

From my personal experience - 

Drools has been taken over and rewritten many times AND broken into many parts/names just in last 3 years.  Before you launch a project with version 3, they had version 4 without any compatibility. And when you plan to move to 4, version 5 was also making rounds of beta version, And they are all so different that you cant say you know one version so new one wont be a problem. IT IS A BIG PROBLEM. Whats the future ? one more rewrite ? This product is not stable at all. The eclipse plug in is full of holes.

A sample war file of 25MB for guvonor (or whatever its called now) gives a "Error" message without any info many a times when i compile a new rule or update it. The jFaces or whatever "face of Faces" it uses is so badly written. The whole Drools  thing sounds scary to me.    

Also the documentation  - very vague, lots of errors , havent been kept up with latest version at all. One section is versio x another is version x.1 on same page creating massive confusion. I know its a JBoss thing, you got to pay for everything called "free". But still ... 

Anyway ... i mostly use open source for almost everything but I  keep away from Drools and wont mind paying for some commercial vendor.

It is true that Drools 3 was a rewrite over 2 with zero compatibility between versions. Drools 3 was released almost 5 years ago. Drools 4 was released about a year after v3 it was not a rewrite just incremental changes. There was no api incompatible changes and drl had only one minor "fix" that would cause migration problems; where v3 auto boxed but did not auto-unbox, v4 added auto-unboxing.

Drools 5 was released in 2009, 3 years after v3. There was no DRL incompatible changes from v4 to v5. There was no api incompatible changes, that we are aware of, any api compatibility changes that came up during the release cycle we fixed. v5 did introduce a new redesigned api, but we kept the old api along side so that people could use either, thus not breaking backwards compatibility or blocking migration. 

So other than adding auto-unboxing from version v3 to v4, there has been no breaking changes from version v3 to version v5.1 over almost 5 years. What the new api does is bring in clear separation from what is an end user api and what is an internal api or implementation and does more to encapsulate any internals. Previously some adventurous users could go "deep diving" and end up using some internal api stuff that would change. When ever we changed any internal stuff that we thought end users might be using we opened it up for discussion on the mailing lists. With the new api this should not happen now, if the interface is not in drools-api jar then it's considered internal.

Versions v3, v4 and v5 have always had the core jars - core, compiler, decisiontables and jsr94. That hasn't changed in 5 years, we have recently added another required dependency drools-api, as just mentioned. We have added other jars over time, as we add functionality. Instead of putting it into core and compiler and bloating those we put it into their own modules so users only include it if they need it - it's called "paying for it, only if you use it". So if you want to use Drools with Spring and Camel, you only include those jars if you need it, if you don't need it you can just stick with api, core and compiler.

Your comments on documentation have some validity but a are little unfair. We actually have a large amount of documentation which we keep adding to over time. I don't think lack of documentation compared to either other OSS projects or commercial projects is something you can accuse Drools of. I personally have put a lot of effort into the quick start tutorial that are building up. Anyone who has used commercial systems can tell you how lacking they are compared to ours, you'll find many references in the mailing lists to our “fine documentation”. The commercial systems keep documentation light to drive professional services. The documentation could do with more consistency and in places can be a bit bitty or hard to read from one section to the next and has a few holes. But luckily there are books you can purchase and read as well. We do have a little bit-rot because of the sheer volume of documentation; this is actively being discussed in the community mailing lists now and Wolfgang Laun from the community is helping us to address this, especially on the syntax rail-road diagrams.

Drools is a fast innovating project, features are added at a rapid pace and documentation grows rapidly with it. We have been a small team so far which means we haven't put the polish on the documentation as we hoped. We are now growing from a 4 man team to 7 and will increase further next year, thanks to investment from Red Hat. We are actively working on cleaning up our core code at the moment, with drools-api leaving us free to making sweeping changes, and the additional resources and engagement from the community means we can be more pro-active on the documentation.

I checked the user mailing list to see if you had engaged the community with any of your issues and don't see any posts from you over the last 6 years. Drools has an excellent community and the lists are very active, so I'd recommend that you raise your issues there so we can help improve our projects. I see you've raised this issue before on TSS, http://www.theserverside.com/discussions/thread.tss?thread_id=59886#334050, where you complain about name changes. These topics were actively discussed on the mailing lists and blogs, we don't do these things unilaterally and the community is consultant at each stage. Again I'd recommend the mailing lists for this types of discussions, moaning on TSS doesn't really help to pro-actively improve a project, compared to engaging the community in mailing lists.

Drools is nightmare for lot of folks.

From my personal experience - 

Drools has been taken over and rewritten many times AND broken into many parts/names just in last 3 years.  Before you launch a project with version 3, they had version 4 without any compatibility. And when you plan to move to 4, version 5 was also making rounds of beta version, And they are all so different that you cant say you know one version so new one wont be a problem. IT IS A BIG PROBLEM. Whats the future ? one more rewrite ? This product is not stable at all. The eclipse plug in is full of holes.

A sample war file of 25MB for guvonor (or whatever its called now) gives a "Error" message without any info many a times when i compile a new rule or update it. The jFaces or whatever "face of Faces" it uses is so badly written. The whole Drools  thing sounds scary to me.    

Also the documentation  - very vague, lots of errors , havent been kept up with latest version at all. One section is versio x another is version x.1 on same page creating massive confusion. I know its a JBoss thing, you got to pay for everything called "free". But still ... 

Anyway ... i mostly use open source for almost everything but I  keep away from Drools and wont mind paying for some commercial vendor.

It is true that Drools 3 was a rewrite over 2 with zero compatibility between versions. Drools 3 was released almost 5 years ago. Drools 4 was released about a year after v3 it was not a rewrite just incremental changes. There was no api incompatible changes and drl had only one minor "fix" that would cause migration problems; where v3 auto boxed but did not auto-unbox, v4 added auto-unboxing.

Drools 5 was released in 2009, 3 years after v3. There was no DRL incompatible changes from v4 to v5. There was no api incompatible changes, that we are aware of, any api compatibility changes that came up during the release cycle we fixed. v5 did introduce a new redesigned api, but we kept the old api along side so that people could use either, thus not breaking backwards compatibility or blocking migration. 

So other than adding auto-unboxing from version v3 to v4, there has been no breaking changes from version v3 to version v5.1 over almost 5 years. What the new api does is bring in clear separation from what is an end user api and what is an internal api or implementation and does more to encapsulate any internals. Previously some adventurous users could go "deep diving" and end up using some internal api stuff that would change. When ever we changed any internal stuff that we thought end users might be using we opened it up for discussion on the mailing lists. With the new api this should not happen now, if the interface is not in drools-api jar then it's considered internal.

Versions v3, v4 and v5 have always had the core jars - core, compiler, decisiontables and jsr94. That hasn't changed in 5 years, we have recently added another required dependency drools-api, as just mentioned. We have added other jars over time, as we add functionality. Instead of putting it into core and compiler and bloating those we put it into their own modules so users only include it if they need it - it's called "paying for it, only if you use it". So if you want to use Drools with Spring and Camel, you only include those jars if you need it, if you don't need it you can just stick with api, core and compiler.

Your comments on documentation have some validity but a are little unfair. We actually have a large amount of documentation which we keep adding to over time. I don't think lack of documentation compared to either other OSS projects or commercial projects is something you can accuse Drools of. I personally have put a lot of effort into the quick start tutorial that are building up. Anyone who has used commercial systems can tell you how lacking they are compared to ours, you'll find many references in the mailing lists to our “fine documentation”. The commercial systems keep documentation light to drive professional services. The documentation could do with more consistency and in places can be a bit bitty or hard to read from one section to the next and has a few holes. But luckily there are books you can purchase and read as well. We do have a little bit-rot because of the sheer volume of documentation; this is actively being discussed in the community mailing lists now and Wolfgang Laun from the community is helping us to address this, especially on the syntax rail-road diagrams.

Drools is a fast innovating project, features are added at a rapid pace and documentation grows rapidly with it. We have been a small team so far which means we haven't put the polish on the documentation as we hoped. We are now growing from a 4 man team to 7 and will increase further next year, thanks to investment from Red Hat. We are actively working on cleaning up our core code at the moment, with drools-api leaving us free to making sweeping changes, and the additional resources and engagement from the community means we can be more pro-active on the documentation.

I checked the user mailing list to see if you had engaged the community with any of your issues and don't see any posts from you over the last 6 years. Drools has an excellent community and the lists are very active, so I'd recommend that you raise your issues there so we can help improve our projects. I see you've raised this issue before on TSS, http://www.theserverside.com/discussions/thread.tss?thread_id=59886#334050, where you complain about name changes. These topics were actively discussed on the mailing lists and blogs, we don't do these things unilaterally and the community is consultant at each stage. Again I'd recommend the mailing lists for this types of discussions, moaning on TSS doesn't really help to pro-actively improve a project, compared to engaging the community in mailing lists.

i saw 3 new versions in about 4 years of time and that worries me, may not be a problem for others. It depends on where you work and how you use it. If you work for a insurance company which has a huge base of underwriters( policy rules makers), please dont expect them to wait for another "software upgrade project" . And even if you guys say the api didnt change much, in a company where millions of dollars are involved in insurance policy rules a one line of code change matters. And being open source project , people would tend to use some internal aPI. As you mentioned a lot of those things changed between different versions.

So you all may not have huge projects or may be agile enough to take risks, not my company. I know its the down side of open source - its free blah blah blah .... heard that before. But if open source wants to get into main stream and big corps, it needs to do a better job. Someone mentioned Tapestry example. its that true.

About documentation & the plug in - one small mistake in documentation can throw off the developers. And please be honest about the faces implementation issue.  I used to see "error" alerts atleast 5 times a day when i complied my rules. Again, it may not matter to you all, its all good now, but when you are stuck at midnight on something and lot of things are at stake,  it matters.

May be i should have opened a bug and used the the community mailing list, but i couldnt wait for "next release". And a comment on your beginner's guide, please - its bad. You see for yourself how many people in the forums ask very basic questions over n over again, because the documentation lacks basic details.  

So thats why "it worries me". I didnt say you all should not use it either. I just shared my experience. Looks like it was wrong to do so based on the feedback. Hey thank me for making this dead thread lively. what chance did it have to get a single response otherwise :)

I have been on JRules for last 1.5 years. Its been a very stable eclipse plug in, the team server / web based to eclipse synch works just fine, there arent too many "modules" inside it. Its just very simple overall. And this is from a my experience who used jboss for about 3.5 years. We ended up paying ILog ( now silly IBM acquired it :) )  , but really got peace of mind.

Please continue with your tutorial. Sorry for the interruption....

i saw 3 new versions in about 4 years of time and that worries me, may not be a problem for others. It depends on where you work and how you use it. If you work for a insurance company which has a huge base of underwriters( policy rules makers), please dont expect them to wait for another "software upgrade project" . And even if you guys say the api didnt change much, in a company where millions of dollars are involved in insurance policy rules a one line of code change matters. And being open source project , people would tend to use some internal aPI. As you mentioned a lot of those things changed between different versions.

That's why we have .org and .com releases. .org is bleading edge, release early release often. The .com releases are for organisations that need stability and can't upgrade every version. .com has a commitment for support for 5 years with backporting of bug fixes, so you can get bug fixes without new features. .com goes through additional QA, testing and hardening. That's the JBoss business model and the value add for .com customers.

i saw 3 new versions in about 4 years of time and that worries me, may not be a problem for others. It depends on where you work and how you use it. If you work for a insurance company which has a huge base of underwriters( policy rules makers), please dont expect them to wait for another "software upgrade project" . And even if you guys say the api didnt change much, in a company where millions of dollars are involved in insurance policy rules a one line of code change matters. And being open source project , people would tend to use some internal aPI. As you mentioned a lot of those things changed between different versions.

That's why we have .org and .com releases. .org is bleading edge, release early release often. The .com releases are for organisations that need stability and can't upgrade every version. .com has a commitment for support for 5 years with backporting of bug fixes, so you can get bug fixes without new features. .com goes through additional QA, testing and hardening. That's the JBoss business model and the value add for .com customers.

 

If I have to buy a paid version of rules engine , i will go with JRules today - because of ease of use, stable software plug in, thoughtfulness of business users and developers etc. And we did extensive evaluation of rules engines that time - yes including other open source rules software.

I would not go with drools.com for sure. You guys have years to catch up.  

again - my humble opinion.. ( BTW - forrester and gartners also say the same).... 

for what it's worth, you're not alone. I know several companies that chose JRules over other products because their developer tools are better. Compared to blaze, quickrules and various bpm offerings, JRules is more complete in my bias opinion. That's not to say it does everything out of the box, no product does that today.

Drools can do anything (well almost). It is extremely powerful and has a lot of uses. The real trouble is people not understanding just what its capable of (or even being able to handle its declaration style) and backing away in fear of the different.

We use it for business, UI visibility and data rule validation, message routing and object factories. I'd like to add in Complex Event Processing and workflow (if statefull) but those are more fearful things...

Drools can do anything (well almost). It is extremely powerful and has a lot of uses. The real trouble is people not understanding just what its capable of (or even being able to handle its declaration style) and backing away in fear of the different.

We use it for business, UI visibility and data rule validation, message routing and object factories. I'd like to add in Complex Event Processing and workflow (if statefull) but those are more fearful things...

I couldn't resist responding. Based on what you say, I get the feeling you associate production rule engine with declaration style. That is a common misunderstanding amoung many new users of production rule engines. First and foremost, using a production rule engine like JESS, JRules and Blaze is about logic programming. It isn't "declaration style" at all. It's a completely different way of thinking and building logic.

I've seen many people who claim to be "rule consultant" that didn't get that basic principle. One can write declarative rules using graphical notation like state diagrams or with a text based language, but that doesn't necessarily mean it is "logic programming." I've also seen a lot of people say they "use declarative rules", but they were really writing procedural code with a rule language. On the contrary, drools can't do "anything" unless you plan on using it as a sledge hammer. Don't abuse rule engines for the sake of "appearing" cool.

If you're going to use a production rule engine, use it properly. The only way to do that is to spend 5-10 years studying the domain and reading everything you can get your hands on.

I'd mostly agree on this. But this isn't a technical issue, rather a conceptual one. I also aim a tackling some of those issues, especially for rules employed within business processes: www.markus-doehring.de/phd. You'll also find some already existing references for high-level advice on, e.g, when to use rule- and when to use flow-paradigms.

Besides your technical issues, I'm also very interested in feedback on those conceptual questions.

I'd mostly agree on this. But this isn't a technical issue, rather a conceptual one. I also aim a tackling some of those issues, especially for rules employed within business processes: www.markus-doehring.de/phd. You'll also find some already existing references for high-level advice on, e.g, when to use rule- and when to use flow-paradigms.

Besides your technical issues, I'm also very interested in feedback on those conceptual questions.

Interesting Phd thesis subject. One minor correction on that page, RuleML actually predates BPMN. Said Tabet of RuleML has contributed to BPMN discussions. The goal of BPMN is much more narrow than RuleML, so a meaningful comparison can't be made. I've been working with RuleML founders for many years now, so I'm bias.

To the best of my knowledge, there's a lot of prior art in workflow, production rules and event processing, but not much on the semantic intersection of these three. The guys at ART did a lot of stuff that was EDA focused, even though it wasn't called event processing back in the 90's. They also did a lot of workflow stuff before it was called BPM. If you want to dive deeper, feel free to email me directly woolfel AT gmail DOT com.

I didn't intend to say that RuleML has been existing for a longer time than BPMN, but BPMN (to my mind) is more considered by industrial BPM solution providers ... which is exactly, as you said, due to its narrower focus, with rules being much more difficult being unified under a common language.

I'm definitely also interested in an exchange on those prior work, I'll drop you a separate mail on this.

declarative meaning the way a rule is actually written in my context.

I'm just saying that:

when

...stuff

then

...more stuff or insert(blah) causes all extra 'things' to happen is harder for some to grasp than traditional java:

if (stuff)

{

... more stuff

}

its hella neater and much more conceptual (for me to visualise kind of like a pinball machine layout of rules and consequences) than typical if statements especially when there are many (and shared) dependencies that need to stack up for another rule to fire.

drools is cool because of what it can do and how (and its free).

declarative meaning the way a rule is actually written in my context.

I'm just saying that:

when

...stuff

then

...more stuff or insert(blah) causes all extra 'things' to happen is harder for some to grasp than traditional java:

if (stuff)

{

... more stuff

}

its hella neater and much more conceptual (for me to visualise kind of like a pinball machine layout of rules and consequences) than typical if statements especially when there are many (and shared) dependencies that need to stack up for another rule to fire.

drools is cool because of what it can do and how (and its free).

My previous explanation was clearly crappy, so i'll try to explain it better. Whether the syntax is when/then or if() {} has nothing to do with logic programming. I agree some people consider a declarative syntax cleaner, but I've met plenty of developers who would disagree. I've seen plenty of heated debates with real developers who thought "so what if the syntax is declarative!" For the record, I prefer LISP style syntax for rules.

By logic programming, I mean the work is divided into small logical statements or units of work, which utilizes forward chaining and inferencing effectively. Note that forward chaining is different than inferencing. Forward chaining is simply one rule triggering another rule. One can forward chain rules without ever using inferencing. Inferencing generally means reasoning over a situation where data is incomplete or may not be available. An example of inferencing might be location tracking.

At T1 jack is pulling out of his driveway and driving to time square New York. If an application wants to "infer" where he is, the system can look at his most recent long/lat/vector. The system can give a rough estimate of where jack is. If the last data point was 5 minutes old, the estimate may be 1-5miles off. If the data point was 2 seconds old, the estimate is better. At the nuts & bolts level, it means the rules assert new facts, modify existing facts and handles situations where data is missing. In the tracking example, Jack could loose his cell signal or the GPS data is off.

Many people confuse rule chainging with inferencing. More important than what the rule looks like is how the rules in a ruleset works with the data. Many people hard code values in the rules, which is fine when done correctly. Inference applications tend to avoid hard coded value and uses data driven rules techniques. This mean the rules focus on defining the join structure between the objects. In other words, the patterns we are interested in.

These things aren't easy to learn and it takes a long time. Luckily, there's several great books on the topic like Jess In Action, expert systems and programming and several others. Then there's hundreds of academic papers on the topic of expert systems and machine learning that cover these challenges in detail. I would encourage you to think beyond the syntax and really dive deep into the domain. Regard of the rule engine you use, there's a lot more than just syntax.

jboss simply rocks!

stork club movie

flexibility is such an important thing

buffalo freelance website designer