BO-scoped workflow/EAI (and service), and BO-scoped rule engine

BO-scoped workflow/EAI (and service), and BO-scoped rule engine

A. BO scoped workflow, service, and EAI.

(i) workflow/task: you can always call workflow as a service -- workflow is executed within a service (the workflow engine). In other words, service is the underlining mechanism. If a scope is not enough, then, you can create another subworkflow.

(ii) service: you need service, because service can handle transaction, workflows cannot. BO can have a default scope of transaction. Just a note here, the Siebel server has some internal component. If you need to use it directly from client, then, you need to use "server request broker" -- a service interface.

(iii) EAI: service needs scripting, and we prefer declarative programming (to avoid clicking, we must learn to hack sif/xml exports), so, we want to avoid service per se. Also, service cannot use objects as parameters. So, we use EAI that can handle both transactions and object parameters.

B. BO-scoped rule engine

I used rule engine before, in a large project in java. We experimented it in many ways, and finally we concluded that it is not as powerful as it sounds. Inferences are not really that useful, for two reasons: (i) machine performance: we cannot load all the rules and (more importantly) and all those objects needed for those those rules in memory! (ii) human accountability: when something is not right, we cannot say that it is AI -- we are accountable! Basically this means we do not want it to be that powerful! We want predictability! -- As a result, perhaps M$'s no-inference rule engine approach is correct! Wait a minute, perhaps M$ only sees the part of it -- the real thing about rule engine is that it eliminates the effect of the order of rules. This is very important, because by a strong inference engine, we do not need to worry about the order anymore; in other words, this means (i) we need to be careful to specify the rules in such a way that they are order-independent. (ii) the string inference engine can help us to do that.

Anyway, because of the concept of "scope", rules engine is just a glorified "(intra and inter-) entity validation/logic" mechanism -- yes, this is the reason that I have not blog rule engine per se that much -- it is already covered by entity validation/logic (note: rules can change values also, so, it is not just "validation" per se). Rules are grouped special kind of fine-grained AOP.

In Siebel, BO scoped can help the system to help us also, by providing smaller number of options. Note that currently, Siebel cannot provide help for lookup values. It should; I guess, it will be in next version.

C. Why BO is so important? As indicated in my previous blogs, BO is UnitOfWork. For web or SOA, it is the request (or conversation, if we relax it a little bit). It ties OR mapping, facade, valiation/entity logic, and UI-view all together. If you really push it, asking what exactly is it? I would answer it is OR mapping with a context of AOP (coarse-grained facade and fine-grained entity).