This figure shows two farms, a production farm and a standby farm, each containing two middle tiers and an OracleAS Infrastructure. OracleAS Guard server is installed on each node along with OPMN. In this case, the OracleAS Guard client is installed on the node containing the production OracleAS Infrastructure.

This figure shows how an OracleAS Guard server is started. The OracleAS Guard client attempts to connect to an OracleAS Guard server [Step 1]. If this is unsuccessful, then the local OPMN server is contacted [Step 2] to start the local OracleAS Guard server for the instance [Step 3]. The OracleAS Guard client then connects to the OracleAS Guard server. For operations that require OracleAS Guard operations across the farm, the local OPMN server is contacted to start instances across the farm [Step 4]. OracleAS Guard servers communicate directly [Step 5]. The OracleAS Guard server will remain active until the client disconnects, or all operations are complete and the timeout value has been reached.

This figure also shows how OPMN and OracleAS Guard servers communicate. OPMN can communicate with other OPMN servers within a farm [fine black lines and arrows], whereas OracleAS Guard servers and clients communicate across the network [coarse black lines and arrows] based on the configured topology of the service. With DR, these operations require communication across both farms. In this case, OracleAS Guard must communicate across both farms and rely on OPMN services to start local OracleAS Guard servers. Thus on a given standby instance the OracleAS Guard server must be started directly using opmnctl. When started directly using opmnctl, a server will not timeout and will run indefinitely. This configuration allows cross-farm communication.