Databases Reference
In-Depth Information
Peer-to-peer topology
With this topology, we are allowing composite applications deployed on the same
Service Infrastructure to communicate directly with each other, without the need to
go via the Service Bus. In this scenario, we would need to implement the external
virtual services layer using a
Mediator
.
With this approach, all invocations happen over the service infrastructure, which has
a number of advantages, including the following:
•
•
•
All invocations are optimized, resulting in improved performance
Transactions can be propagated between composite applications
Complete audit trails across composite applications
The disadvantage of this approach is that without a well-defined governance
process, you can quickly lose the overall visibility and control of your architecture.
For example, how do you stop a developer from implementing a composite in one
application that bypasses the external virtual services layer of another application,
calling a business service directly?
Note, we may still need to implement a set of external virtual services in the OSB
layer, for the purpose of controlling the invocation of the composite by consumers
that aren't deployed directly on the service infrastructure, adding additional
complexity to our solution.
Hybrid approach
With this approach, the default is to follow the centralized approach and mandate
that communication between composite applications go via the Service Bus, but
direct composite application to composite application communication is allowed
under certain circumstances.
The key to this approach is that the default is to use the centralized approach,
but provide a mechanism through your governance process for peer-to-peer
communication where there is a justified reason, for example, improved performance.
