Database Reference
In-Depth Information
Structuring composite deployments
with partitions
Prior to Oracle SOA Suite 11g PS2 (11.1.1.3), as hundreds of composites were
deployed to the SOA server, they were all listed in alphabetical order on the con-
sole, which made it a burden to manage and was not very structured. Oracle re-
cognized the lack of structure and, therefore, introduced the concept of partitions
to help better organize where to deploy your composites. However, partitions are
just logical separations to group your composites together. Domain libraries, ex-
tension modules, server
Java Naming and Directory Interface (JNDI)
, and in-
frastructure properties are shared across all partitions.
Partitions do not have their own configuration or logging. They serve no purpose
other than grouping composites into separate categories. Thus, for example,
code for your Human Resources integrations can reside in a partition separate
from your EBS integrations, offering better structuring 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 ex-
ample, all composites within a partition can be shut down with a single operation.
