Tech Chat - Mike Neale on JBoss BRMS

JBoss Enterprise BRMS (Business Rules Management System) provides an open source business rules management system that enables easy business policy and rules development, access, and change management.  BRMS builds upon the Drools project, providing a JCR-based repository and an Ajax-based front-end that uses GWT.  In this interview, BRMS Project Lead Mike Neale provides some background on the BRMS project, delves into its architecture, and describes how developers can use business rules in their applications.

DZone: Mike can you tell us a little bit about your role at Red Hat?

Mike: Yes, I originally worked, and still work, on the Drools project. I came from the Drools user community and joined JBoss pre-Red Hat. It turned into Red Hat and since then, we've worked on a product called the BRMS, which is now a full-fledged JBoss and Red Hat product. It stands for the Business Rule Management System. I'm the project lead for the BRMS side of things, and I also contribute to Drools.

DZone: Could you give us some background on the Drools and BRMS projects?

Mike: Drools had been in use for obviously quite a while. I was a user before I became a contributor, and developer, and now a professional on it. But we found a lot of customers asked for, or built, their own management system to manage versions, concurrent versions, retiring rules, promoting rules, deploying rules; then, most importantly in some ways, visual metaphors for editing rules. One of the promises made about rules is that they're lifting up the level of logic a bit, so naturally people want to let non-technical users, business analysts, domain experts edit rules. So something like the BRMS came about to address that. We looked at what the customers were doing. They were building their own bespoke solutions, and we thought, well, let's take some of their ideas, some of their contributions, and try and build a product out of it.

The BRMS is now a product available from Red Hat. It's built on Drools. It contains the Drools run-time, and compiler, and all the other tools around it.

DZone: What does BRMS provide in addition to the basic Drools engine?

Mike: The Drools engine is obviously an engine compiler, and set of other tools, a plug-in for Eclipse. The BRMS provides a repository, a Java content repository, the JCR API. We picked that standard at the back end. At the front end, we use GWT to do the Web toolkit-based widgets to build our Web-based interface. On top of that, we have other ways for people to access the repository via APIs and WebDev. Then there's an additional Eclipse plug-in that allows people to have rules both in the BRMS repository, which typically would be stored in a database, as well as in their workspace. The main thing, the most physical thing, of course, is the Ajax Web interface.

DZone:  You mentioned the Ajax Web interface. Is BRMS primarily a GUI-driven application? Is it something that a developer would primarily interface with, or the business analyst?

Mike: It's really intended for the business analysts. Now, someone like a developer, or an administrator, or a power user would be involved--at least to set it up; certainly system administrators--to set permissions, install and configure it. Then perhaps developers would upload their models if they're using it, maybe create some functions. But the real aim of it, and where a lot of the work is, is letting these other users access the system. Either in a read-only way, or with the ability to edit things, maybe even create new things. But the focus is on those users. That's actually not easy to do.

We're trying to simplify complex things in an interface that they can understand, using things like decision tables (which we're doing more and more like spreadsheets), using spreadsheets and other what we call “metaphors” for editing rules. But underneath, it generates rules that are fed to Drools to be executed at run-time.

DZone: Is there a notation that you've standardized on?

Mike: No. It's a heterogeneous repository, so that means one of the ways, a very popular way, for people to manage rules is actually in an Excel spreadsheet, or using OpenOffice. One of the constraints we have is we want to let people edit rules, but we don't want to make them only use one or two GUIs. We want to let them edit in something like Excel and then upload it. So we store that as a blob, which is something that the JCR is great at doing and indexing.

Also, we might store rules. A lot of them are in an XML format. Basically, each type of rule, artifact, or file has its own storage format, and we just store them all. So where we do provide a GUI, obviously the GUI knows how to render and edit that file format. But where we don't, it's stored, and it's still compiled if it's relevant. There's no one notation.

What does spit out at the end? When you build your knowledge bases for Drools, it spits out the Drools Rule Language, the DRL, or a binary compile package. We're always keeping our eye on standards that are out there, and we'll support them as they become available.

As the repository is a heterogeneous data storer, we are thinking about storing other things like BPEL and BPM as well, and providing editors for them as well. But, as I said before, that's just one artifact type that we'll manage. It's a heterogeneous set of data.

DZone: Does BRMS allow for the extrapolation of rules and workflows from a given code base? 

Mike: Not directly. There's obviously a bit of skill involved with that. We do have tools that for creating rules: - if there are sets of data in some tabular database, or any sort of database, or some data source, we can create a template that will then combine that data together and generate rules. So we can certainly do that. But we don't have any sort of developer extraction tools as yet to extract rules out of it. There's obviously a bit of skill and practice involved in learning how to use rules.

DZone: What type of support does the engine provide for integration with various testing tools?

Mike: Obviously, if you're writing Drools rules in the technical rule language, you can have it as part of your project, and you can run the usual tools. It can just be part of your build process. In the BRMS there's also a graphical tool. When you provide your models or define your models graphically in the BRMS, it can generate a GUI that allows you to populate fields, check that rules fire, check the results afterwards, analyze them, and then build that up into a suite of tests. You can run that one at a time or in bulk, see how many passed, how many failed, see how many rules you tested, that sort of thing.

That's integrated into the BRMS, the idea being, if the whole point of rules - or one of the points - is to allow changes on the fly, we want to have a high level of testing involved. So when people make a change they can press a button and check all the assumptions that they had made - like they might have put a test to check that something's always true, that it's all green, that it's all good to go - before they deploy the rules.

So that's integrated graphically. You can also call that from a build service. You can hit a URL and get a result from that as part of your build, if you were integrating it, but you don't have to. You can get those test scenarios out of the repository via WebDev or similar as XML and you can pass them to a runner so it can run it as part of your application.

Like I said before, at the lowest level where developers are integrating, they can just use the normal testing tools.

DZone: How do I actually use business rules in my application?

Mike: One of the more popular ways is using Drools run-time as a library. Say you would use the BRMS to define your rules, to manage them, to edit them, to review them, perhaps even to test them, all independently of your application. You then put the Drools run-time in your application. Then you configure what we call the “rule agent” or the “knowledge agent” to basically go out, possibly across the network - it could get in from a class path or a file system; it could be anywhere - to go out, grab the rules, load them into your application at run-time, and then make sure they're kept up to date. So if you make a change in the repository, it will then be reflected in the run-time.

A developer would then talk to the engine via the Drools API or the JSR-94 draft standard, something like that. So they're basically passing their objects to the engine, letting it do its reasoning, and then getting results back.

Another approach that is becoming popular is rules as a service, so it can just become a part of a service bus or something. We're working on providing an out-of-the-box service so that people can define models, create rules, edit, test, and deploy them to a Web, or a RESTful, or a SOAP service and call that remotely.

So the advantage of the latter approach is that you don't need to have any libraries in your code base, and it doesn't even have to be a Java application. You're just passing data in an XML, or possibly even JSON format, and then getting results back.

DZone: Can the rules artifacts actually be used for code generation?

Mike: There's nothing in the product version that does that, but there are experimental libraries we're working on that will generate static code. One of the fundamental designs deep in Drools is that it uses the Rete network to optimize stateful execution, but, in many cases, people don't actually need that. They just want sequential rules where it runs through a whole condition, but they want to use all the other tools. They want to use the APIs and the analysis tools on that, but really they want the performance of straight-line code, which sometimes can be faster and use less memory. So we're working on tools to basically generate Java code that you can compile; but at this stage, they’re not part of the product.

DZone: For distributed teams where multiple business analysts interface with the BRMS interface, how do you ensure that rule changes are being synchronized effectively with the code depository?

Mike: As it's a Web interface, you can run one single instance of a server and have all analysts accessing it over the network. You can run multiple ones. We've just had a user working this week on making sure clustering works so that you can have a single repository clustered with multiple Web front ends. But they can access it concurrently. They log in under their own accounts. It uses, like most things, optimistic blocking. So when someone opens something to edit, they've got edit permissions that will take effect - the repository will note that Joe's got this rule open, or this decision table open, or this artifact open. If someone else goes to open it and someone else has it open, it'll give them a bit of a warning, and they can choose to ignore that. But at least they know that someone else is looking at it.

Of course, as it's optimistic blocking, if someone's made a change and you try to make a save, it will tell you that they've made a change.

DZone: How do you ensure optimal performance of deployed business rules?

Mike: Well, that's one of the features of the underlying Drools library itself. A lot of it is designed for performance. You take the rules. It doesn't interpret them. It doesn't run through them one at a time. It actually compiles them into a network. That's what the "Rete" means. It's Latin for "network, " or something like it. It actually has a thing inside it called a “logic transformer”, that actually twists the logic a little bit into a network that's fairly optimal. In a general case, it runs very fast. It's certainly competitive with anything else out there. In many cases, it will outrun code that you could write by hand. Unless you like writing really, really messy code.


DZone: Can you talk about some of the features you're working on for the next major release?

Mike: Yes. One of the features that is on there right now for the next release is a Web execution server. This will be an out-of-the-box server that people can deploy, that they can access from their applications. They don't have to be Java applications. Then there are more testing tools. We're focusing back on testing tools, especially for analysts that use spreadsheets and table-driven data to drive the rules, and pull data from databases and things like that. So those two features are our core focus.

There are going to be a whole lot of usability features. Now we're studying people for usability. How can we improve it? Look at the types of users that we want to have use it. Obviously, being an open source-driven project, a lot of the feedback comes from developers, which is really great. It's really good for the engine, but in terms of the user interface, they're not necessarily our audience. So we have to take everything with a grain of salt and then look at this other group of users who aren't as active in the community, and try and work out what they actually want. So there will be a lot of improvements to the user interface.

DZone: How can developers get started with using BRMS?

Mike: The easiest way is to download it. I think there's a trial download. There's certainly the project download. We tend to ship it either as a WAR file or as a zipped-up, stand-alone server using JBoss App Server, sort of a stripped-down version of the App Server. It's just a point-and-click, start it up as a server. Point your browser at it, and there you go. Obviously, inside that package is the Drools run-time JARs, if you know to use them.