Database Reference
In-Depth Information
Grouping
SOA
composite
applications
into
partitions
Typically developers choose a partition to which a particular composite should
be deployed, but as an administrator, you must understand its implications.
When composites are deployed—whether through JDeveloper, the console, or
ant—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 Hu-
manResources partition as shown here:
http://soahost1:8001/soa-infra/services/default/HelloWorld/HelloWorld.wsdl
http://soahost1:8001/soa-infra/services/HumanResources/HelloWorld/Hel-
loWorld.wsdl
Considerations for partition management
There are some considerations regarding partitions that you should be aware of:
Avoid creating partitions called Dev, Test, and Prod. Though possible, parti-
tions are not designed to separate by environment.
Domain libraries and SOA extensions (such as MQs and AQs) are shared by
all partitions, so it is not possible to have different versions of these libraries
or extensions for each partition.
It is not possible to have the same JNDI address for outbound connection
pools in Resource Adapters pointing to different queue manager or data
sources for composites deployed in different partitions.
Oracle SOA Suite 11g parameters such as timeouts, threads, and recovery
configurations are defined by WebLogic Server domain, not by 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).
Search WWH ::




Custom Search