The past couple of days I’ve been engaged in a project that took me away from ILOG JRules V7 altogether. I’ve been to Istanbul, Turkey for a code review of a insurance application with a home-made BRMS system amongst the other features. It’s not the first time when I was tasked with a job which quite unexpectedly touches parts of my learning experience I was gaining (undertaking?). It’s nice and eventually makes me wonder why people go with a home-made solution without leveraging existing ones. One of the reasons is that the so-called “existing solution” had not existed at the time the own-crafted solution has been developed (which was the case in the project) and the others including lack of time to evaluate candidates or even not knowing that eventually it becomes such after months or years of development. It doesn’t sound well, but many people I met told me that they consider developing their own solution better than evaluating existing ones (quite often very expensive at first sight, but not that much after some time of developing their own without a finish on a horizon). I don’t really know who should be blamed on – PMs, technical architects or software developers (putting aside the customer with money but not much time refining its business vision of the project). Anyway, it all boils down to constant learning…
Just finished listening to the Unit 5. Orchestrating rule set execution of ZB300 Developing Business Rule Applications with IBM WebSphere ILOG JRules V7.0 and it was quite terminology-loaded. I believe that many of the questions during IBM Certified Application Developer – WebSphere ILOG JRules V7.0 certification exam will be around the unit. That’s why I took some notes to remember the vocabulary and let you appreciate its beauty – I hope one day it will sound familiar and not be confusing any more :]
If you followed the blog for some time, it should already be known what rule project is. It’s a project for rules. Rules are business decisions (or whatever high-level definition exists in books). I’d prefer explaining rules as conditions. When you develop a software I’m sure you’ll stumble upon many of if or while conditions and although they’re usually simple boolean expressions they could become quite involved too, and thus refactoring them to a method or external service (hosted on JRules infrastructure) might make sense. Just to be remembered – with a rule project the development story in JRules’ Rule Studio begins.
I couldn’t figure out exactly what rule artifacts are. On one hand I’d call everything in a rule project a rule artifact whereas it turns out to be somehow less general as a mere item in a rule project. I’d be grateful to find out the answer if you know it and by any chance are reading the blog entry. Thanks.
The term decisions and rules is quite often used interchangeably. I think it’s a matter of speaking style and the audience what makes a better wording for you (or them). I’d call decision as conditions with no hesitation. Be careful what you hear and ask when it’s not clear as these three words can convey some additional value and be slightly different depending on a context.
Rule packages are a way to organize business rules in a rule project (as does a package in Java language). That should be pretty easy to get a handle of.
Rule set is an executable set of rules and other rule artifacts to create a business decision with no notion of sequence or succession and deployable to Rule Execution Server (RES)/Rule Engine. Many rule sets in a single rule project can exist with each sharing rules as necessary. It’s been called as the first key element for rule orchestration. If I’d counted all the terms in the Unit, I’m certain “rule set” would be amongst the most often spoken ones.
Rule flows are a series of tasks within a rule set. It’s a definition of execution order of rule tasks with transformations between them and the transformation’s conditions; representation of the application business logic; produces a single decision based upon containing rules.
Rule task is a group of rules or simply a node in a rule flow for rules or rule packages. It’s part of rule flow (which in turn is made of rules).
Rule set parameters is a means of passing data to a rule set to work on; use to transform data from an application to a rule flow, which in turn passes it on to its rules; it is the only way to convey data between a calling application and rule set.
Rule set variables is a means of managing internal state of a rule set; defined per rule project and visible to all of the rule project’s rules which can be useful to share data between rules, functions and tasks.
There was a little bit about rule selection, rule ordering, rule overriding, rule set archive and ruleapp, but it’s enough for today. Next time.
I wonder how many of you would rather watch than read. Please comment and let your opinion be heard. Screencasting is on my TODO plate so with some encouragement from my readers I think I could take on it.