Oracle Mediator Request Flow

5-38 Oracle Fusion Middleware High Availability Guide Mediator engine is initiated by the SOA Service Infrastructure and involves sending signals to in-flight instances and unloading of loaded components. Figure 5–24 illustrates Oracle Mediator Startup lifecyle. Figure 5–24 Oracle Mediator Startup Lifecyle

5.5.1.3 Oracle Mediator Request Flow

The recovery semantics of Oracle Mediator after a server failure are based on client interaction type and routing rule type. Oracle Mediator provides support for synchronous and asynchronous request-response interactions. The following describes the behavior based on interaction type: ■ Synchronous Interaction: For synchronous interactions, an error is thrown back to the client in the case of a server failure. It is the clients responsibility to handle the error message and take appropriate action such as retrying the request. ■ Asynchronous Interaction: There are two types of asynchronous invocations - one that starts a new routing rule execution and one that is a callback to an existing rule execution. In the case of a callback, the engine attempts to resolve the subscribing instance through a correlation id. If there is a failure in handling the callback, the client receives an error message and has to handle the error appropriately. The client invocation must be transactional in order to guarantee reliable handling of a callback in the case of a server failure. Oracle Mediator can route messages either sequentially or in parallel. Only messages processed in parallel need manual recovery in the case of a server failure. The following describes the behavior based on routing rule type: ■ Sequential Routing Rule: For sequential routing rule, complete rule is executed in a single transaction. In the case of server failure, Oracle Mediator relies on the underlying transaction manager for recovery. ■ Parallel Routing Rule: For parallel routing rule, Oracle Mediator uses a store-and-forward paradigm that involves two separate transactions - one transaction for persisting the message and a second one for executing the routing rule. If there is a failure prior to the persistence, the client receives an error message and has to handle the error in the same way as in a sequential routing rule. If the persistence is successful, the client call returns and further processing is done outside the context of the client call. In the case of a server failure, Oracle Mediator will initiate recovery upon server restart after a configurable time interval specified by ContainerIdLeaseRefresh

5.5.1.4 Oracle Mediator Configuration Artifacts