Database Reference
In-Depth Information
Draw the Service contract (WSDL) as you see it, generate the code for the component,
and then build REST from this component, exposing the required operations using JAX-
RS (as one possible option). The second option would be to put the REST<->SOAP con-
version on the Adapter framework and OSB.
This solution also can be perfectly justified; for instance, the search of Video Asset can be
based on many search engines and API (both internal and external): the YouTube API,
IMDb, RottenTomatos, and your internal metadata store. You would need the adapter if
you will have to do the Transformation/Translation/Bridging. If all your APIs are REST-
ful and you can extract data elements according to your Video Asset EBO, you can do this
kind of aggregation on OSB. In the case of any transformation, consider the presence of
the Adapter framework. All core patterns for the Proxy service were discussed in Chapter
4 , From Traditional Integration to Composition - Enterprise Business Services .
Remember, this type of aggregation doesn't make this service task-orchestrated because it
remains totally business agnostic. It is also synchronous and we do not need any kind of
state deferral from the BPEL engine. Thus, placing this type to BPEL/SCA will definitely
be a mistake making the service slow and unreliable (more infrastructural elements that
necessarily do not improve reliability). In general, individual requestors are interfaces to
different search APIs and can be presented as separate EJBs/POJOs and then you can as-
semble them on OSB using the JEJB transport. The JEJB proxy service serves as a state-
less session bean to the EJB client interface.
The next logical outcome from the previous point would be the JSON/XML conversion
for the same type of Enterprise Business Message ( EBM ). Yes, this is not really a Pro-
tocol Bridging; it's a Data Format Transformation SOA pattern as we have different
formats to deal with. Again, transformation can be avoided if the Concurrent Contract
SOA pattern is observed at the early stages of service design. Indeed, that's quite common
(and prudent) to have services designed for XML/JSON messaging format support and in
case of REST services, such as http://ctu.com/services/v2013/fusion/ltv/json/Channels/
sort/LogicalNumber or http://ctu.com/services/v2013/fusion/ltv/xml/ Channels/sort/Logic-
alNumber .
We have plenty of libraries and frameworks to the marshal/unmarshal Object to XML/
JSON as mentioned earlier, and JAX-RS is one of the most powerful framework to do the
job; please see the following figure:
Search WWH ::




Custom Search