SOA Ecosystem–Interconnected Principles, Patterns, and Frameworks - Applied SOA Patterns on the Oracle Platform - page 61

between. No transformation is required as all data models are CDM-compliant, and a uni-
fied protocol eliminates the necessity of the bridging protocol.
The first real wake-up call would come from the realization that not all our APIs really are
parts of the canonical Federated Endpoint Layer (as explained in Chapter 6 , Finding the
Compromise - the Adapter Framework ). The Assumption 2 item mentioned in the previ-
ous bullet list is quite often too optimistic in real life; this means that:
• Data model transformation and data format transformation (translation) could be
needed.
• There could be no APIs at all. Even worse, data required for a new composite ser-
vice will be pulled from various sources, sometimes with multiple data cleansing
and filtering routines extended over a period of time.
• Complex transformations will be performed to maintain the initially declared data
granularity on service composition, such as aggregation or debatching.
• Messaging and/or transport protocols are not canonical, and this disparity must be
harmonized.
The Application Business Connector Services framework
Following the principle of separation of concerns, we must preserve our Business Service
Composition's hypothetical area that is free from all disparities; this is suitable only for
fast and clean compositions. Thus, the implementation of Application Business Connector
Services is compulsory. This is the first concrete framework in the list of SOA frame-
works we are going to discuss. The sole purpose of this framework is to compensate for
the lack of the service(s) to present a standardized contract, suitable for repeatable reuse
and utilization. Services residing in this framework are special forms of wrappers, de-
signed to receive/extract, translate, transform, filter, validate, and propagate (route) further
information required for business compositions, that is, implement the VETRO pattern
( http://www.oracle.com/technetwork/articles/soa/jellema-esb-pattern-1385306.html ) . You
can see the required functionalities, implementation techniques, and service models for
this framework in the following list of requirements:
• Implementation technique:
◦ Synchronous implementation for simple MEPs
◦ Asynchronous transaction coordinator for adapters (data-collectors),
handling long-running data aggregation transactions
• Service models:
◦ Adapter services (Legacy Wrappers, File Gateways, FTP Hotels, and so
on) are utility services in general