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:
Figure 4.5: Partitions are displayed in the navigator in Fusion Middleware Control
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:
- Right-click on soa-infra and then click on Manage Partitions to access the Manage Partitions page.
- At this point, you can do one of the following four things:
- Click on the Create button to create a partition.
- Highlight an existing partition and click on the Delete button to delete the partition.
- Highlight an existing partition and click on the Composites Control button to start up, shut down, activate, or retire all SOA composites within that partition.
- Highlight an existing partition and click on the Deployment button to undeploy all SOA composites within this partition or to deploy a single composite to this partition.
The Manage Partitions page with each of its action buttons is shown in the following screenshot:
Figure 4.6: The Manage Partitions page
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.wsdlhttp://soahost1:8001/soa-infra/services/HumanResources/HelloWorld/HelloWorld.wsdl
There are some considerations regarding partition management that you should be aware of:
- Avoid creating partitions called Dev, Test, and Prod. Though possible, partitions are not to be separated by environment.
- Domain libraries and resource adapters (such as DB, MQ, and AQ) are shared by all partitions, so it is not possible to have different versions of these libraries or extensions for each partition.
- Partitions do not provide multi-tenant capabilities in Oracle SOA Suite 12c yet. As such, server JNDI names of resources, such as data sources, connection pools, JMS destinations, and so on, are shared by all composites deployed across different partitions.
- Oracle SOA Suite 12c configuration parameters such as timeouts, threads, and recovery configurations can only be defined at the WebLogic Server domain level, not by a partition.
- If composites that use inbound adapters (such as the inbound AQ Adapter, in which messages are automatically dequeued from an Oracle AQ) are deployed to multiple partitions, it is not guaranteed which composite will dequeue the inbound message (that is, they will compete with each other).
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:
- HTTP Read Timeout
- HTTP Connection Timeout
- JCA Retry Count
To update a runtime property for a composite, you can perform the following steps:
- On the navigator, expand SOA | soa-infra.
- Expand the partition (for example, default), choose from among the deployed SOA composites, and click on the composite name and the revision (for example, HelloWorld [1.0]).
- On the Dashboard tab, scroll down and locate Services and References.
- Click on one of the service or reference names.
- Click on the Properties tab.
- You will find a number of customizable properties, depending on whether you have clicked on a service or reference, and the type of service or reference.
When you create a partition, you must assign it to a Work Manager Group, as shown in the following screenshot:
Figure 4.7: Creating a SOA partition requires assigning it to a Work Manager Group list
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:
Figure 4.8: The Work Manager Groups page
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:
Figure 4.9: Work Managers in the WebLogic Server Administration Console
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):
Figure 4.10: Viewing the configuration of a WebLogic Server work manager
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:
Figure 4.11: Creating a Maximum Threads Constraint in the WebLogic Server Administration Console
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:
- On the navigator, expand SOA and right-click on soa-infra.
- Navigate to Security | Application Roles.
- Click on the search icon.
- For every partition that exists, you will find the following roles:
- [PartitionName]_Monitor
- [PartitionName]_Composer
- [PartitionName]_Tester
- [PartitionName]_Deployer
- [PartitionName]_ApplicationOperator
- Choose a role and click on Edit.
- Click on Add and search for a user to assign this role to.