Future support for using PL/SQL core business logic with ADF BC

Question

We want to migrate our large Forms client/server (6i) application to ADF, possibly using a migration tool like Ciphersoft Exodus.
One scenario could be to use ADF BC and ADF-Faces or a different JSF-Implementation for presentation and business layer but keep our heavy PL/SQL-businesslogic inside the Oracle database in packages, triggers, functions and procedures.
This scenario could be chosen due to the huge amount of interconnected logic inside the database (10 years of development; no technical components; any package may access any table and more of this kind of dependencies). The business logic nowadays held in Forms client will be moved mainly into the database as a prerequisite to this scenario.
Choosing this "keep-logic-in-DB"-scenario we need a good support by ADF BC to do so. We know and prototyped that it is possible to call some PL/SQL via JDBC from ADF BC and it is possible to use stored procedure calls for standard business entity data access (ins, del, upd, ..). But this does not solve our problems. We want to reuse core business logic coded in PL/SQL. This is much more than change the ADF standard behavior for an update with an own PL/SQL-call.
Now my question:
Will there be a kind of sophisticated support to use ADF BC in combination with database-kept logic?
If so, when will this happen and how will the common problems of transactional state inside the database and inside the ADF BC be solved? Any plans or ideas yet?
Many other clients do have similar applications built in Forms and PL/SQL and would be glad to hear about a path of direction.
I've read the technical article 'understanding the ADF BC state management feature' which you have contributed to. One current limitation is pointed out there: Using PL/SQL with ADF BC limits ADF AM pooling to 'restricted level' which reduces scalability.
Are you aware of additional main problems/tasks to solve when using PL/SQL heavily with ADF BC, which we have to think about?
Thank you for any response.
Ingmar

Answer 1

My main problem is two 'concurrent' areas holding state in an application system based on DB-stored PL/SQL-logic in combination with ADF BC.
For a new System everything can be made ok:
Sure, it is possible to build a new system with the business logic included in ADF BC only. All long-living state will be handled in the BC layer ( including support for UnitsOfWork longer than the webside short HTTP-requests and HTTP-sessions and longer than the database transactions.
For an old system these problems arise:
1. DB data changes not reflected in BC layer:
Our PL/SQL-logic changes data in tables without notifying the ADF BC layer (and its cache). To keep the data in ADF BC entity objects identical to the changed database content a synchronization is needed. BC does not know which part of the application data has been changed because it has not initiated the changes through its entity objects. Therefore a full refresh is needed. In a Forms4GL environment the behavior is similar: We do frequently requeries of all relevant (base)tables after calling database stored logic to be sure to get the changed data to display and to operate on it.
-> Reengineering of the PL/SQL-logic to make the ADF BC layer aware of the changes is a big effort (notifying BC about any change)
2. longer living database transactions
Our PL/SQL-logic in some areas makes use of lengthy database transactions. The technical DB-transaction is similar to the UnitOfWork. If we call this existing logic from ADF BC, database state is produced which will not be DB-committed in the same cycle.
This reduces scalability of ADF BC AM pooling.
Example:
a) Call a DB-stored logic to check if some business data is consistent and prepare some data for versioning. This starts a DB-transaction but does not commit it.
b) Control is handed back to the user interface. Successful result of step a) is displayed
c) User now executes the versioning operation
d) Call another DB-stored logic to execute the versioning. DB-transaction is still open
e) Business layer commits the transaction automatically after successful finishing step d). Otherwise everything from a) to e) is rolled back.
-> redesign of this behavior (= cutting the 1to1 relation between LogicalUnitOfWork and the technicalDatabaseTransaction is a big effort due to the big amount of code.