Databases Reference
In-Depth Information
An alternative would be to connect to an external system via an adapter
deployed to the Oracle Service Bus (as opposed to the Service Infrastructure
in the previous scenario).
This would be the approach when integrating with an enterprise application such
as Oracle E-Business Suite, Siebel, or SAP, since these are likely to be invoked from
composite applications and thus need to be considered as a composite apps in their
own right.
Service invocation between composite applications
The boundaries between where one composite application finishes and another
begins is not always clear. Take the previous scenario; we could be using the
database adapter to connect to a custom application that we may need to include
within multiple composite applications (say Application A and Application B).
In this scenario, we could say that the virtual services we have exposed are part of
composite Application A or composite Application B or a composite application
in its own right. With any of these outcomes, we have the issue of how we want
to handle inter-composite application communication, when deployed on the same
Service Infrastructure.
In this scenario, we have three basic approaches:
•
•
•
Centralized topology(that is, go via the Service Bus)
Peer-to-peer topology(that is, go direct via the service infrastructure)
Hybrid approach
Centralized approach
With this approach, whenever a composite application needs to invoke a service
provided by another composite application, it would do so via an external virtual
service implemented as a proxy service on the Service Bus.
This is essentially the model that we have advocated from the start, as it allows us to
completely de-couple our service consumer from our service provider. In addition to
the advantages we covered earlier, mandating that all external services are accessed
via the OSB gives us a number of other benefits.
From a service development lifecycle perspective, having this very clear line of
delineation between composite apps makes it simpler to communicate and enforce
our overall SOA Architecture, thus simplifying our governance requirements.
From an operational perspective, it allows us to use the Oracle Service Bus as a
centralized point of control for managing, monitoring, and securing our services.
