Configuring Local Optimization in Oracle SOA Suite

Configuring Local Optimization in Oracle SOA Suite:

Local optimization is the process of one SOA composite application invoking another SOA composite application through direct Java invocations in an environment in which both composites are on the same SOA server (JVM).

Direct Java invocations are generally more efficient than SOAP over HTTP calls. Therefore, whenever the conditions are met for direct Java invocations, Oracle SOA Suite optimizes the service calls for the co-located composites.

In 10.1.x releases, we manually configured SOAP optimization with the optSoapShortcut property. For release 11g, SOAP optimization is automatically configured.

Condition Checks for Using Local Optimization:

Oracle SOA Suite performs the following condition checks to determine if local optimization is possible.

• It must be a composite-to-composite invocation. This is the most fundamental criteria that makes the direct Java calls possible when both the client and target services are implemented based on the same SOA Infrastructure (that is, the same SOA server).
• The composite implementing the reference (target) service must be active. This condition requires the target composite to be up and running, which in turn ensures that the reference service is available.
• The client and target composites must be co-located on the same server. This is an obvious requirement for direct Java invocations. It is also a critical step in which Oracle SOA Suite compares the server (on which the client composite is deployed) host configuration with the host and port values specified in the reference (target) service endpoint URI. If the host and port values match, it can be concluded that the client and target composites are located on the same server.
• However, the comparison is not necessarily straightforward given that working with both standalone and clustered server setups and potential load balancer configurations is necessary. Therefore, here are the step-by-step condition checks that determine the correct server configuration on all platforms:

•  Checks the Server URL configuration property value on the SOA Infrastructure Common Properties in em console. 

•  If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort if SSL is enabled) properties configured for the cluster in the weblogic console.

• If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort if SSL is enabled) property configured for the Server in weblogic console.

Servers ->Specific Server - >Protocols ->HTTP

• If not specified, uses the DNS-resolved Inet address of localhost.
• Checks if the port value specified in the reference service endpoint URL matches the configured server port value. If no port value is specified in the endpoint URL, Oracle SOA Suite assumes 80 for HTTP and 443 for HTTPS URLs.
• If the port values match, the server URL (that is, http(s)://host:port, where host and port are obtained from the checks mentioned above) is then compared to the server URL in the reference endpoint address. The URLs are resolved to canonical values and the comparison also takes into account the cases in which the endpoint URL host is localhost or 127.0.0.1.

• Oracle SOA Suite concludes that the composites are co-located if the server URL comparison returns a value of true. 

If the comparison is passed in the above steps then the composite will be invoked locally via java else it will be invoked via HTTP. 
We can confirm if a call went over local optimization in the Trace section of the Flow Trace page. The (Local Invocation) text for the reference and service of the invoking and invoked composites is displayed