From Traditional Integration to Composition – Enterprise Business Services - Applied SOA Patterns on the Oracle Platform - page 263

Task Northbound Southbound

transformation Proxy where we will perform dy-
namic transformation.

The realization of Adapter Factory was discussed
earlier. It will dynamically dispatch a message to a
concrete protocol Adapter Proxy, similar to what we
had in Message Broker.

Deliver mes-
sage

This passes well-formed messages to the SCA or southbound SB part.

At this moment, we assume that all our OSB operations will be based on SOAP. The technology of creating a JCA adapter in
Oracle 11 g is practically the same as in the previous 10 g release. Traditionally, we have to create an empty SCA in
JDeveloper, drag the required adapter (DB, File, FTP, and so on), and set all the necessary properties related to the adapter's
type (pay special attention to JNDI name). We will use the previously created .jca , .wsdl , and .xsd files in Eclipse to
generate the OSB services, representing JCA transport. Thus, we will call these adapters transport adapters . They will be
actively used by both Northbound and Southbound parts of our agnostic controller. However, we assume that the Southbound
layer will employ them directly, when Northbound will require a generic reader to dispatch to the different kind of control-
lers.

Adapters

It is also important to bear in mind that the JCA-compliant resources are hosted not on OSB, but one level down—on WLS
as a public resource. On OSB, we create only Proxy/Business services that interact with a supported adapter. That's the
beauty of decoupling!

We will discuss the OSB Adapter framework in more detail in the following chapters.

Short summary

Let's summarize what we learned. The preceding table does not reveal any contradicting
functionality in the southbound and northbound OSB realization of the synchronous com-
position controller; therefore, we can build unified versions that are suitable to handle all
In and Out service collaboration scenarios. We will just have to add conditional branches
in our inbound and outbound pipelines to enable/disable certain operations, depending on
the process context that is provided by a recognized execution plan. Let's not forget that
not every service collaboration scenario should be handled by an Agnostic Composition
Controller, only those that really require implementation of the SOA ESB patterns in a
business agnostic way (and dynamic invocation is a prerequisite). Please refer to the busi-
ness requirements formalized in the previous chapter.

Apart from the Proxy-based service governance patterns discussed previously, we are con-
stantly referring to the service messaging and transformation patterns in the SOA patterns
catalog that is assembled under the ESB compound pattern as three compulsory patterns:
Asynchronous Queuing, Intermediate Routing, and Service Broker suitable for Agnostic
Composition Controller scenarios will fall into these patterns, but we need more detailed
descriptions for each of them, linking the generic SOA patterns with the VETRO tasks
identified in the preceding table. Really, Intermediate Routing sounds too generic.