Databases Reference
In-Depth Information
The other extreme would be to deploy every component as a standalone composite
in its own right. This is similar to what we had to do in 10gR3. However, this will
lead to an overly fragmented solution, which will be more complex to test, integrate,
deploy, and maintain. So the key question is what is the right level of granularity
of a composite?
When identifying services, we typically advocate a top-down process-driven
approach, which will help us to identify our
core
business processes and services,
for which we can define our service contract (as covered in the next chapter add).
We use this as our starting point for our level of granularity, with each
business process or service being implemented as a single composite
(using the appropriate components).
Once we start to design a composite, we will typically identify other business
processes or services that are required by the composite. At this point, we need
to decide whether the child service needs to be split out as a separate service, and
therefore be implemented as a composite in its own right.
Key considerations when making this decision are reusability, lifecycle, and
operational management of the composite.
Performance isn't really a consideration, assuming all composites are
deployed on the same service infrastructure, as there is no real difference
in the overhead of invoking a component within the same composite as
opposed to invoking it with a separate composite.
From an audit and tractability perspective, there is little difference, since
Enterprise Manager is sophisticated enough to join audit trails across
components that span multiple composites.
Composite reusability
The first consideration is whether the child service needs to be reused by other
composites (independently of the parent composite), either now or in the future.
If the answer is yes, then typically we want to split it out as a separate composite.
This isn't always as obvious as it may seem, as it is quite easy to take the approach
that every component could potentially be a reusable service and end up with all the
issues of an overly-fragmented solution.
The other consideration is that although it is technically simple enough to deploy a
child service as its own composite, the reality is that contextually it is coupled
to the parent service, that is, it is designed based on the requirements of the
parent composite.
