Finding the Compromise – the Adapter Framework - Applied SOA Patterns on the Oracle Platform - page 388

on) is also simple. The execution of rule functions is based on NDS and implementation
of the dynamic facilitator is exceedingly simple; see the following code snippet:
PROCEDURE dynstatexec (
statement IN VARCHAR2,
nargs_in IN NUMBER := 0,
arg1_in IN VARCHAR2 := NULL,
…
arg9_in IN VARCHAR2 := NULL,
v_result OUT VARCHAR2
...
IF nargs_in = 0
THEN
EXECUTE IMMEDIATE statement || '; END;';
ELSIF nargs_in = 1
THEN
EXECUTE IMMEDIATE statement || '(:1, :2,); END;'
USING arg1_in, OUT v_result;
ELSIF nargs_in = 2
THEN
…...
You can build it for any number of inbound parameters and for any type of returning
value. This approach is highly universal, lightweight, and can be used everywhere, espe-
cially combined with a DB schema for service artifacts from the previous chapter: the
statement is an executable module registered as a task (service) and linked as a rule in the
ruleset, associated with the event/object. If you prefer a more standard approach (and
heavy) based on Oracle tools, please proceed with a similar implementation using Oracle
BRE API for Java and implement PL/SQL wrappers for it. In this case, you will use the
standard rule repository. We believe that the approach presented earlier is a bit more suit-
able for implementation within OEBS.
One more thing to mention: after execution of business rules, we will have a list of Trad-
ing Partners (or none, if nobody subscribed to this event), and a list of messages we have
to produce (we agreed that it will be only one Canonical per Entity, but still we have the
capability to construct different messages). We can fire execution right away, or we can
record discovered information back to the Process Log table. Another process (via Sched-
uler) will start actual construction. This two-step processing will increase decoupling even