C'est un serveur applicatif OpenSource (au sens OSI mais pas FSF apparament), qui a pendant longtemps été développé par Lutris, une société californienne, en collaboration avec la communauté et quelques autres boîtes (dont FT et Evidian).
Enhydra Classic est purement Java, sépare bien données-manipulation des données-présentation, est XML/(X)HTML, JDBC/SQL, etc. Et il est basé sur Tomcat. Il gère bien évidemment les sessions utilisateur, et la répartition de charge via un module apache (le director), simple mais très efficace. Il gère également les pools de connexion à une base de données, etc.
Et il marche très bien, et pas mal de gens s'en servent.
Et puis un jour, Lutris a décidé d'implémenter Enhydra Entreprise, cette fois-ci J2EE.
Et Lutris a fermé. Impossible de vendre quoique ce soit autour de ce modèle (et surtout pas du service, comme Lutris le faisait): le marché appartient à de grosses boîtes qui vendent leur serveurs applicatifs à d'autres grosses boîtes, et personne là-dedans ne comprend vraiment ce qu'il vend et ce qu'il a acheté. Dans 80% des cas, un serveur applicatif J2EE dépasse de beaucoup les besoins.
Quand à Apache/PHP et à IIS/ASP, c'est carrément dommage de les mettre dans le même sac. Le problème numéro 1 d'ASP, c'est qu'ASP ne fait RIEN ou presque, c'est juste un conteneur de toutes les cochonneries MS qu'il vous viendrait à l'idée de mettre dans votre web: VB/JScript, ODBC/ADO, OLE/COM/DCOM/ActiveX. Bref, emmerdes et trous de sécurité à l'infini, quand à la stabilité...
PHP en revanche, ça ressemble plus au noyau Linux: plein de trucs dedans, écrits spécialement pour PHP et rien que pour PHP. Donc fondamentalement plus stable et plus sûr.
Après au niveau de l'utilisation... il existe des serveurs applicatifs en PHP aussi.. mais il est vrai que je trouve le langage PHP un peu pauvre, pour plusieurs raisons (le typage faible -mais c'est discutable-, pas de gestion bien foutue des erreurs -les exceptions Java-, pas de modèle objet bien foutu et complet -très utile pour une implémentation MVC propre, et une bonne maintenabilité-). D'ailleurs, c'est dommage que l'article n'en aie pas parlé, pour juste se concentrer sur le typage qui n'est qu'un exemple bien faible, somme toute...
[^] # Re: Un article qui a au moins l'intérêt de se poser certaines questions
Posté par anonyme512 . En réponse à la dépêche Apache/PHP et IIS/ASP : pas si bons ?. Évalué à 4.
Je reviens à la charge avec un exemple: Enhydra.
C'est un serveur applicatif OpenSource (au sens OSI mais pas FSF apparament), qui a pendant longtemps été développé par Lutris, une société californienne, en collaboration avec la communauté et quelques autres boîtes (dont FT et Evidian).
Enhydra Classic est purement Java, sépare bien données-manipulation des données-présentation, est XML/(X)HTML, JDBC/SQL, etc. Et il est basé sur Tomcat. Il gère bien évidemment les sessions utilisateur, et la répartition de charge via un module apache (le director), simple mais très efficace. Il gère également les pools de connexion à une base de données, etc.
Et il marche très bien, et pas mal de gens s'en servent.
Et puis un jour, Lutris a décidé d'implémenter Enhydra Entreprise, cette fois-ci J2EE.
Et Lutris a fermé. Impossible de vendre quoique ce soit autour de ce modèle (et surtout pas du service, comme Lutris le faisait): le marché appartient à de grosses boîtes qui vendent leur serveurs applicatifs à d'autres grosses boîtes, et personne là-dedans ne comprend vraiment ce qu'il vend et ce qu'il a acheté. Dans 80% des cas, un serveur applicatif J2EE dépasse de beaucoup les besoins.
Quand à Apache/PHP et à IIS/ASP, c'est carrément dommage de les mettre dans le même sac. Le problème numéro 1 d'ASP, c'est qu'ASP ne fait RIEN ou presque, c'est juste un conteneur de toutes les cochonneries MS qu'il vous viendrait à l'idée de mettre dans votre web: VB/JScript, ODBC/ADO, OLE/COM/DCOM/ActiveX. Bref, emmerdes et trous de sécurité à l'infini, quand à la stabilité...
PHP en revanche, ça ressemble plus au noyau Linux: plein de trucs dedans, écrits spécialement pour PHP et rien que pour PHP. Donc fondamentalement plus stable et plus sûr.
Après au niveau de l'utilisation... il existe des serveurs applicatifs en PHP aussi.. mais il est vrai que je trouve le langage PHP un peu pauvre, pour plusieurs raisons (le typage faible -mais c'est discutable-, pas de gestion bien foutue des erreurs -les exceptions Java-, pas de modèle objet bien foutu et complet -très utile pour une implémentation MVC propre, et une bonne maintenabilité-). D'ailleurs, c'est dommage que l'article n'en aie pas parlé, pour juste se concentrer sur le typage qui n'est qu'un exemple bien faible, somme toute...