Finding the Compromise – the Adapter Framework - Applied SOA Patterns on the Oracle Platform - page 361

Optimizing the Adapter Framework
The best adapter is the one you do not have to implement. The end. Ah, if only we could
get rid of them so easily. Requirements for an adapter within a domain usually signify that
something in your service inventory went wrong and you overlooked the discrepancies in
your data models, formats, and/or messaging/transport protocols. Regarding protocols, you
could actually anticipate that a single protocol would not be enough and the Dual Protocol
SOA Pattern ( http://soapatterns.org/design_patterns/dual_protocols ) can be justified in the
cases explained next.
Your service activities on both the north and south sides are the canonical SOAP over
HTTP, but between servers, handling every individual layer of your SOA frameworks
( ABCS<->EBS , EBS<->EBF , and EBS<->EBS ), you would like to have something
faster, without XML processing overhead. In this case, the RMI-type protocols could be the
optimal choice, such as iiop / iiops or t3 / t3s . While iiop is used by the a CORBA-
enabled Java clients and requires CORBA naming context, the t3 protocol is the internal
WebLogic protocol for Java-to-Java connections. In fact, this protocol from the very begin-
ning was the essence of Application Server's interoperability, even before it became We-
bLogic. This protocol is quite fast and supports all interoperability features such as Load
Balancing, including complex Load Balancing algorithms (Weight-Based, Random). For
this scenario, you can actually build services with contracts supporting only one canonical
SOAP over HTTP and let WLS handle the t3 protocol. Thanks to Oracle, most of the job
can be done through the configuration. The t3 protocol is a foundation for the SOA-Direct
protocol and SB-Transport protocol used in SOA Direct Binding, and the difference
between them is explained in the following figure: