Java Reference
In-Depth Information
Procedure Access Object
Problem
A customer of eInsure had a two-tier thick client lead management application. eInsure
had to integrate with this existing two-tier application. The lead management application
heavily used legacy stored procedures running on Oracle Database. The stored proce-
dures contained both business logic and persistence logic. It was not possible to reuse
the UI, which was built with Visual Basic. Because the integration had to be completed in
a short time period, it was not possible to port the business logic to Java components.
Moreover, eInsure was not allowed direct access to the database tables of the lead
management application.
The legacy version of eInsure had also left behind several stored procedures that
were accessed using straight JDBC. But as you saw with DAO, this involves a lot of code
redundancy. The mixing of persistence logic with business logic made the business tier a
regular candidate for change. The stored procedure can directly subscribe to the transac-
tional services provided by the RDBMS. This makes it difficult for the application server
to manage distributed transactions. This often leads to bugs that are hard to detect and
fix. Using stored procedures limits portability options. In other words, a lot of code
changes are required to support the same application on a different RDBMS.
Forces
• Accessing a stored procedure from a session facade using the JDBC API causes an
intermingling of persistence logic with application services.
• Invoking a stored procedure involves lots of low-level programming against the
JDBC API.
• Stored procedure access with a low-level JDBC API results in a lot of code
duplication.
• Stored procedures make it difficult to apply system services such as transactions.
Solution
Use a
procedure access object
(PAO) to invoke stored procedures without directly interact-
ing with a low-level JDBC API.
