[PL/SQL] Portable

Bonjour,
Je vous présente mon problème :
Nous avons actuellement un client lourd en VB (ihm uniquement) , qui accede a une base de données Oracle. Tous les traitements sont implémentés en PL/SQL.
Nous souhaitons en faire une application légère (WEB) à base d'architecture J2EE et d'obtenir une application multi-base (Oracle, SQL-Server, Sys-Base, ...) et portable.
Le PL/SQL étant spécifique à Oracle, il faut trouver une alternative permettant d'être indépendant du choix de la base de données et de la plate-forme.
Ré-implémenter les traitements dans les EJBs (donc en Java), est l'idée envisagée, mais nous nous inquiétons des performances étant donné que les traitements sont déjà trés couteux dans l'application actuelle.
Y'aurait-il d'autres solutions envisageables permettant notre passage en J2EE ?

En gros je souhaiterai savoir s'il est possible éventuellement de ne pas "recoder" tout le moteur de l'application, en utilisant un convertisseur par exemple.

Je ne pense pas qu'un tel convertisseur existe, et encore moins que ce soit possible : chaque BDD a ses propres extensions, et c'est pas normalisé tout ça.

Je pense que vous n'avez pas le choix et passer par une réécriture en Java. Le souci, c'est que si les traitements sont longs, va falloir mettre en place de l'asynchrone, et c'est pas forcément évident. C'est quoi le but de votre appli Web ?

Après avoir fait des recherches, nous sommes donc convaincu que la réécriture du moteur est innévitable, et nous nous demandons si cette nouvelle impémentation verrait ses performances altérées. En sachant que les traitements se réduit dans la plus part des cas a de simple requetes de séléction, qui seraient donc évaluer par le serveur de base de données et non par le serveur J2EE.

Quels genre de traitements ? Y a t'il bcp d'update ou d'insert ou plus de select ? Une solution du type hibernate ou iBatis pour peut-être vous faciliter la vie en terme d'apprentissage (par rapport au EJB). D'autre part la solution iBatis vous permettrait dans une phase de migration de reprendre vos select actuels simplement en les mappant à des objets. Une foit cette phase effectuer et fonctionnel vous pourrez vous consacrer a faire du code non spécifique à oracle.

"...nous sommes donc convaincu que la réécriture du moteur est innévitable..."

Réfléchit bien à cette solution, car ce n'est jamais bon d'avoir n fois le même code. Penses :
- à la maintenance,
- que se passera-t-il quand tu voudras rajouter une base ?