Databases Reference
In-Depth Information
Composite application
As we have already mentioned, a composite application is made up of a number of
composites, with each composite providing a service that could potentially sit in any
layers of our architecture.
A composite itself is made up of one or more types of components (for example,
BPEL process, Mediator, Human Task). Each of these components has an affinity to
various layers within our architecture. The following is a
guide
to which components
can be used where:
•
Application services layer
: This layer is pretty straightforward in that if
the application doesn't provide inbuilt support for web services, it is the
case of using the appropriate Service Adapter to hook into the underlying
application.
Virtual services layer
: Within a
composite
, a Mediator should be your
default starting point for this layer, as it has been designed to address the
specific challenges tackled by this layer of our architecture.
Business services layer
: BPEL is typically used for task-based services, as
it provides a rich language for building composite services, with Human
Workflow being used for manual tasks.
Business Rules provide an excellent tool for implementing functional
services, as well as the validation within task-based services.
For entity services, we can use ADF business components. While it is not part
of the SOA Suite, it is tightly integrated within the 11
g
service infrastructure.
Business Processes Layer
: This layer, as you've no doubt already realized,
is the natural domain for BPEL. However, Business Rules also play an
important role in allowing you to externalize the logic behind decision
points within your process.
•
•
•
Business Activity Monitoring is then used to instrument your composite and
any other relevant services, in order to provide you with a holistic view across
your application.
Composite granularity
A key consideration when designing a composite application is the appropriate level
of granularity when partitioning it into multiple composites.
For example, it is quite feasible to build a single composite that spans all layers of our
architecture (excluding the service consumer layer). While this may work, the issue
that we have is that we would need to modify and re-deploy the whole composite
whenever a change occurs at any level within our composite.
