Bon, j'ai renoncé à tester jonas pour jboss, carrement plus simple à mettre en oeuvre. Un trés bon point pour lui.
Cependant, il rest toujours plus complexe à integrer qu'un apache+php généralement préinstallé (ou facilement installable via apt,yum ou autre) a linux (il en va de meme pour windows avec easyphp msas ou autre).
Une fois l'installation faite, j'ai pu tester des petites choses (sur les deux environements).
- application basique (hello world).
- Petites applications client/serveur (chat, client irc, petit jeux réseau).
- liaison avec base de données (postgres/mysql/oracle 8i)
- test XMLRPC
plus quelques autres tests.
Mes impressions:
Si on reste avec un navigateur web coté client (pas d'applet java/pas de flash ou autre, juste des page web avec du javascript/vbscript/script) : On peut faire EXACTEMENT la meme chose avec une plateforme J2EE et PHP (sauf que globalement c'est plus simple a mettre en oeuvre en php).
La ou j'ai constaté un "petit" avantage à J2EE c'est si on crée une application web avec une applet coté client.
Le on se retrouve avec une jolie application client/serveur en mode connectée. L'interet, avoir des remonté d'info en temp reel ce que ne peut pas faire une page web.
Peut on faire la meme chose en PHP, oui, 2 solution.
La plus simple on utilise du flash (je sais c pas bien ca pu c pas libre) pour un résultat presque identique.
On utilise (comme en j2ee) une applet java qu'on fait communiquer avec du PHP (c'est un peu plus sioux mais ca fonctionne parfaitement).
Maintenant, que ce soit J2EE ou PHP j'ai lu de GROSSES aneries quant à l'indépendance vis à vis du serveur.
dans un cas comme dans j'autre, on reste "relativement" indépendant de la plateforme (mes applications php je les passes de windows à linux a linux4powerpc sans probleme) .
Mais dans un cas comme dans l'autre, on concerve les memes dépendances:
Filesystem: si vous stockez des fichiers sur le filesystem local vous aurez les contraintes dudis filesystem (la solution reste de tout stocker en DB, mais la c'est pareil en J2EE et PHP).
L'affichage d'application cliente avec applet/flash:
Pour avoir testé des applis graphique java/flash sous windows/linux/mac je peux vous jurer que j'avais des différences d'affichage (en particulier avec les police de caracteres), on peut eviter ca mais ca demande une gymnastique de plus.
Maintenant, je reste persuadé que PHP reste performant pour 98% des applications qu'un serveur J2EE.
Le développement d'une application J2EE reste TRES lourde et on peu faire la meme chose en PHP.
La seule chose que je concede (mais qui reste importante) c'est la normalisation: J2EE est plus "conforme" que PHP.
Mais je suis certain qu'une bonne equipe de dev avec un bon chef de projet peuvent se passer de cette "normalisation".
Quand à python, (j'ai lu ca dans un post plus haut) je n'en parle meme pas. Il ne joue pas dans la meme catégorie. Je suppose que l'auteur voulais parler de Zope & Co. Pour moi c'est inutilisable a grande echelle (sans parler des performances et de la difficulter d'integrer des Products généralement lié à des libs externes incompilables plus du fait que les products sont pour la majorité inutilisable d'une version de Zope a l'autre).
# avis apres test de jboss
Posté par elamapi . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 0.
Cependant, il rest toujours plus complexe à integrer qu'un apache+php généralement préinstallé (ou facilement installable via apt,yum ou autre) a linux (il en va de meme pour windows avec easyphp msas ou autre).
Une fois l'installation faite, j'ai pu tester des petites choses (sur les deux environements).
- application basique (hello world).
- Petites applications client/serveur (chat, client irc, petit jeux réseau).
- liaison avec base de données (postgres/mysql/oracle 8i)
- test XMLRPC
plus quelques autres tests.
Mes impressions:
Si on reste avec un navigateur web coté client (pas d'applet java/pas de flash ou autre, juste des page web avec du javascript/vbscript/script) : On peut faire EXACTEMENT la meme chose avec une plateforme J2EE et PHP (sauf que globalement c'est plus simple a mettre en oeuvre en php).
La ou j'ai constaté un "petit" avantage à J2EE c'est si on crée une application web avec une applet coté client.
Le on se retrouve avec une jolie application client/serveur en mode connectée. L'interet, avoir des remonté d'info en temp reel ce que ne peut pas faire une page web.
Peut on faire la meme chose en PHP, oui, 2 solution.
La plus simple on utilise du flash (je sais c pas bien ca pu c pas libre) pour un résultat presque identique.
On utilise (comme en j2ee) une applet java qu'on fait communiquer avec du PHP (c'est un peu plus sioux mais ca fonctionne parfaitement).
Maintenant, que ce soit J2EE ou PHP j'ai lu de GROSSES aneries quant à l'indépendance vis à vis du serveur.
dans un cas comme dans j'autre, on reste "relativement" indépendant de la plateforme (mes applications php je les passes de windows à linux a linux4powerpc sans probleme) .
Mais dans un cas comme dans l'autre, on concerve les memes dépendances:
Filesystem: si vous stockez des fichiers sur le filesystem local vous aurez les contraintes dudis filesystem (la solution reste de tout stocker en DB, mais la c'est pareil en J2EE et PHP).
L'affichage d'application cliente avec applet/flash:
Pour avoir testé des applis graphique java/flash sous windows/linux/mac je peux vous jurer que j'avais des différences d'affichage (en particulier avec les police de caracteres), on peut eviter ca mais ca demande une gymnastique de plus.
Maintenant, je reste persuadé que PHP reste performant pour 98% des applications qu'un serveur J2EE.
Le développement d'une application J2EE reste TRES lourde et on peu faire la meme chose en PHP.
La seule chose que je concede (mais qui reste importante) c'est la normalisation: J2EE est plus "conforme" que PHP.
Mais je suis certain qu'une bonne equipe de dev avec un bon chef de projet peuvent se passer de cette "normalisation".
Quand à python, (j'ai lu ca dans un post plus haut) je n'en parle meme pas. Il ne joue pas dans la meme catégorie. Je suppose que l'auteur voulais parler de Zope & Co. Pour moi c'est inutilisable a grande echelle (sans parler des performances et de la difficulter d'integrer des Products généralement lié à des libs externes incompilables plus du fait que les products sont pour la majorité inutilisable d'une version de Zope a l'autre).