Discussions

News: Drools 5 Released

  1. Drools 5 Released (34 messages)

    The Drools team are pleased to announce the release of Drools 5.0 Final. Everyone's favourite Java Rule Engine with the delivery of version 5.0 gives genesis to the Business Logic integration Platform, which provides a unified and integrated platform for Rules, Workflow and Event Processing. It's been designed from the ground up so that each aspect is a first class citizen, with no compromises. Drools 5.0 is now split into 4 modules, the links below provide more information and screenshots for each module: Drools Guvnor Drools Expert Drools Fusion Drools Flow. Guvnor is our web based governance system, traditionally referred to in the rules world as a BRMS. We decided to move away from the term BRMS to something based on governance, as our long term emphasis is no longer rules specific. Expert is the traditional rules engine. Fusion is the event processing side, it's a play on data/sensor fusion terminology. Finally there is Flow which is our workflow module. The Drools 5.0 Release Notes http://downloads.jboss.com/drools/docs/5.0.1.26597.FINAL/drools-introduction/html/ch02.html#d0e29 Home Page http://www.jboss.org/drools Blog http://blog.athico.com/ Drools Boot Camp - San Francisco 1-7 of June http://blog.athico.com/2009/03/drools-boot-camp-san-francisco-june.html

    Threaded Messages (34)

  2. Re: Drools 5 Released[ Go to top ]

    I would like to point out for those new to rule engines and production systems, drools 5 is not an expert system. The use of the term "expert" is a bastardization. A developer can build an expert system by providing an object model, data and rules. An expert system shell is a rule engine or production system which provides functionality that makes it easy to create an expert system. A great example of an expert system shell is JESS and CLIPS. Calling a rule engine "expert" is misleading. I notice the documentation provides no explanation on expert systems. Also, I notice the documentation does not give Gary Riley credit for assisting with asymmetric retract. Technically speaking there's no such thing as Asymmetrical RETE algorithm. It's just asymmetric retract, which has existed since early 90's for those not familiar with RETE algorithm. 2.1.3.1. Asymmetrical Rete algorithm implementation Shadow proxies are no longer needed. Shadow proxies protected the engine from information change on facts, which if occurred outside of the engine's control it could not be modified or retracted Congrats on getting the new release out. peter
  3. Re: Drools 5 Released[ Go to top ]

    I see Mr Happy came out from under his bridge. For anyone that doesn't know, Mr Lin is classic "poisonous person" and use to be part of the Drools community: How Open Source Projects Survive Poisonous People" I've debated these points and others many times before and explained why he's wrong.
    I would like to point out for those new to rule engines and production systems, drools 5 is not an expert system. The use of the term "expert" is a bastardization. A developer can build an expert system by providing an object model, data and rules. An expert system shell is a rule engine or production system which provides functionality that makes it easy to create an expert system. A great example of an expert system shell is JESS and CLIPS.

    Calling a rule engine "expert" is misleading. I notice the documentation provides no explanation on expert systems.
    Drools is an Expert System, we don't claim it's an Expert System Shell. Although it can be used in a shell like manner if you use MVEL, and we have written an experimental Clips shell front end for Jess and Clips compatibility. I checked with Gary Riley, who wrote the "bible" on Expert Systems. He says there is no single absolute definition of an Expert System, and that Drools while not having a native Shell or dependency management has the important features of dynamic knowledge definitions for rules, type models and facts and goes way beyond in other areas of functionality, such as temporal reasoning and process modelling. As such he absolutely agrees that Drools is an Expert System, so hey if you want to claim you are more of an authority than Gary, then please do let me know when your book is out and I'm sure Gary would appreciate your corrections for his next book revision.
    Also, I notice the documentation does not give Gary Riley credit for assisting with asymmetric retract.
    The user manual is not an academic paper, we use ideas and concepts from dozens of authors and we don't credit them all in the user manual. However we do give reference in our blogs and talks where and when appropriate, in no way have we tried to plagiarise other's ideas as our own. You've made this claim before, also you went around saying I didn't create Drools. I have discussed with Gary in the past that he is comfortable that we have not plagiarised his ideas s our own, and well you've had your own smack down from Bob McWhirter (The Drools co-creator) on the other lies.
    Technically speaking there's no such thing as Asymmetrical RETE algorithm. It's just asymmetric retract, which has existed since early 90's for those not familiar with RETE algorithm.

    2.1.3.1.Asymmetrical Rete algorithm implementation
    It absolutely is an algorithm and defines an important enhancement over the original 1979 algorithm, while it's been in Clips from the start Gary has continued to refine and improve it even in recent years. Gary himself now does talks on "Asymmetrical Rete", and he'll be discussing his algorithm in Texas. The only difference is he use to just call it "Clips Rete Enhancements" until I helped coin terminology for this enhancement to help define it's approach compared to classic Rete, which he now uses.
    Shadow proxies are no longer needed. Shadow proxies protected the engine from information change on facts, which if occurred outside of the engine's control it could not be modified or retracted
    As I've explained to you before Asymmetrical Rete removes the need for Shadow Proxies while still protecting the engine from outside changes. It protects the engine from the brittleness of being able to modify or retract facts if their underlying pojos change outside of the engine. This is because the facts can always be retracted, no matter what the changes, making it far more robust. Shadow Proxies force a duplication of data as they shallow "clone" the original pojos, thus taking up more memory, also they can only shadow direct fields, so if people use a nested accessor - or even just a value in a fields hashmap - the system becomes very brittle and they risk memory leaks. For an explanation Rete creates a graph of memories that remembers facts. Those memories are populated on the assertion action. When you modify or retract those memories must be updated, classic Rete requires a re-determination of the path the assertion took, which involves re-evaluation for all expressions of the rules, so that the modify or retract action can update the correct memories. The original values are thus needed for this process. Asymmetrical Rete allows those memories to be updated, without having to re-determine the path and thus we don't need to keep the old duplicated data around, nor is it's integrity lost by nested accessor changes. Symmetrical Rete means the assertion and retraction does the same work both sides, as rules are evaluated both times. Where as Asymmetrical Rete is different for the retraction, the assertion keeps more references around allowing the retraction to work just by following those references. Mark Drools Project Lead Drools Blog
  4. Re: Drools 5 Released[ Go to top ]

    Glad to see you're still ignoring prior art and making claims you "invent" stuff when there's clearly prior art. The term asymmetric retract has been coined in atleast 2 papers related to RETE-UL. People can check for themselves, the first paper to use that term as far as I know of is Doorenbos RETE-UL paper. The second one was a follow up on Doorenbos RETE-UL. And CLIPS has used that approach for many years as you stated, which Gary Riley confirmed. I don't buy the excuse that "a business doesn't need to give credit". I'm a firm believer in giving credit where it is due and called out other vendors in the past. I've consistently been a stickler when companies ignore ethics in favor of hype. Like when microsoft Biztalk product manager claimed they invented a new faster algorithm and I challenged him. Or when ruleburst claimed RETE was slow because they used an old prolog engine. I also challenged hyper RETE as a marketing term. Let's be honest, it's a marketing term and not a "new algo". I'm sure Dr. forgy was using asymmetric retract since 2000 in OPSJ. Go ahead and claim you invented something. I feel it's wrong. Clearly many people disagree with me, but that's how I feel. Thanks for attacking me, it's nice to know you can yell really loud. I have a pretty thick skin, so it's all good. I don't mind heated debates or stubbing some toes in the interest of identifying hype from reality. peter
  5. A rule engine or production system is like a V8 engine. By itself it's just an engine. It doesn't have wheels, transmission, seats, belts, suspension or a driver. Once you attach the engine to a frame, transmission, wheels, suspension, etc, it becomes a car. In the same way, a rule engine like jess, clips, jrules, blaze, drools, etc is an engine. After you've created the object model, creates the data, written the rules, started an instance, and loaded everything, you have an expert system. I have my definition and you have yours. I happy to accept your definition is different and incompatible with mine, but there's hardly a need to yell. peter
  6. A rule engine or production system is like a V8 engine. By itself it's just an engine. It doesn't have wheels, transmission, seats, belts, suspension or a driver. Once you attach the engine to a frame, transmission, wheels, suspension, etc, it becomes a car.

    In the same way, a rule engine like jess, clips, jrules, blaze, drools, etc is an engine. After you've created the object model, creates the data, written the rules, started an instance, and loaded everything, you have an expert system.

    I have my definition and you have yours. I happy to accept your definition is different and incompatible with mine, but there's hardly a need to yell.

    peter
    I don't know dude, you seem pretty intent on knitpicking terms to the point of sowing some FUD. I think you've been accurately called out as a "poison person".
  7. A rule engine or production system is like a V8 engine. By itself it's just an engine. It doesn't have wheels, transmission, seats, belts, suspension or a driver. Once you attach the engine to a frame, transmission, wheels, suspension, etc, it becomes a car.

    In the same way, a rule engine like jess, clips, jrules, blaze, drools, etc is an engine. After you've created the object model, creates the data, written the rules, started an instance, and loaded everything, you have an expert system.

    I have my definition and you have yours. I happy to accept your definition is different and incompatible with mine, but there's hardly a need to yell.

    peter


    I don't know dude, you seem pretty intent on knitpicking terms to the point of sowing some FUD. I think you've been accurately called out as a "poison person".
    I agree I am nitpicking on the term "expert." I never claimed I wasn't nitpicking. In fact, it's pretty clear I am nitpicking. On the citation issue, not giving credit is an offense most companies are guilty of, so JBoss is no worse than other offenders. Plenty of open source projects are guilty of it. I just feel the community needs to hold companies and projects to higher standards. Going by Mark's definition, hammurapi rules, open tablet and any other rule engine out there qualifies as an expert system. Do we risk degrading "expert" to nonsense if it's defined so that anything could be an expert system? If that's what people want, so be it. I definitely don't prescribe to that opinion. I realize I've been called out as poison person. Honestly, I've definitely been guilty of it in the past on various open source projects. I'm no saint and never claimed to be one. On more than one occasion, I've flamed projects and/or users. I've also never claimed to be an expert or authority of any type, so my opinion is just an opinion. In my own defense, I've worked diligently to push the state of art in rule technology. I've written detailed articles summarizing the lessons I've learned and shared it openly with rule vendors. If you want to read them, you can find the articles here. http://jamocha.svn.sourceforge.net/viewvc/jamocha/morendo/doc/Temporal_Logic_Extension_for_RETE_Algorithm.doc?revision=2061 http://jamocha.svn.sourceforge.net/viewvc/jamocha/morendo/doc/dynamic_typing.pdf?revision=2486 I fully admit I could be wrong, since I've only been studying this domain since 2000. I still have a long way to go before I have a solid understanding of rule engine technology. I welcome dissenting opinions and debate, for the simple reason that it forces me out of my comfort zone and pushes me to re-evaluate my thinking. I understand many people don't like that, which is fine. peter
  8. I have been working with latest Drools 5.0 CR releases, and Guvnor. Guvnor seems like a excellent BRMS, we wanted to add a web service for guvnor for executing the rules remotely. we found that the REST Api is available as part of guvnor doesn't seem to have execute capabilities and Drools Server (another module) had this capability with REST APIs, why not merge Drools Server and Guvnor to provide both or else their needs to be a provision for configuring drools server to work with guvnor hand in hand. One more thing we noticed about guvnor is that it stores the asset (uploaded business objects (jar files) as BLOBs) which kind of restricts developers from writing their own execution engine for doing the above mentioned task. Comments on these will be really helpful. Thanks, Siva Prasanna
  9. I have been working with latest Drools 5.0 CR releases, and Guvnor. Guvnor seems like a excellent BRMS, we wanted to add a web service for guvnor for executing the rules remotely. we found that the REST Api is available as part of guvnor doesn't seem to have execute capabilities and Drools Server (another module) had this capability with REST APIs, why not merge Drools Server and Guvnor to provide both or else their needs to be a provision for configuring drools server to work with guvnor hand in hand.

    One more thing we noticed about guvnor is that it stores the asset (uploaded business objects (jar files) as BLOBs) which kind of restricts developers from writing their own execution engine for doing the above mentioned task.

    Comments on these will be really helpful.

    Thanks,

    Siva Prasanna
    Siva, this is something I have been talking and working with the DROOLs team for a bit. I will be working with Michael Neale to make sure guvnor has hooks to modify rules outside of guvnor through simple database changes. I was disappointed when I first saw Guvnor was implemented with a content repository, but I now understand, after much discussion with these guys why they did it and how the versioning and flexibility is nice. My hope is in the next month or two Guvnor will have the option of "extended hooks" into a database to allow exactly what you described. I can tell you it has been in the plans for a while. Feel free to come to the San Francisco in June to help knock it out :) http://blog.athico.com/2009/03/drools-boot-camp-san-francisco-june.html -Michael
  10. Here are some links for those who care to do some research read up on the topic. http://en.wikipedia.org/wiki/Expert_system http://www.pcai.com/web/ai_info/expert_systems.html http://www.aaai.org/aitopics/pmwiki/pmwiki.php/AITopics/ExpertSystems http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci212087,00.html http://www.wtec.org/loyola/kb/c1_s1.htm http://www.austinlinks.com/Fuzzy/expert-systems.html http://www.webopedia.com/TERM/E/expert_system.html The definition of expert system does vary, but if you look at all the definitions above returned by google, it does have a consistent set of attributes. peter
  11. the talk was interesting. thanks for posting the link. peter
  12. Hi, What would be a rule engine with a language enabling actor programming ? Would it be only heuristic programming in order to choose actor activation ? Something more/else ? Thanks. Dominique http://www.jroller.com/dmdevito
  13. Hi,

    What would be a rule engine with a language enabling actor programming ?
    Would it be only heuristic programming in order to choose actor activation ? Something more/else ?

    Thanks.

    Dominique
    http://www.jroller.com/dmdevito
    what do you mean by "actor programming"? do you mean functional? or you mean actor model? http://en.wikipedia.org/wiki/Actor_model from a production rule perspective, the Right-hand side is the action of the rule. Depending on the rule engine, the action could be procedural code, a method call, or a function call. The function call approach is similar to the actor model. That makes sense, since ART was influenced by LISP and the actor model was also influenced by LISP. The designers of ART originally wrote the engine is common lisp. It was later rewritten in C/C++, but retained many of the same ideas and concepts. CLIPS was written by NASA inspired by ART. JESS was inspired by CLIPS. If you want a rule engine that uses the actor model approach, i would recommend CLIPS or JESS.
  14. Hi,

    What would be a rule engine with a language enabling actor programming ?
    Would it be only heuristic programming in order to choose actor activation ? Something more/else ?

    Thanks.

    Dominique
    http://www.jroller.com/dmdevito


    what do you mean by "actor programming"? do you mean functional? or you mean actor model?

    http://en.wikipedia.org/wiki/Actor_model.
    Yes, I was thinking about actor model. I was wondering about rule engine "integration" with Java if Java would enable actor model programming. Would it be much more seamless/simpler ? Would it much more easier to write rules with such extended Java only (Scala ?), that is, without any use of XML ? These are inner questions I had in mind. Dominique http://www.jroller.com/dmdevito

  15. Would it much more easier to write rules with such extended Java only (Scala ?), that is, without any use of XML ?
    These are inner questions I had in mind.

    Dominique
    Hi Dominique, Let me try to shed some light into the question. Production rules in general have a set of conditions (LHS), that when evaluated to true will trigger the execution of a list of actions (RHS). For the Drools engine, the actions are usually a black box, meaning you can write whatever you want in there and Drools will just trigger the execution. Drools supports 2 dialects for that out of the box: Java and MVEL. As we both know, Scala code interact transparently with Java code and vice-versa, so, if your actions involve/require the use of the actor model, that is not a problem for Drools, as long as the triggering code is supported by Drools (Java or MVEL). Me and Michael, as fans of Scala would like to add support to Scala dialect in Drools and we might do so in the future. Just a lot already in our plates as of today, but the architecture supports it. Not sure why you mentioned XML? Although we do support XML for the rules, it is just a convenience as our main focus is on improving support to DRL (easier for developers), DSL, and authoring rules on GUIs (easier for business people). Cheers, Edson
  16. Hi,

    What would be a rule engine with a language enabling actor programming ?
    Would it be only heuristic programming in order to choose actor activation ? Something more/else ?

    Thanks.

    Dominique
    http://www.jroller.com/dmdevito


    what do you mean by "actor programming"? do you mean functional? or you mean actor model?

    http://en.wikipedia.org/wiki/Actor_model.


    Yes, I was thinking about actor model.
    I was wondering about rule engine "integration" with Java if Java would enable actor model programming.

    Would it be much more seamless/simpler ?
    Would it much more easier to write rules with such extended Java only (Scala ?), that is, without any use of XML ?
    These are inner questions I had in mind.

    Dominique
    http://www.jroller.com/dmdevito
    From a rule language semantics point of view. As long as the actions of the rule are defined as atomic actions, it should work well with the actor model. This implies the rule language needs to support functions as a first class concept. This is the approach used by RuleML specification. I've been using rule engines since 2000. The approach I use is to make the rule actions functions.
  17. Drools Solver solves planning problems such timetabling, rostering, bin packaging, freight routing, ... With Drools 5 it's been upgraded from experimental to beta and its extensive reference manual is published along with the other drools documentation: http://www.jboss.org/drools/documentation.html Download the release and take a look at any of the 6 examples (with runExamples.bat/sh), such as examination timetabling, course scheduling or miss manners 2009: http://www.jboss.org/drools/downloads.html
  18. Drools vs jBPM[ Go to top ]

    Since Drools now also covers workflow modelling, I wonder how the future of jBPM will look like. Does anyone know if those two products will be consolidated? Cheers, Gerald
  19. Re: Drools vs jBPM[ Go to top ]

    production rule systems are not well suited for sequential or linear business process. Although one can wedge it into production rules, it's better to integrate a BPM engine with a production rule engine. Take for example, saving data to a database. That tends to be a linear process, which should be done with a workflow engine that supports database operations. Forcing that onto production rule engine like jrules, blaze, clips, jess, drools, haley, etc isn't a good idea. Just because you can do it, doesn't mean you "should". a production rule engine should be used for inferencing or reasoning, not managing a sequential operation.
  20. Re: Drools vs jBPM[ Go to top ]

    Peter, We agree on this one ! ;) That's why the Drools Flow component that manages the workflow part is a separate BPM sub-component that manages the linear sequences, state management, etc., just like other BPM engines do. It is however closely integrated inside the platform, allowing unification and advanced integration. Kris Verlaenen
  21. Re: Drools vs jBPM[ Go to top ]

    Peter,

    We agree on this one ! ;) That's why the Drools Flow component that manages the workflow part is a separate BPM sub-component that manages the linear sequences, state management, etc., just like other BPM engines do. It is however closely integrated inside the platform, allowing unification and advanced integration.

    Kris Verlaenen
    It's also why other commercial products handle workflow in a separate component, but integrate the two within the same "engine". The concept and approach has existed for quite a while. Glad to see workflow is being handled by a separate sub-component. The old approach of using modules was a bit of a hammer approach. peter
  22. Re: Drools vs jBPM[ Go to top ]

    Since Drools now also covers workflow modelling, I wonder how the future of jBPM will look like. Does anyone know if those two products will be consolidated?

    Cheers,
    Gerald
    The official JBoss team response to this question is detailed on the Drools Flow page, linked in the main posting: http://www.jboss.org/drools/drools-flow.html?#Drools_Flow_and_jBPM Which I'll re-paste here: Drools Flow is a community project. jBPM is still the only official workflow product at JBoss. Drools Flow and jBPM are two separate projects. This is as a result of the need for process integration within the Drools knowledge-oriented platform (and advanced integration between processes and rules), which could not be provided by the jBPM project at that point. Both jBPM4 and Drools Flow are based on a (similar but independent) process framework with pluggable execution behaviour, what jBPM refers to as the PVM (Process Virtual Machine). However, until now, neither the jBPM or Drools team have been able to agree on a common way to move forward. We however do believe Drools Flow offers a set of features at least comparable with the jBPM project. Drools 5 is a complete rethink (not reimplementation) from the bottom up, with a new public api and everything designed with rules, processes and events as first class citizens - no feature is added without making sure that is is seamless, unified and orthogonal. Because processes, rules and events are integrated into the same engine, all three paradigms can easily take advantage of the common features (when you add a feature to one paradigm it is accessible to the others as well). There is simply no reason for multiple apis and deployment approaches that at best only burden the user with more complexity and at worst introduce impedance mismatches when two differing projects are used together. The traditional way of using two different offerings forces the user to work with a process-oriented or rules-oriented approach, which just gets in the way, often with great confusion over which tool they should be using to model which bits. Drools is a move away from a rule-centric or process-centric attitude to a more behaviour modelling approach with a lot more flexibility for users to model their problems how they want, creating a more holistic approach to software development (where the term holistic is used for emphasizing the importance of the whole and the interdependence of its parts). We do not believe in the process-centric approach only, where rule integration or event processing integration are not being considered or will be added as an after-thought rather then a basic principle from the beginning. This usually means that rule integration is limited to a stateless rule session being invoked in a process node (with all the mapping, marshalling and unmarshalling and consistency problems as a result). Being process-oriented also forces the user to learn duplicate, but different, apis and deployments approaches, will not provide one tool chain for supporting the life cycle of the business knowledge (like for example a unified knowledge repository and management tool as Drools Guvnor, or provide important features such as correlated audit logging and reporting.
  23. Re: Drools vs jBPM[ Go to top ]

    Hi Mark, Thanks for your comment. Cheers, Gerald
  24. Re: Drools 5 Released[ Go to top ]

    Mark, Congratulations to all the team! "Everyone's favourite Java Rule Engine", indeed! ;-) Straying off-topic, I am saddened that the TSS editors did not deem my announcement of JRules 7.0 newsworthy a couple of weeks back. I'd be interested to know what the policy is related to commercial vs. Open Source product announcements. All the best, Daniel Selman (ILOG, an IBM Company)
  25. Rule engine comparison[ Go to top ]

    I've seen a few Rule Engines pass by (jrules, drools, jess, clips,...) Has anyone made an attempt to compare a few of them? -Wolf
  26. Hi guys, Regarding the Drools vs jBPM discussion, I can share my recent experiences making the shift from jBPM to Drools. I started with jBPM about a year and a half ago, at the beginning it seemed to be a decent framework, very process centric and developer oriented. When I started to play with rules and delegating the business decisions to the inference engine, I started to notice that I needed to learn another set of very different of API, and that these two frameworks didn't integrate very well. When I decided to get involved with the Drools project, about 8 months ago, I realized that the integration proposed for version 5.0 was what I, as a developer, was looking for years. A whole environment that allows me to model different business situations with an unified set of APIs and merging three of the hot topic today: BPM, Business Rules and Complex Event Processing, all in one! And since it's not easy to define all my business logic using only one of those, it's promising to see I'm now allowed to combine (and integrate!) them whenever necessary. The other thing that really attracts me is the fact that the tooling created by the Drools team is great, very extensible and easy to use, with a lot of extra features compared with the jBPM tooling. In my opinion, the most useful features are: 1) A powerful set of nodes to model your business processes 2) An easy way to create your domain-specific processes. I created a lot of new domain-specific nodes in a very short period of time. And these can be used inside the graphical tooling immediately. 3) Nice debugging tools, you can follow your process (and rules) step by step, simulating your execution. 4) The real possibility to support and plug in new languages. I have participated in the OSWorkflow migration tool, and I see that is very easy to create support for different languages. This is so cool that it would also allow you to run jBPM3 defined processes with RuleFlow. 5) A lot more extra features like a human task management component based on WS-HumanTask, reporting, etc. So far I only mentioned the technical advantages that we discovered making the switch from jBPM to Drools, but there is another mayor thing that pushed me towards Drools, and that is the fact that the group of core developers are really open to new ideas (that is very cool, in not every project you can find that) and let the community members share their personal experiences and contribute with them on an every day basis. It is also important to mention that the Drools project seems to be be evolving at a much faster rate than jBPM, which seems to have been frozen for about 3 years now. From what I've seen, they are working in version 4 of their framework, without adding new functionality compared to version 3. I hope that my experience helps you to choose the right tool for your situation, I have already chosen, and that is why I try to contribute every day to this nice framework and promote it to succeed, because it makes the life of the developer easier. And that is all we want !! Greetings
  27. Hi guys,

    Regarding the Drools vs jBPM discussion, I can share my recent experiences making the shift from jBPM to Drools. I started with jBPM about a year and a half ago, at the beginning it seemed to be a decent framework, very process centric and developer oriented. When I started to play with rules and delegating the business decisions to the inference engine, I started to notice that I needed to learn another set of very different of API, and that these two frameworks didn't integrate very well.

    When I decided to get involved with the Drools project, about 8 months ago, I realized that the integration proposed for version 5.0 was what I, as a developer, was looking for years. A whole environment that allows me to model different business situations with an unified set of APIs and merging three of the hot topic today: BPM, Business Rules and Complex Event Processing, all in one! And since it's not easy to define all my business logic using only one of those, it's promising to see I'm now allowed to combine (and integrate!) them whenever necessary.

    The other thing that really attracts me is the fact that the tooling created by the Drools team is great, very extensible and easy to use, with a lot of extra features compared with the jBPM tooling. In my opinion, the most useful features are:
    1) A powerful set of nodes to model your business processes
    2) An easy way to create your domain-specific processes. I created a lot of new domain-specific nodes in a very short period of time. And these can be used inside the graphical tooling immediately.
    3) Nice debugging tools, you can follow your process (and rules) step by step, simulating your execution.
    4) The real possibility to support and plug in new languages. I have participated in the OSWorkflow migration tool, and I see that is very easy to create support for different languages. This is so cool that it would also allow you to run jBPM3 defined processes with RuleFlow.
    5) A lot more extra features like a human task management component based on WS-HumanTask, reporting, etc.

    So far I only mentioned the technical advantages that we discovered making the switch from jBPM to Drools, but there is another mayor thing that pushed me towards Drools, and that is the fact that the group of core developers are really open to new ideas (that is very cool, in not every project you can find that) and let the community members share their personal experiences and contribute with them on an every day basis.

    It is also important to mention that the Drools project seems to be be evolving at a much faster rate than jBPM, which seems to have been frozen for about 3 years now. From what I've seen, they are working in version 4 of their framework, without adding new functionality compared to version 3.

    I hope that my experience helps you to choose the right tool for your situation, I have already chosen, and that is why I try to contribute every day to this nice framework and promote it to succeed, because it makes the life of the developer easier. And that is all we want !!

    Greetings
    This is going to come across as nitpicking, but the approach isn't new. If you take time to look at what JRules offers, you'll see it's been done. Not only that, it's been in production for years on many projects. I would encourage you to look around a bit more and try to learn from other sources. There's a wealth of ideas and approaches out there. One major limitation with workflow is that it only works well if the process fits into a neat simple sequence. If a process has no pre-defined sequence, it "can" be easier to handle with production rules. I say "can" in quotes for 1 reason. The user has to understand logic programming and proper rule chaining. The biggest challenge with production rules is learning logic programming. Most users of rule engine never get this. I've interviewed a dozen people claiming to be rule consultants with 3-5 yrs of experience and didn't know the basics of logic programming. Once a developer takes the time to learn logic programming, production rules can become a powerful tool in a developer's toolbox.
  28. Imperative approach of modeling BP/W uses graph based representation of execute path or tasks order. Declarative approach is set of rules, what describe relationship between tasks. Imperative model is most restricted, hence flexibility of declarative is most comprehensive. At least declarative model make easy process flexibility than imperative model. (Above statement in Wil van der Aalst et al. opinion: Constraint-Based Workflow Models: Change Made Easy Process Flexibility: A Survey of Contemporary Approaches) In this respect: Drools better choice, than jBPM. Whether Drools will go on declarative BP/W way? (How, when and where?)
  29. Drools Flow is not using a constraint model, but due to the close integration with the rules engine, it does allow for more declarativeness (and thus increased flexibility). Using rule set nodes for example can greatly enhance the flexibility of your process, by extracting the decision logic from the process itself. In advanced execution mode we step away from the purely imperative approach and allow rules to even augment the logic defined in the process, to for example override the logic in the process for exceptional cases. This allow the process to focus on the "normal" control flow so that exceptions do not necessarily clutter the process (but can be specified using rules). In the future we will extend this further, for example by combining both modes and by introducing dynamic nodes (which acts as a placeholder for dynamically selected nodes using rules), etc. Kris Verlaenen
  30. Thank Kris for reply! It's good news. As you wrote, Drools mixes succesfully both approaches. This is promising because it. (As most often, extremity is never fruitful in case of multipole variant solution, rather something compromise be possible useful...) Advanced execution coming soon. I understand? (If it exist even now, then I'm sorry, but I found nowhere in dox.) Rules allowing is dynamic in Advanced execution, that is it does work for cases in executing? (So this mechanism can fill in type flexibility by deviation. Perhaps it claim an easy management tool...) Dynamic nodes will fill in type flexibility by underspecification... And here I'm, where my original thought ran: support (api and tool) of flexibility by change and four notorious problems of van der Aalst - dynamic change (e.g. migration) - management information problem (e.g. to aggregate state of cases for multiple variant process) - coordination problem (for inter-organizational workflows by enforcing local consistency rules) - difference measuring What You think about it? Thx.
  31. Imperative approach of modeling BP/W uses graph based representation of execute path or tasks order.
    Declarative approach is set of rules, what describe relationship between tasks.

    Imperative model is most restricted, hence flexibility of declarative is most comprehensive. At least declarative model make easy process flexibility than imperative model.

    (Above statement in Wil van der Aalst et al. opinion:
    Constraint-Based Workflow Models: Change Made Easy
    Process Flexibility: A Survey of Contemporary Approaches)

    In this respect: Drools better choice, than jBPM.
    Whether Drools will go on declarative BP/W way?
    (How, when and where?)
    Doesn't that depend on the use case. If I have some business logic for saving data to the database, that's going to be a sequential process. On the other hand, if we have a real-time account management service which third biz partners use, we "probably" want declarative and model it as states. The challenge for developers is figuring what the use case really needs and then implementing a solution appropriately. I've seen people try to handle business process that don't have a fixed sequence with BPM/BPEL, and end up with a huge graph with thousands of nodes and hundreds of branches. Clearly a gigantic graph is difficult to maintain, so developers need to take time and understand the problem and tools. On the other side, I wouldn't want to use a production rule engine to save data to a database. Sometimes a graph is appropriate and other times it's not.
  32. Two examples of real world[ Go to top ]

    Thank for Peter called my attention to some important aspect. I agree for Your opinion about particular use case determine balancing between imperative and declarative models, whereas persistable declarative model isn't impossible... Here are two examples from my milieu: 1. Call and control center of emergency service, where two-three protocols are leading role (inquiry, [guidance,] dispatch) and dominant requirement is time-critical and flexibility by deviation. 2. Typical office-workflow: deal subsidies in labour market (e.g. dole, retreining of unemployments and assistance of employments for making workplace and others social services...), where freqently (but not monthly, rather quarterly-yearly :-) changes legal, financial and economic environment, hence workflow models ought to be variable. My opinion flexibility by change appropriate with regard to this. What do You think? I see well? Thx.
  33. Re: Two examples of real world[ Go to top ]

    Thank for Peter called my attention to some important aspect.

    I agree for Your opinion about particular use case determine balancing between imperative and declarative models, whereas persistable declarative model isn't impossible...

    Here are two examples from my milieu:
    1. Call and control center of emergency service, where two-three protocols are leading role (inquiry, [guidance,] dispatch) and dominant requirement is time-critical and flexibility by deviation.
    2. Typical office-workflow: deal subsidies in labour market (e.g. dole, retreining of unemployments and assistance of employments for making workplace and others social services...), where freqently (but not monthly, rather quarterly-yearly :-) changes legal, financial and economic environment, hence workflow models ought to be variable. My opinion flexibility by change appropriate with regard to this.

    What do You think? I see well?
    Thx.
    I've been working with rules since 2000 and in that time, I find that figuring what's needed is the hardest part. Take a task assignment example from health insurance. When a person goes to the doctor for a checkup, that information is sent to the insurance agency. When they get that, a batch system analyzes the details of the examination and decides if a patient out reach call is needed. Say John Doe is diagnosed with high blood pressure. The company has identified high blood pressure as a critical out reach program, which reduces claims and increases profit. Say John Doe is already taking high blood pressure medication and gets a checkup every 6 months. If we modeled this using a sequential workflow, we "may" run into an issue. We might want to check if the customer had high blood pressure in the past, known allergies to medication, age, gender, plan type, geographic region, or other pre-existing conditions. If we try to graph all the possible branches, it could become a gigantic graph with hundreds of branches. Instead, if we model this as states with declarative rules, it "may" be easier. In contrast, if we want to manage time off request, that fits neatly into a simple sequence. So even if something looks like workflow, it might not be. The reverse is also true. peter
  34. Congratulations ![ Go to top ]

    Congratulations on the JBoss Team for this great release ! This product really rocks !
  35. Drools Chance subproject[ Go to top ]

    More new features coming up with Drools Chance (http://blog.athico.com/search/label/Drools%20Chance) Chance is the Drools module for reasoning with Imperfect Knowledge and will include: - generalized truth degrees to model different types of imperfect information (vague, imprecise, uncertain, incomplete, ...) - configurable evaluators and operators - extended language with keywords and logic connectives - support for exceptions - ... Consider a simple example in many-valued logic: rule "Server alive" when //At least one message has been acknowledged recently exists ( Message( sender == monitor, $msg : msg, $t : time) over window:time( 10s ) and @(kind = "Lukas") Acknowledge( target == monitor, msg == $msg, time ~close @(args="50ms") $t) ) and @(kind = "Min") forall // server has always ack'd "promptly" (within a 1s period) ( $ping: Message( sender == monitor, target == server, $m : msgId, $ts : time ) over window:time( 10s ) and @(kind = "Lukas") $ack : Acknowledge( sender == server, target == monitor, msgId == $m, time ~close @(args="1s") $ts ) then log("Server Reliability degree " + drools.getConsequenceDegree()); end The rule could be part of an event-driven Network Monitor: the monitor pings a server at regular intervals (e.g. 1s) and waits for an ack in response (to keep things simple, acks echo the body of the ping message), which is expected to arrive within, say, 1 millisecond. The idea behind the rule is: "if acks are received, but not from the server, then assume it (or at least the connection) is down". The concept, then, is refined to take into account how quickly the acks arrive using the custom (fuzzy) evaluator "~close": a 1s response usually has a different meaning than a 1ms one, so the consequence can take this into account. The project is still experimental and will undergo many changes, but progress and examples with explanations will be posted in the blog in the days to come Davide Sottara PhD Student Department of Electronics, Computer Science and Systems Faculty of Engineering University of Bologna email : davide.sottara2[at]unibo.it, dsotty[at]gmail.com