Database Reference
In-Depth Information
message context. Following this logic, we can assume that Composition Controller can re-
cursively act as a subcontroller for just another instance. That's it! Just by changing the
rules, we can change the sequence of the invocations and consequently implement new
processes on the fly. So simple, isn't it? Who would think about it? Here, we can conclude
the chapter and probably the entire topic.
Tip
Again, as you can see, suggestions are based on common sense; most certainly, these lo-
gical outcomes are not new to you. We now see our task as a demonstration of Oracle
SOA Suite's capabilities to implement the suggested outcomes.
Talking about it seriously though, dynamic Composition Controllers are not new at all,
and we have all coded and implemented them many times. However, here we are going to
choose examples that are specific to Orchestration, where we have two distinct properties:
processes should be long running and asynchronous and the controller must be truly ag-
nostic for dynamically brokering other service members. Therefore, the problems we are
facing are obvious too:
• There is no problem in abstracting the rules, centralizing them, and accessing
them dynamically. What we must remember is that these rules could evolve while
the process is running for days and weeks. Thus, rule versioning must be handled
seamlessly by Composition Controller together with Rule Engine. A single pro-
cess cannot start using one ruleset and finish with another.
• The process can fail for many reasons. With a static non-agnostic controller, you
can set precise compensations and error handler(s), anticipating concrete faults.
An agnostic controller alone has no idea about what to do in error situations,
which means that you will again need to employ Rule Engine in order to com-
pensate for the error.
• A compensation itself is rather specific as we cannot always apply generic com-
pensation flow(s) in a generic controller. We should also be careful in propagating
the error to the upper level (initiator or master-controller) for many reasons.
• Actually, abstraction and centralization of the rule is the problem as we technic-
ally present a single point of failure, and the infrastructure must provide a redund-
ant solution for this.
• While abstracting the controller itself, we must not forget that these types of con-
trollers are more suitable for synchronous and fast-running compositions. Long-
running compositions will require persisting the process state, and agnostic con-
trollers are not the best candidates for this. Actually, BPEL was invented to solve
this problem, presenting a task-orchestration service as a non-agnostic Composi-
Search WWH ::
Custom Search