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.
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.
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
Thank you, Its quite precise and helpful
ReplyDeleteYes next time dont just copy and paste the doc!!!
ReplyDeleteHi Albin,
ReplyDeleteCan you share some insight for Soap over http performance optimization when the client is deployed on Non-SOA server and the target is on SOA server. It would be of great help to understand the basics around it.
Thanks in advance.
Hi Albin,
ReplyDeleteWhat is the outcome if there is a SOA Cluster even when Java RMI calls may distribute the call within the cluster?
Regards,
Susmit