Discussion :

[burkan21]

Bonjour,
On m'a filé un projet d'un site web (d'une agence de voyage) pour l'améliorer.
Ce site est fait avec CGI perl, mais mon domaine est le J2EE.
Alors ma question est: vous me conseillez d'aprendre Perl et laisser la structure telle qu'elle est? ou bien avec un peu plus d'effort migrer l'application à J2EE?

Merci.

[marabout]

Malgré des éléments très intéressants et sans doute très puissants, il me semble que les CGI Perl perdent de la distance au profit des applis purement client serveur (ASP, ASP.Net, PHP) ou J2EE qui est très bien pour des applis qui le méritent (applis importantes) mais n'hésite pas aussi à voir du côté des web services.

[_Mac_]

Malgré des éléments très intéressants et sans doute très puissants, il me semble que les CGI Perl perdent de la distance au profit des applis purement client serveur (ASP, ASP.Net, PHP) ou J2EE qui est très bien pour des applis qui le méritent (applis importantes) mais n'hésite pas aussi à voir du côté des web services.

Je ne suis pas sûr que tu répondes vraiment à la question. D'autant qu'à mon sens ce que tu dis est partiellement faux : le client-serveur c'est pas J2EE ou PHP, c'est une autre techno d'avant les dites nouvelles technologies (MVS, AS400, etc.), là où on a un client dit lourd connecté en permanence à un serveur et avec un contexte transactionnel fort. Le Web, c'est du client léger sur base d'HTTP donc pas connecté en permanence. Quant aux Web services, c'est totalement hors sujet.

Bref, ma réponse : ça va dépendre principalement de 2 choses :
1. La complexité de l'application : migrer vers J2EE (voir plus bas) n'est pas une mince affaire, sans compter les risques de régressions fonctionnelles, etc. Plus l'application est complexe, plus la migration est risquée en terme d'objectifs projet.
2. L'argent dont dispose le client et ce qu'il est prêt à faire avec : une migration coûtera beaucoup plus cher au client qu'une évolution (voir également ci-après).

Tout est une question d'évaluation des risques par rapport aux objectifs du projet. Si le client demande de rajouter une fonctionnalité et de conserver l'existant, la réponse est immédiate : apprends le Perl. S'il s'agit d'une refonte de l'application ou une profonde évolution, c'est autre chose.

Il faut savoir 2 choses (décidemment, tout va par 2) :
- en ce qui concerne les CGI et Perl, la technologie n'a rien à voir avec J2EE. Donc attends toi à découvrir un nouveau monde si tu dois apprendre les CGI et Perl. L'une des principales différences est qu'il n'y a pas de notion de conteneur en CGI, donc oublie tous les services que peut offrir un conteneur J2EE.
- Le coût d'aquisition de J2EE pour un client qui n'a pas encore de J2EE est important. Il n'y a pas que le coût de la prestation de développement en tant que tel, il faut acheter éventuellement un serveur J2EE, peut-être même acheter de nouveaux serveurs, former les équipes à l'exploitation du serveur, etc. Tout ça, ce sont des risques en plus que le client doit être prêt à accepter et gérer.

Il faut donc d'abord discuter avec le client pour savoir ce qu'il attend et ce qu'il est prêt à faire. De là, tu peux établir une estimation du coût suivant les 2 hypothèses : développement sur la base de l'éxistant (ce que j'appelle évolution) ou migration vers J2EE. Tu discutes de l'affaire avec le client et vous avisez. Le fait que tu ne connais pas Perl est un risque à gérer : il faut notamment compter du temps de montée en compétence supplémentaire.

Tout ça pour dire que ton "un peu plus d'effort" est moins anodin qu'il ne paraît...