[Info] Migration SI PowerBuilder Oracle vers J2EE ?

Bonjour,

notre SI actuel a été développé sous powerbuilder et tourne sur un environement oracle/windows. sur un mode client serveur.

On s'interroge sur la portabilité d'un tel système sous envirennement J2EE, et une architecture n-tiers et les contraintes d'utilisation éventuelles.
le système comprends
+ de 500 interfaces graphiques sur requêtes SQL
+ de 200 Fenêtres Windows
* 70 tables dans la base de données
* 3.000 lignes de procédures stockées SQL

le système est consultable par environ 2500 postes sur toute la france.

Je m'interroge surtout sur le temps de réponse d'une telle architecture. J'ai en effet lu une étude comparative je22/.net qui laissé entendre que j2ee pouvait avoir des temps de réponses très long passé une certaine charge.

Quelqu'un peut il m'éclairer? Comment avoir des éléments fiable de réponse avant de lancer une telle migration?

Bonjour,

Je vais essayer d'être objectif et de ne pas ouvrir la porte au(x) troll(s).
L'appli dont tu parle avait été écrite non dans 1 but de mise en production, mais pour illustrer les possibilité d'1 techno. Les dev. se sont 'fait plaisir'. C'était 1 peu 1 vitrine ciale, on ne s'interressait pas à ce qu'il y avait derrière.
L'appli PetStore v° .net à été dev. ds 1 seul but : que .net aille plus vite... donc code optimisé, accès data optimisés, utilisation des technique d'affichage optimisé etc...
Evidemment à l'arrivée...y a pas photo.
A la suite de ça, les dev. d'oracle ont recodés aussi l'appli. PetStore en ayant le même but : aller + vite que .net : les résultats sont là :
http://www.oracle.com/technology/tech/java/oc4j/pdf/9ias_net_bench.pdf
(Pour résumer la v° Oracle tourne environ 7 fois plus vite que la v° .net)
Pour moi ça ne signifie rien. Simplement que les 3 équipes de dev. avaient 2 objectifs différents.
Je pense qu'il n'a a ni bonne ni mauvaise techno. La satisfaction globale d'1 SI est la satisfaction qu'apporte son maillon le plus faible.
Avec 1 archi. saine, des SGBD bien étudiés, du code propre, des tuyaux du bon diamètre, des besoins bien compris etc... qque soit le choix qui sera fait il ne devrait pas y avoir de pb.

PS: PB gère très bien aussi le n-tiers, pourquoi n'envisagez-vs pas d'évoluer avec ?

A +

Un autre point à prendre en compte est le type de client envisagé :
client lourd de type Swing
ou
client léger de type Web

La première solution présente l'avantage de la facilité de migration de fonctionnements IHM séquentiels, et les inconvénients du déploiement d'un client lourd;

la seconde apporte l'avantage de l'absence de déploiement, et les inconvénients du mode déconnecté (gestion de session utilisateur etc).

Dans tous les cas les temps de réponse seront plus liés au dimensionnement des serveurs, des bdd, du réseau, des données échangées qu'au type de techno utilisée.

Avant de se lancer dans le chantier de migration une préétude est nécéssaire :
- une analyse de l'IHM existante et des nouvelles fonctionnalités attendues pour choisir le type de client
- une phase de prototypage sur un sous-ensemble fonctionnel restreint, qui va servir à valider le choix de l'architecture, et mesurer la tenue en charge et les temps de réponse à l'aide d'outils spécialisés.

Cela peut se confier à une société d'ingénierie.