Database Reference
In-Depth Information
In addition to this, you have great flexibility for declaring <Properties> in the prop-
erty set within your policies in order to support your complex actions; please see the syn-
tax in the Oracle documentation.
Oh! the possibilities. They are truly boundless. Honestly, the OFM policy-based Excep-
tion Handling Framework is the second best thing in OFM after BPEL; this mechanism is
extremely powerful. You can employ any category of Faults (embedded, default, or de-
clared), assess (test) faults as you want, group them under any types (technical or func-
tional), create new or employ existing actions for resolutions, chain actions within any
fault, associate the actions returnValue parameter with any other following action
(another form of action chaining), declare property sets for your actions (highly useful for
Java Actions, but for others as well), and finally, centralize your policies using bindings.
Applied to Mediator as in the earlier example, which generally acts as a mini-ESB within
SCA; you will have an excellent realization of Policy Centralization. What else can you
wish for?
Please look closely at rules 6, 9, and especially 5 when it comes to Metadata Centraliza-
tion. Before building complex policies for agnostic controllers, you must be 110 percent
sure that all possible scenarios are accounted for, all composition members and their roles
are identified, and all appropriate resolutions are detected:
1. Even in static composition controllers, due to BPEL's easy-to-implement ways of
services' invocation, you could have long chaining of synchronous and asyn-
chronous task-orchestrated services. Some of them can have parallel flows,
spawning subsequent parallel flows; some sync BPELs can call async BPELs
comprising JMS adapters with triggered dehydrations causing callbacks in separ-
ate threads so that you lose your request-response correlations; third-party com-
ponents can propagate faults incorrectly; and so on and so forth. In dynamic com-
position controllers, without understanding the initial situation, your analysis will
be even worse. So, quite soon all your Policy Centralization will be centralized
around a single ora-human-intervention , as it is the only option to keep
control.
2. The simplicity of default fault actions can be deceptive. Regarding the preceding
point, we could have different use cases for seemingly identical throw-
versus-reply and reply-with-fault . Please see the Oracle documenta-
tion for more details.
3. The endless policy-based exception handling possibilities multiplied on endless
Java capabilities of the ora-java action can lead to disaster if applied uncon-
trollably. A Java guru can decide to put all the handling scenarios into Java ac-
Search WWH ::




Custom Search