What you describe sounds to me like the good old principle of coding to an interface and not an implementation. It is used to build good technical frameworks and it applies just the same to build a “business framework” i.e. a toolkit of services you can reuse to build a process.
Your comment also reminds me that I believe Jrules could be a nice candidate for the orchestration layer of an SOA. Your point about the BOM confirms it.

Thanks for your interesting post. I hope you won’t mind if I add to your post some (long) reflections I had about the BOM entity while reading your entry:

Unlike traditional Orchestration tools (Biztalk, Tibco’s BusinessWorks and other BPEL-like tools) which normally and unfortunately interact directly with small-grained APIs (sometimes wrapped as Web Services), I was delighted to find this BOM layer in your description of the Jrules architecture (even though it requires extra development time and the ROI is not clear in the 1st place).

This BOM, reflecting a Business Entity, is something which is entirely missing from 99.99% of all SOA architecture blueprints. Yet, this Business Entity layer is crucial, as it provides:

- The foundation for coarse-grained business services.
As you well explained, Business users, who are using business language, expect to define rules on business entities; and quoting from the reference you mentioned: “Business rules arise from the objects that one encounters in a business and their interrelationships”. Business users [and I claim that programmers just as well] are not supposed to interact with APIs -even if wrapped as web services 

- The foundation for Information Caching. This architectural element inside a BOM (not that BOM has it, but it is a reasonable placeholder for it) allows “always-on” business-objects for read purposes, as well as for ultra fast response time. Without BOM, the rule [or the business process] has to interact with [potentially] many underlying APIs, each of which having a different level of availability, reliability and response-time. Using information caching inside a BOM is a tremendous advantage of the BOM entities.

Regarding the alternatives for building the rule/process, i.e. a rule engine, an orchestration layer or a scripting language like python and ruby: there are obviously good reasons for using each of these depending on the Enterprise/Project context. But the most important thing, imho, is to always go through the intermediary of the BOM and not interacting directly with the distributed APIs of the underlying applications.

Have a nice week,
muli