Database Reference
In-Depth Information
the moment). We are just happy to confirm that the Oracle, Apache Camel and
JBoss Fuse teams share the same SOA vision.
Finally, what we haven't done (neither should you) with your OSB agnostic controller:
• The OSB Service Broker is much closer to the Message Broker we discussed than
to Orchestration (that's why we discussed the Message Broker, actually). It's still
a good old RTD interchange pattern. Do not implement any business logic here!
Do not orchestrate in ESB, only decouple, transform, and route.
• The logical continuation of the preceding point is that if you think that you can do
the callout to a Java function from the OSB performing a business logic—don't!
Count how many SOA principles you will break.
• Do not use your OSB Proxy Service for the patterns different from what we dis-
cussed. If it looks like implanting business logic into Proxy—stop here. Imple-
ment atomic service
and
then present it via OSB.
• It's a very thin line between the Split-Join pattern and batch processing in ESB.
Although it's quite possible to do some batch processing between the two DBs
(your DBA is prohibited from using DBLinks and, for some reason, believes that
SQL*Loader is for dinosaurs), try to avoid that design. Use the Oracle ODI
product, if you can.
• As deduced from all the preceding points—OSB can act as an adapter layer, but
still Oracle recommends BPEL for this purpose. Think about it.
There are plenty of common components that are utilized by both Service Brokers, syn-
chronous and asynchronous. In EBF and EBS frameworks, we share common Audit, Log-
ging, and ErrorHandling services. However, most importantly, we use the same execution
plan (scontroller's routing slip). This configuration entity and part of the generic message
container is based on the service metadata that is maintained on Enterprise Service Repos-
itory. This core framework is the subject of our next chapter.
Search WWH ::
Custom Search