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

Traditionally, in a classic BPEL-based Adapter framework for SOAP services with XML
payload, XSLT transformation is the easiest choice. With visual mapping and a drag-and-
drop approach, you can achieve desirable results in minutes for simple cases. Regretfully,
complex cases would require manual coding, and from a performance standpoint, XSLT is
probably the slowest.
Naturally, complex coding in XSLT will make it impossible to be seen in Visual Designer.
One can argue that complex coding is hardly possible in XSLT and, anyway, the tempta-
tion to do Java Callouts will be incredibly strong. By the way, the JSON payload will re-
quire some manual coding anyway. Considering this, our architectural directions could be
as follows:
• Expose every individual's Search Services via the Adapter framework to the Ser-
vice Bus and aggregate service calls to different sources on OSB. Only one ser-
vice will be exposed to the customers; the result will be provided in the canonical
form (XML/JSON formats). The solution's modularity will be quite high, as every
source will be individually wrapped. Performance will not be at the best, as we
will have to do lots of serialization/deserialization and data model conversions.
The Adapter framework could be quite heavy.
• Still, only one service will be exposed, but instead of wrapping every individual
source into an adapter and assembly on OSB, we will do all object-to-object map-
ping behind the main service, presenting custom searches as separate EJBs or
POJOs. This approach could be suitable when performance requirements are
high, the number of individual sources are limited and/or static (due to business
agreements with external providers), and when aggregation logic is quite com-
plex; you will have to put it into a separate Java module anyway. You remember
the rule from Chapter 4 , From Traditional Integration to Composition - Enter-
prise Business Services , dedicated to Oracle Enterprise Service Bus—do not place
complex orchestration/service collaboration logic on OSB!
Actually, from a modularity prospective, both approaches are pretty much identic-
al. The second approach also can be quite modular with a proper Java classes
design. It also can be swift, as we will not leave Java premises and do all map-
pings on a low level. Spring 3 Object Mapping is a very good choice (see ht-
tp://static.springsource.org/spring/previews/mapping.html ) , but we have lots of
other libraries from Apache, such as Commons-Lang and Commons-Convert,
ModelMapper ( http://modelmapper.org/ ), and Dozer for JavaBeans. This list is
not complete. Therefore, with proper placing of the SOA patterns, the ABCS lay-
er still can be very thin and manageable.