Partitions provide a mechanism to logically group your SOA composites. Thus, for example, the code for your Human Resources integrations can reside in a partition separate from your EBS integrations, offering better structure and organization. There are a few bulk lifecycle management tasks that can be performed on all SOA composite applications in a partition, as we will describe in this section. For example, all SOA composites within a partition can be shut down with a single operation. The following screenshot shows a list of partitions in the navigator under soa-infra:
Each partition may have one or more SOA composite applications deployed to it. Partitions in Oracle SOA Suite 12c also provide the ability to set up group-specific or user-specific permissions on each partition, including viewing, deployment, and administration. Partitions cannot be nested (that is, a partition cannot have a child partition). Partitions also do not have their own configuration or logging.
Domain libraries, extension modules, server Java Naming and Directory Interface (JNDI), and infrastructure properties are shared across all partitions.
Oracle SOA Suite 12c should have, at minimum, one partition. The default partition is created automatically when the product is installed, but it can be deleted afterwards if you choose to do so. You must always have at least one partition to which you can deploy SOA composites.
You can perform several management tasks pertaining to partitions. These tasks include:
The simplest method to manage partitions is via the Manage Partitions page. Simply navigate to this page to create, delete, or perform bulk lifecycle management operations on the partitions as follows:
The Manage Partitions page with each of its action buttons is shown in the following screenshot:
The Composites Control and Deployment buttons are only activated when a partition is highlighted.
Typically, developers choose which partition a particular composite should be deployed to, but as an administrator, you must understand its implications.
When SOA composites are deployed—whether through JDeveloper, the console, Ant, or WLST—a partition name must be specified. Code deployed to the default partition will result in a different WSDL URL than that deployed to, for example, the HumanResources
partition, as follows:
http://soahost1:8001/soa-infra/services/default/HelloWorld/HelloWorld.wsdl
http://soahost1:8001/soa-infra/services/HumanResources/HelloWorld/HelloWorld.wsdl
There are some considerations regarding partition management that you should be aware of:
Once SOA composites are deployed, certain properties can be updated at runtime without the need to redeploy them. All properties can be set at design time (through JDeveloper 12c) or at runtime (via Fusion Middleware Control).
Examples of runtime properties include:
To update a runtime property for a composite, you can perform the following steps:
When you create a partition, you must assign it to a Work Manager Group, as shown in the following screenshot:
Work Manager Groups are first created by right-clicking on soa-infra then clicking on Work Manager Groups (every new installation will have a default Work Manager Group). The following screenshot shows the two custom-created work managers—HighPriority and LowPriority. On the rightmost column, the partitions assigned to the Work Manager are shown:
You may modify the work manager of any partition at any time, but a server restart is required for it to take effect. When you create a Work Manager Group from Fusion Middleware Control, multiple work managers are created in Oracle WebLogic Server. These work managers are entities that represent logical thread pools. For example, after creating the Work Manager Group LowPriority and navigating to [Domain] | Environment | Work Managers in the WebLogic Server Administration Console, numerous work managers and constraints that are created are displayed, as shown in the following screenshot:
The priority of these work managers can be customized as needed. However, now it is enough to understand that Oracle WebLogic Server manages the thread pool on behalf of Oracle SOA Suite 12c. Multiple partitions can be assigned to a single Work Manager Group that is dedicated to processing background transactions. Certain aspects of Work Managers are further explained in Chapter 7, Configuration and Administration.
If you take a look at Figure 4.9 again, clicking on LowPriority_Adapters takes us to Figure 4.10. Here, it is shown in the following screenshot that the Maximum Threads Constraint type is not defined (in fact, it is defaulted to unlimited):
The Maximum Threads Constraint field limits the number of concurrent threads to the value indicated here. By clicking on New, you can create a new Maximum Threads Constraint and assign it a value either based on a count or data source. The following screenshot shows us how to set this value to 5
:
Thus, for the Work Manager Group LowPriority, the adapter's work manager defined in Oracle WebLogic Server was customized to a maximum concurrent value of 5 threads.
This fine-grained configuration provides the ability to significantly control the behavior of background processes of the code running in your SOA partitions. This is valuable in cases where certain composites that are deployed to specific partitions need to be given higher processing priority and/or concurrency over others.
There are some considerations surrounding the assigning of Work Group Managers to partitions, which are as follows:
Another new feature introduced by Oracle SOA Suite 12c is the ability to control access to SOA partitions. For example, a user logging in to Fusion Middleware Control will only be able to view the partitions and their underlying SOA composites that they have access to.
To restrict a partition to a particular user, the following steps are performed:
18.191.235.176