Pourquoi migrer des applications client-serveur vers Java ?

Quelles sont les motivations qui amènent de plus en plus d'entreprises à remplacer leurs applications existantes par un système d'information "web- centric" ? 
On peut tout d'abord citer le coût élevé de développement et de maintenance des environnements client/serveur. 
Toutefois le facteur principal est sans doute la nécessité d'ouvrir certaines parties du système d'information aux partenaires et aux clients de l'entreprise.

Problèmes des environnements client/serveur traditionnels

Les applications client/serveur ont été développées pour améliorer l'interface souvent rustique des applications "mainframe", en s'efforçant d'y substituer la convivialité généralement présente dans les applications de micro-ordinateurs. 
Il était également espéré qu'en déportant les traitements sur le poste de travail, le coût des communications serait sensiblement réduit. 
La réalité a démontré que si les bénéfices d'une plus grande convivialité étaient généralement atteints, c'était au prix d'inconvénients qui posent aujourd'hui des problèmes graves aux responsables informatiques.
Parmi ces inconvénients, citons les coûts de distribution des modules logiciels sur les postes de travail, l'évolution des systèmes d'exploitation des postes clients, le manque de pérennité des outils de développement, la rareté des compétences et l'opacité des technologies propriétaires�

Pourquoi un client browser?

Parce que le browser affichant des documents HTML est devenu le client standard incontestable, utilisé par des millions d'Internautes. 
De plus ce client est désormais présent sur tous les postes de travail. Cette solution élimine très largement les problèmes d'administration et de contr�le des postes de travail, inconvénient majeur des systèmes client/serveur traditionnels. 
La technologie Internet a, dans ce domaine, d'ores et déjà gagné la partie.

Pourquoi Java?

Parce que Java s'impose progressivement comme le langage universel dont le principal mérite est de ne pas dépendre d'un fournisseur ou d'un environnement. 
Java ne conna�t pas actuellement de "concurrent" crédible pour ce type de développement en dehors du tout Microsoft avec des risques de dépendance totale. 
Il est possible de penser que Java sera le cobol des années 2000.