The ADF framework strongly suggests if not dictates a certain application architecture. Through ADF BC (Business Components) – the predominant business service implementation with ADF – applications will typically interact directly with the database, over JDBC Database Connections from a shared connection pool. Developers who create the ADF BC Entity Objects and View Objects will be quite aware of the data model and the database implementation. They will usually write SQL. And the result of their work is substantially coupled with the database. Transactions across multiple data source are very hard to implement in that typical ADF BC scenario because ADF BC talks to a single database and typically controls its own transaction.

When ADF applications are developed in an environment where an enterprise architecture has been laid down, and decoupling is an important objective and service orientation is mandated – then this typical implementation of the business service using ADF BC connecting directly to the database may not be desirable or even allowed.

On one of my projects, we are currently in the situation where we try to determine the guidelines for the implementation of the More >