Collaboration: At the Extremities of Extreme
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Ryan Slobojan on Aug 22, 2007
JBoss Drools, an open-source business rules engine, recently reached version 4.0. InfoQ took the opportunity to learn more about JBoss Drools and its current and future capabilities.
It has been a little over a year since JBoss Rules 3.0 was released, and the first big change is the name - with this release, JBoss Rules is becoming JBoss Drools. Along with the new name come new API and language features which break backwards compatibility with 3.0. According to the official release announcement, the major features and benefits in 4.0 are:
Version 4.0 is also available in the JBoss Maven repository for Maven users, and the Eclipse Drools IDE has a number of new features and capabilities to go along with this release. There is a detailed overview of the changes available in PDF form as well.
- Faster performance: Drools 4.0 is faster and leaner than its predecessor and features a smaller memory footprint. Internal benchmark testing showed improvement from minutes to seconds.
- Improved expressiveness: This release introduces a dramatically more expressive and powerful declarative business action scripting language (MVFlex Expression Language). Users will find that it is more concise as well as more readable.
- Business analyst friendly tooling: A new Guided Rules Editor lets non-programmers point and click their way to advanced declarative business rules that automatically bind to enterprise data without writing a single line of code. Basic menu prompts and drop-down lists do the guiding.
- Rule flow capabilities: This visual modeling technology enables users to declaratively model execution paths of related rules. It also allows for simultaneous flows within a single working memory and essentially organizes rule execution along the requirements governing a typical business process.
- Multi-application support: Improved support for stateful and stateless processing as well as overall thread safety helps make Drools even easier to embed within Java Platform, Enterprise Edition (EE) and service-oriented business applications.
- Hibernate-ready: Users can assert facts directly from Hibernate-driven RDBMS queries. Existing Hibernate components can be used directly in the rules engine, reducing the amount of coding.
- BRMS for non-programmers: A technology preview, the new BRMS is a web-based, AJAX-enhanced, collaborative rule authoring, versioning, and management system. Business analysts can now interactively author and/or modify rules that are automatically versioned. Administrators now have full lifecycle control over which rules are in QA, staging, production, etc.
Mark Proctor, the JBoss Drools lead, recently talked about what to expect of future JBoss Drools releases:
We are still missing 3 main things:Proctor also described some community projects, such as an upcoming solving framework called drools-solver, and a fuzzy-logic evaluation system which will plug into JBoss Drools. Further into the future, Proctor believes that JBoss Drools will grow from a rules engine into a fully integrated artificial intelligence platform for behavioural modelling.
analytics
ontology modelling
testing
Our next release will be quite quick, I'm hoping approx 3 months. That release should hopefully have analytics and testing in it, as I want to get those out as soon as possible. Ontology modelling will take a little longer so will be in release after that, along with prolog style backwards chaining (for a full hybrid engine) and Complex Event Processing(CEP)/Event Stream Processing(ESP).
I just wanted to say great job on the Drools projects. Keep it up!
Best Regards,
Richard L. Burton III aka rburton
Business analyst friendly tooling: A new Guided Rules Editor lets non-programmers point and click their way to advanced declarative business rules that automatically bind to enterprise data without writing a single line of code. Basic menu prompts and drop-down lists do the guiding.
I am wondering if anyone finds this feature useful.
I myself have worked with several rules engines and the idea was always the same - business people, who don't know coding, will be able to create and wire business rules.
However, never in my experience such feature ever ended up well accepted. Moreover, it brought certain disadvantages to code, such that your business logic was now defined in 2 places, partially in Java (rule implementation) and partially in the rule itself using some sort of rule scripting language specific to rules engine.
Another disadvantage is that business people still had to learn some sort of light weight scripting language for rules which is a challenge on its own.
Does Drools address these issues? Is there anyone who is using Drools and at the same time does not know how to code?
Best,
Dmitriy
GridGain - Grid Computing Made Easy
I myself have worked with several rules engines and the idea was always the same - business people, who don't know coding, will be able to create and wire business rules.
However, never in my experience such feature ever ended up well accepted. Moreover, it brought certain disadvantages to code, such that your business logic was now defined in 2 places, partially in Java (rule implementation) and partially in the rule itself using some sort of rule scripting language specific to rules engine.
I don't really buy into "Business users write rules" myself except in very simple cases. Something like Drools' decision tables, where business users parameterize rules written by developers seems a little closer to feasible.
That said, I think from a marketing perspective, since people often look at rule engines with this in mind, it's a useful feature to have for adoption, even if people end up deciding not to use it. I hope that it is actually useful to people as well.
Came out today, and don't see it in the article above, which also came out today:
blog.athico.com/2007/08/drools-features-and-scr...
I believe that any effort in this direction (facilities) is welcome
Congratulations guys, Drools rocks!
In most Rules Based System functionality (at least from a business perspective) will change ( sometimes a lot) when the rules are modified. Its hard to image a business user (even a powerful one) can just go in and change the rules in a production system. Which means there will be seperate environments for performing various types of tests. I doubt if business users are willing to do that.
Another type of software which makes this marketing promise is "Workflow based softwares". Again business users can hardly be expected to go in and change process flow in a sophisticated application like Oracle BPEL.
Ofcourse developers welcome good tools and such tools make using Workflow systems and Rules engine very accessible. But somehow "Good for developers" does not sell as much as "Business users can now express functionality using their lingo".
I believe the 'Business analyst friendly tooling' could hold quite large potential for us. We typically code our rules into a DB structure in such a way that other non IT/developer staff can change the rules with a GUI we have developed. These staff are reasonably technically minded, and deal with business clients. If they could have a tool like this, and it is relatively easy to use, it would save us maintaining our own rule engine.
Its hard to image a business user (even a powerful one) can just go in and change the rules in a production system.
It happens all the time where I work. Someday it will be our downfall, but we can't talk senior management out of it.
Many vendors are not doing the industry any good by peddling the vision that you can get rid of your developers. We certainly don't do that, what we do is provide tools to solve a variety of problems in a variety of ways that assist both developers and analysts and enables them to more easily work together. My personal aim is to build a platform that empowers developers to declaratively model the behaviour of complex problems, that's why we have worked on building such a rich language and integrated ruleflow for process modelling. Drools now has the richest rule language of any system, commercial or open source.
On the other hand we also have to solve real world business problems; where we want to enable developers and business analysts to work closer together, to allow developers to give (in a controlled manner) more autonomy to analysts. Environments like Decision Tables, Guided Editor and DSLs when applied correctly to the right problem domain work. We still have other authoring metaphors to add such as Decision Trees and Score Cards. Do they remove the need for developers, no. Do they allow analysts to work end to end on their own out of the box, no. Do they empower the analysts with more autonomy, yes. Do they provide an environment where analysts and developers can have a clearer idea of what each other is saying and trying to describe and model, yes.
Mark
blog.athico.com
That really depends on the use case and the scope of the DSL. I've built DSL for compliance in the past and it worked well. In this case though, the language was specifically designed for compliance officers in their language. I've also worked on DSL for privacy rules, which is a very focused and narrow scope. A general purpose natural language editing interface still has a steep learning curve. Teaching business users to simple rules is feasible. Teaching business users to write complex rules is very difficult.
peter lin
"That really depends on the use case and the scope of the DSL.". Obviously, hence "when applied correctly to the right problem domain work."
Mark
blog.athico.com
It also depends on your "non-programmers". At Exchange Solutions, we were able to be pretty successful with Decision Tables on Drools 2.X with the right business users. It still wasn't perfect, still required some developer intervention, wasn't the sort of thing you'd give to any business user, but we had non-programmers doing a fair amount of rule work, and most importantly, this work was done by the people specifying the logic behind the business rules, which cut out a lot of the requirements, analysis, design communication that has to happen when the requirement-specifiers and implementors are one or more steps removed from each other.
From my own experience, many sales people hide the real cost of training business users. I've heard sales people say "it takes a few weeks". My experience is it takes 8-12months for business users to get comfortable. In many cases, the existing business users may not be able to write rules, which means they need a skilled business analyst. the industry on the whole needs to improve that. my bias 2 cents.
peter
Implemented as you describe I would agree this is a non-starter. Most good rules management systems (disclosure: I work for Fair Isaac with Blaze Advisor) allow you to hide some of the rules complexity using decision tables, decision trees or templates. This allows business users to collaborate with programmers on maintaining the rules. It does not replace programmers nor does it introduce a second scripting lanugage. It just presents another, more business-friendly, view of the declarative logic so that business users can do their bit in maintaining the rules.
JT
James Taylor
The EDM blog
My ebizQ blog
Author of Smart (Enough) Systems
See my answer above - business users can (and many do) write rules that conform to rule templates (just like they can build reports that conform to report templates) and use metaphors like decision tables and decision trees.
JT
Our experience (disclosure: I work at Fair Isaac with Blaze Advisor) is that organizations still have development/test/production environments and that the advantage of using a business rules management system are twofold:
- business users can make many of the updates to the development system (reducing interpretation errors and getting the development system updated faster) - IT still push it into production
- in an emergency the logic in the production systems can be changed more rapidly (typically by IT and the business in parallel).
JT
James Taylor
The EDM blog
My ebizQ blog
Author of Smart (Enough) Systems
Mark
As usual I quite agree!
JT
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
18 comments
Watch Thread Reply