The infrastructure property settings are properties that apply to all composites running on the SOA infrastructure. Configuring these properties ensures that you have some sort of global setting applied to your environment. You can configure them from by navigating to Administration | System MBean Browser | Application Defined MBeans | oracle.as.soainfra.config. Infrastructure properties can be altered at runtime by entering a value in the Value text box for the read-write MBeans, as shown in Figure 7.4. There is an option to even validate your modifications by invoking the validate function from the Operations tab. Key infrastructure properties that can be configured from MBeans include:
- Infrastructure profiles
- Lazy loading and lazy deployment parameters
- Tuning thread pool changes
- Global logging levels, audit, and cache configuration
- Callback server endpoint and dehydration data source JNDI
- JMS or database-based mode for Event Delivery Network (EDN) framework
- Global transactions and fatal connection retry settings
- Universal schema validation
- UDDI registry and HTTP server connections
- Infrastructure keystore locations
- Search criteria for the retrieval of recent instances and faults
Take a look at the following screenshot:
Figure 7.4: Configuring SOA Infrastructure Properties
Apart from configuring the System MBeans from a web browser, their configuration override can also be scripted with the help of WebLogic Scripting Tool (WLST). This is helpful when you are in charge of managing multiple SOA infrastructures and want similar configurations applied across them all by executing a handful of scripts. These WLST scripts can be executed from the WLS offline prompt (wls:/offline>) by running wlst.sh (or wlst.cmd in Windows) under $MW_HOME/wlserver/common/bin. Configuration properties for the SOA infrastructure are available as part of a custom tree. The following WLST script connects with a running SOA server, enters its custom tree, and changes the existing directory to oracle.as.soainfra.config. You can view all MBeans under this by executing the ls() command. The common infrastructure properties can be changed by simple set([propertyName],[propertyValue]) statements, as shown in the following command snippet:
connect('<username>','<password>','<soahost>:<soaport>')
custom()
cd('oracle.as.soainfra.config/oracle.as.soainfra.config:name=soa-infra,type=SoaInfraConfig,Application=soa-infra')
ls()
set('ValidateSchema',true)
exit()Configuring and managing the infrastructure properties is just the beginning of a long journey.
Oracle SOA Suite 12c is comprised of different engines and numerous deployment components. As such, the memory utilization can be a problem. Some current challenges with memory utilization with Oracle SOA Suite are:
- Multi-functional capabilities of a middleware platform mean packaging multiple engines together.
- Not all engines are always needed, thereby taking up memory that can be used elsewhere.
- Expanding business means adding more composites and integration points.
- Additional composites add additional resources, adding to server startup times.
With Oracle SOA Suite 12c, administrators now have the choice of a number of configuration profiles which control the available functionality, modularity, and consequently, resource consumption. Modularity profiles allow for enabling only necessary components, optimizing memory. These profiles can be configured post installation through Fusion Middleware Control. Currently, there are seven different types of modularity profiles available in Oracle SOA Suite 12c. For example, the lightest is probably BPEL Only, which is BPEL, core SOA infra, and a partial set of adapters; SOA FOUNDATION ENTERPRISE is pretty much everything excluding B2B, Healthcare, and BPM; and SOA CLASSIC is everything, that is, including BPM.
To give a comparative analysis there is a 30 percent memory usage difference between BPEL Only and SOA CLASSIC profiles.
Infrastructure profiles can be viewed and modified from Oracle Enterprise Manager Fusion Middleware Control. Navigate to see the currently set profile as follows:
- Log in to Oracle Enterprise Manager Fusion Middleware Control.
- Right-click on soa-infra and navigate to SOA Administration | Common Properties.
- Under SOA Infrastructure Common Properties the currently set profile is visible.
- To set a different profile, use the Change Profile button.
- Note that changing profiles require, a server restart to take effect.
As an Oracle SOA Suite administrator, you will realize that starting a SOA managed server is very slow. Often, the server startup logs indicate that the SOA server is up and ready to receive requests but composites are still not ready to accept requests and messages are rejected, causing end applications to error out. Beginning with the 12c release, this behavior can be somewhat controlled. Lazy loading prevents this problem by ensuring composites are ready to receive messages as soon as the SOA server is up. It loads composites minimally, thus improving the availability of the SOA servers. Lazy loading is turned on by default for the domain but can be turned off for composites that have high SLA expectations to avoid delay in processing the first message. Oracle estimates that lazy loading can start the SOA managed server give times faster when loading hundreds of composites.
To modify the lazy loading parameters, follow these instructions:
- Log in to Oracle Enterprise Manager Fusion Middleware Control.
- Right-click on soa-infra and navigate to Administration | System MBean Browser.
- In the system MBean browser, expand Application Defined MBeans | oracle.as.soainfra.config | [soa_server] | SOAInfraConfig | soa-infra.
- The CompositeLazyDeployment and CompositeLazyLoading properties can be changed to set or unset lazy loading of composites during either deployment or server startup, respectively (as shown in the Figure 7.5).
Figure 7.5: Configuring composite lazy loading
Though lazy loading is on by default at the domain level, it is not enabled by default for upgraded domains. It is recommended to always enable lazy loading. Despite the composites being loaded minimally, there are no concerns with their behavior. Inbound adapters still listen for messages and inbound web services can be invoked. Generally the first instantiations are a little slower as the composite artifacts are fully loaded. Lazy loading can also be controlled at the composite level, but this is done at design time by updating composite.xml.
Oracle SOA Suite 12c has redefined the model for thread pool management. In 11g, individual engines such as BPEL, BPMN, and Mediator had their respective thread pools that could be configured using the Fusion Middleware Control console. Dispatcher, invoke, and engine threads needed tuning adjustment relative to the infrastructure. Also there were no thread settings to control the number of incoming requests as they were handled by standard WebLogic execution threads. Beginning with 12c, custom thread pools have been abolished and replaced with standard WebLogic Work Managers. This allows the thread pools to be managed and monitored in a much more consistent and standard manner. A few benefits of using work managers instead of engine threads are listed here:
- Tuning for service engines is simplified as there are no individual thread based configurations.
- The self-tuning model of work managers means optimal distribution of threads across all the components based on utility and peak periods.
There are three more important changes in addition to these:
- Addition of a new Work Manager for incoming requests to that they can be limited to prevent server overload.
- Thread Constraints in the Work Managers are matched to the total number of connection pool objects on the
SOADataSource. This minimizes the risk of threads running out of database connections. - The self-tuning model of work managers means optimal distribution of threads across all the components based on utility and peak periods.
The Oracle SOA Suite 12c infrastructure now has a large number of work managers, thread constraints, and request classes with appropriate prefixes. The default configuration has each Work Manager configured to use its corresponding minimum and maximum thread constraints. For instance, SOA_Request_WM uses the SOAIncomingRequests_maxThreads constraint for handling incoming web service requests.
Note
Oracle SOA Suite 12c also allows administrators to create their own Work Manager groups. Each Work Manager is associated with its own min/max thread constraints and fair share request class. A partition in Oracle SOA Suite 12c has to be associated with a Work Manager group. All composites deployed to a partition thus have a share of the threads and resources defined for the associated Work Manager group.
Also, by default the SOADataSource is set to a maximum of 50 connections. Of these, 20 percent are allocated to incoming requests, 50 percent to internal processing, and 30 percent to internal buffer. By default calculations, this would result in SOAIncomingRequests_maxThreads being set to 10 threads and SOAInternalProcessing_maxThreads set to 25 threads.
Thread pool tuning is as such simplified. To change the number of threads allocated to a work manager, change the number of data source connection pool objects and/or the thread appropriation ratio. The latter can be configured from Fusion Middleware Control via the Common Properties MBeans as follows (see Figure 7.6):
- Log in to Oracle Enterprise Manager Fusion Middleware Control.
- Right-click on soa-infra and navigate to Administration | System MBean Browser.
- In the System MBean Browser, expand Application Defined MBeans | oracle.as.soainfra.config | [soa_server] | SOAInfraConfig | soa-infra.
- Click on SOAMaxThreadsConfig MBean. This will allow the thread appropriation to be set as percentages between internal, buffer, and incoming request processing threads.
Let's have a look at the following screenshot:
Figure 7.6: Middleware thread pool appropriation
When the middleware infrastructure detects errors due either to faults with synchronous messages or components throwing non-recoverable error and/or transaction problems, these errors are retried before being passed for error hospital-based recovery. By default, both the default retry count and retry interval set for the platform are set to small values. The attributes controlling the number and interval of retries the infrastructure will perform when an error is returned from the downstream service engine behavior are GlobalTxMaxRetry and GlobalTxRetryInterval. These values can be changed by updating their values from the Fusion Middleware Control console.
To modify GlobalTxMaxRetry and GlobalRxRetryInterval, follow these steps:
- Log in to Oracle Enterprise Manager Fusion Middleware Control.
- Right-click on soa-infra and navigate to Administration | System MBean Browser.
- In the System MBean Browser, expand Application Defined MBeans | oracle.as.soainfra.config | [soa_server] | SOAInfraConfig | soa-infra.
- The attribute values can be overridden from the form by entering them and clicking Apply.