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

You have both SOAP and non-SOAP clients, which prefer a plain HTTP protocol for sev-
eral reasons; one of those is external Load Balancers, where just HTTP is the best. Anoth-
er is the most obvious one—the service consumer prefers plain HTTP. Thus, you will
need to handle both the transport and messaging protocol, and you could do it on the ser-
vice's side, maintaining two contracts through the application of the Concurrent Contract
SOA Pattern: one for SOAP, where you consequently use JAXB (discussed earlier in
Chapter 2 , An Introduction to Oracle Fusion - a Solid Foundation for Service Inventory )
and SOAP wrapping for the object, and another where you just do the O/X Mapping
(again using JAXB or the Spring framework), and then the classic HTTP Post
routines—prepare request, set header parameters, open connection, make the post, read re-
sponse, and so on. What is important for us here is that we always have to anticipate these
requirements in our atomic service design and prepare placeholders for X/O Mappers and
basic inner adapters in the form of a Service Facade SOA Pattern.
This facade will sit between your contract and actual component representing service lo-
gic. In fact, that's what you get on applying REST/SOAP technologies from most mature
marshaling/unmarshaling frameworks (annotations in POJO, Spring, JiBX, and so on).
However, what if your service cannot support facade injections or if the variety of re-
quired protocols is a bit wider than two (out of the scope of the Dual Protocol pattern)?
Well, then a traditional way to handle this is to present the adapter layer in ABCS and