The more I read about IBM WebSphere ILOG JRules V7 and BRMS concepts the more clear they become to me. It’s quite common and will not likely come as a surprise, but during that time I found out that trying to grasp the concepts all at once, in one shot was almost impossible task to achieve. Having spent a couple of weeks of extensive learning with no help from a mentor or a course instructor, a 2-3-week-long break, and getting back pays back now. I think I felt confused with the new vocabulary of ILOG JRules quite a lot and looking for help would have been as much exhausting experience as the learning itself. I can feel the pain again while staying in Istanbul, Turkey as all around me is so new to me and the “signal noise” seems slowing my mental processes down. During the first days of my ILOG JRules learning, I’ve been feeling completely swamped with the information income and having had a short break has certainly made me relieved and the knowledge digested. It’s been quite a refreshing and unforgettable experience that I haven’t felt for quite a while. I wish you experienced it too for its exploiting feeling once most if not all is clear(er).
With this said, I’ve carried on with my reading of the Information Center and took some notes that eventually led me to think what it is to create an application – a business rule application (BRA) – with WebSphere ILOG JRules V7. Here is the short story to let you get started (and me to write all of the knowledge in a few blog entries just before I attempt an ILOG JRules exam). It’s mostly based on my notes from the Tasks section in the Rule Studio chapter of the IBM WebSphere ILOG JRules Version 7.0.2 Information Center.
You, the developer, use JRules Rule Studio (RS).
The real journey begins with a new rule project. You could create some auxiliary projects for the rule project and reuse them so the beginning of the work would’ve been earlier in fact, but it doesn’t really matter. Without a rule project you can’t think about a business rule application development with ILOG JRules. At first you may be surprised with the catalogs and views, but behind the scenes it’s merely a project like any other project you may have created with Eclipse IDE. Worth to point out is that JRules Rule Studio is Eclipse-based. You’ll use the Rule Perspective for most of the work as a developer.
As any project in Eclipse with its references, a rule project is no different and its modularity comes with reusing existing rule projects and their items aka rules artifacts, e.g. BOM entries, queries, rule artifacts and templates. You define the references as the rule project is created or later using the Properties dialog.
Java Execution Object Model (Java XOM) is, yes you’ve guessed it right, the technical, execution model for rules. It could be a JAR file or a class folder. Java XOM is…artificial name to confuse newcomers and make things harder at first, but its concept is quite simple 🙂 It’s nothing more, but a mere set of POJOs. No need to extend a superclass or implement an interface. It’s a model after all, with no external dependencies. JRE libraries are included as XOM by default.
You can also define a dynamic XOM with a set of XSDs. Like a Java XOM, a dynamic XOM sets a model for the business rule application. XSDs and POJOs share the same semantics and JRules leverages it. I don’t know it for sure, I’m speculating, but I believe XSDs are transformed to their Java counterparts behind the scenes, so the dependency is Dynamic XOM <– Java XOM <- Rule Project where <– means optional dependency and <- mandatory one.
In a rule project, you organize artifacts in packages for simpler maintenance – XOMs are packaged and so are rules. It doesn’t make any difference for rule execution environment whether your project artifacts are packaged or not. Just like in the “pure” Java world with no (J)Rules.
Then comes a verbalization of XOM to build a Business Object Model (BOM). I haven’t seen it presented this way and whenever verbalization crops up BOM is nearby. Although it’s BOM being verbalized, it’s in fact XOM implicitly.
I think it’s the most important part of any rule project application development. The vocabulary is indeed the set of terms and phrases defined in all the BOM entries of a business object model. You can define a vocabulary for a complete BOM entry using the Verbalize BOM wizard. Every read-only/read-write attribute (a field with getters and/or setters) is a vocabulary of the created business language for business users who can write their business policies without IT engagement. Phrases correspond to methods in the BOM. You can edit the verbalization of phrases, too. There could be several navigation or action phrases for a BOM element, so that rule authors can use different wordings while using the same method or attribute. Constants correspond to static references in the BOM (just to remind you that you verbalize XOM to create a BOM for your business users). You can edit the verbalization of constants. By default, a ruleset parameter is verbalized as its name. It’s important to document the vocabulary thoroughly that’s later displayed in the information box next to the Content Assist box that appears when you edit business rules.
You may create BOM without XOM, but at some point the mapping between BOM and XOM has to make its way. If there’re some discrepancies between XOM and BOM, you can sort them out with the BOM Editor in the B2X mapping section. That’s where you establish a virtual business vocabulary being mapped to real data from existing XOM. XOM and BOM can be quite different from their structure’s point of view yet work together via B2X mapping.
You can extend the Business Object Model (BOM) with new domains (= series of acceptable values) – a bounded domain, a collection, an enumeration of literals, an enumeration of static references, any other type of domain.
You can map business elements to execution elements in the XOM by associating an IRL function body (IRL mapping) to the business element. You can also map business elements to execution elements in the XOM by associating an extender class (extender mapping) to the business element.
Just to let you remember the most important parts of the rule development process – XOM is a set of execution elements and BOM is a set of business elements. It may remind you Object-Relational Mapping (ORM), where XOM is a (relational) database and BOM is a entity model. If you know one of them, you know both.
With the XOM and BOM ready, you’re set to create a rule…stay tuned for more to come. It’s been quite an extensive endeavor and hence you owe yourself some mental rest 🙂 BRB
p.s. You wish a screencast would explain it better? Just let me know in the comments below. I’d appreciate your feedback.