Journal : Apache/PHP et J2EE
Posté par elamapi () le 18 octobre 2004
Suite à l'article sur LinuxFR, je me suis remis à tester une plateforme J2EE (avec Jboss) pour comparer avec une plateforme PHP5/apache.
Aprés deux jours la même question subsiste.
Mis à part le fait qu'il soit plus complexe d'ecrire un "truc" (nommez le comme vous voulez) qui permette a l'utilisateur d'effectuer une action (en gros une application ou l'utilisateur entre des données et ou il recoit un résultat) sur une plateforme J2EE que sur une plateforme PHP/apache, qu'est ce que J2EE à de plus ?
Je ne trouve pas.
Alors n'etant pas expert J2EE/java je pose la question. Et plus précisement, est ce que quelqu'un à un exemple de ce que je ne pourrais pas faire en PHP et qui serait faisable sous J2EE.
ps: mettez de coté la portabilité. le sujet a déjà été traité.
Aprés deux jours la même question subsiste.
Mis à part le fait qu'il soit plus complexe d'ecrire un "truc" (nommez le comme vous voulez) qui permette a l'utilisateur d'effectuer une action (en gros une application ou l'utilisateur entre des données et ou il recoit un résultat) sur une plateforme J2EE que sur une plateforme PHP/apache, qu'est ce que J2EE à de plus ?
Je ne trouve pas.
Alors n'etant pas expert J2EE/java je pose la question. Et plus précisement, est ce que quelqu'un à un exemple de ce que je ne pourrais pas faire en PHP et qui serait faisable sous J2EE.
ps: mettez de coté la portabilité. le sujet a déjà été traité.
> Lire le journal (88 commentaires, moyenne: 1,3).
Vous avez demandé le commentaire #486382.
Run by 
Cette page a été générée par Templeet en 0.1219s (dont 0.0108 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Marrant, ça...
Je suis en train de faire la même chose. Pour ma part, je n'avais jamais eu l'occasion d'explorer J2EE, alors je suis en train de lire et pratiquer "Teach yourself java with Tomcat in 24 hours". Bon, j'ai déja mis 24 heures pour arriver à la fin de la deuxième leçon :)
Ce que je me demande, c'est comment ont-ils fait pour arriver à un truc aussi compliqué ? C'est tout simplement impressionant d'arriver dans un monde aussi vaste, confus (Servlet, JSP, JSF, EJB, sans compter les Tomcat vs Jboss vs Jonas, les paradigmes de programmation comme MVC avec Struts, etc...).
Il est sûr que J2EE possède des caractéristiques (très) intéressantes, notamment l'obligation de gérer rigoureusement l'organisation de son code, mais était-on obligé d'arriver à un truc aussi indigeste à avaler la première fois ? A côté, PHP est d'une facilité à appréhender rafraichissante...
N'y a-t-il pas un juste milieu ?
[^]Re: Marrant, ça...
lol, juste un gag :)
ecrire hello world , une fois pour J2EE , une fois pour PHP/apache
[^]Re: Marrant, ça...
En fait pour repondre un peu a la question :
J2EE c'est plus sympa pour les grosses appli avec plein d'objets metier derriere.
Tu codes ainsi ton metier dans un vrai langage objet (pas de troll et non je n'ai pas encore utilise PHP5) donc ca sera plus reutilisable (si tu veux faire un client leger et un client lourd par exemple). Coder objet en PHP (version 4) ca ne servait a rien (pas d'encapsulation notamment). En version 5 j'imagine que c'est mieux mais tu n'as pas possibilite de reutiliser autant de librairies qu'en Java.
Donc oui il ne faut pas s'etonner de ne pas voir les avantages de J2EE sur un simple Hello world...
[^]Re: Marrant, ça...
Oki pour le hello world par contre:
>>>tu n'as pas possibilite de reutiliser autant de librairies qu'en Java
j'ai pas compris la ? je ne vois pas ce qui empeche de reutiliser du code php ?
>>>un vrai langage objet
mouais faut voir pour php 5. Evidement c'est pas au niveau de java.
>>>les avantages de J2EE sur un simple Hello world
ben justement, a partir de quel niveau ca devient interessant, parceque c'est ca que j'essais de determiner?
En gros c'est histoire de savoir si un jour j'aurai l'utilité de developper avec J2EE (donc je m'y met plus serieusement) ou alors si J2EE ca sert uniquement a creer des application pour gerer des centrale nucleaire avec 10E100000 lignes de code et 100 personnes deriere auquel cas, ca ne me servira probablement jamais.
[^]Re: Marrant, ça...
HelloWorld.jsp:
<%="Hello World"%>
[+] [^]Re: Marrant, ça...
et tu le met ou ton jsp ?
[^]Re: Marrant, ça...
DTC !
[^]Re: Marrant, ça...
Ton helloworld.php, il faut par exemple le mettre dans le répertoire htdocs d'un Apache + module PHP.
Le helloworld.jsp, il faut par exemple le mettre dans le répertoire webapps/ROOT d'un Tomcat.
Le seul gros gros intérêt de PHP pour moi, c'est la facilité de le proposer en hébergement mutualisé. (et donc la facilité de trouver un hebergeur pas cher qui le propose)
[^]Re: Marrant, ça...
Par contre, si tu le fais en servlet (possibilité qui n'a pas grand intérêt dans le cas présent) et que tu es un peu motivé, tu apprends a faire un package, genre examples dans mon bouquin, que tu mets dans un war auquel tu rajoutes donc un web.xml qui correspond. Tu installes ensuite l'application sur le serveur, et ça marche si tu as tout compris ! Effectivement, sinon, le jsp, ça a l'air très bien en théorie.
[^]Re: Marrant, ça...
Tu ne peux pas réutiliser du code php pour autre chose que du web. Alors qu'avec j2ee, demain tu peux développer une interface native sans rien changer au code métier qui est derrière. Et en prime les deux interfaces marcherons en même temps.
[^]Re: Marrant, ça...
j'entre apercois le truc.
En gros tu developpe une appli qui aura la meme interface sur une page web que sur une application/applet java ?
Effectivement la je vois l'interet, mais dans ce cas, peut on systematiquement avoir l'equivalent HTML d'une applet/application java ?
[^]Re: Marrant, ça...
Elle n'aura pas la même interface au contraire, l'intérêt c'est d'avoir des interfaces différentes justement...
Par ex une interface client en html, une interface d'administration en telnet, en jabber, une interface gestion en gtk, en swing... Ou même, pas d'interface du tout, c'est un autre serveur qui communique avec le tien...
[^]Re: Marrant, ça...
a alors je ne comprend pas.
Dans ce cas, tu peut tout aussi bien ecrire ton application/applet java qui communique avec un serveur php.
[^]Re: Marrant, ça...
Oui, mais ton application tu devra l'écrire dans un autre langage et assurer la communication entre ces deux langages, ce qui va t'obliger à rajouter une couche/passerelle supplémentaire.
Par exemple, comment accèdes-tu à ton application php à partir de telnet, jabber, irc etc... ?
[^]Re: Marrant, ça...
pas besoin de couche ni de passerelle. Le hic ne vient pas de la. c'est la persistance qui fait défaut dans le cas présent.
[^]Re: Marrant, ça...
Ha bon, comment tu fais pour envoyer un message jabber à une appli php par ex ?
[^]Re: Marrant, ça...
ben tu a la gestion des socket en php :)
donc bind, accept, ensuite si mes souvenir son bon
avec jabber c'est du XML qui passe donc tu utilise ton joli parser XML php (y en a plein) et tu cause à ton jabber :)
mais meme si ca reste faisable, ca reste de la magouille, je vien de capter ce qui me manquait (post plus pas)
c'est la persistance des processus (pas de données).
[^]Re: Marrant, ça...
Je ne te parle pas d'envoyer un message jabber mais d'en *recevoir* un ! Ce qui implique d'avoir un serveur multi-protocoles.
[+] [^]Re: Marrant, ça...
tu n'as pas bien lu.
BIND , puis ACCEPT = j'attend une connexion EN PROVENANCE de jabber.
Une fois la connexion etabli j'en fait ce que j'en veux , je lit les données qui arrive ou j'ecrit c'est pareil.
[^]Re: Marrant, ça...
ok, mais la, exit php-cgi et mod-php...
[^]Re: Marrant, ça...
vivi en plus, exit apache et serveur, ou ca devient de la GROSSSSE magouille.
[^]Re: Marrant, ça...
ca marche tres bien la preuve un client jabber en php http://webmessenger.blitzaffe.com(...)
-- Malk0 --
[^]Re: Marrant, ça...
le site est indisponible pour l'instant donc je ne peux pas vérifier, mais est-ce que par hasard cette application n'utiliserait pas javascript pour rafraichir la page et actualiser la connexion ?
Si c'est ça, la persistence est gérée (au moins partiellement) par le navigateur, et ton exemple est foireux :)
[^]Re: Marrant, ça...
oui il me semble mais a la limite rien ne t'empeche d'avoir un demon php qui gere les connections jabber et qui discute avec ton appliweb, ou meme un script .
Ce que je veux dire c'est que c'est aussi faisable en php, bien qu'il n'y ai rien de standardisé pour ce genre de choses.
D'autre part si on reste sur une appli purement web (pas d'applet) tu aura exactement le meme probleme de rafraichissement de la page avec j2EE qu'avec PHP non?
-- Malk0 --
[^]Re: Marrant, ça...
Bah non, plein de gens disent dans ce journal qu'une appli J2EE est persistente coté serveur. Elle peut donc parfaitement être un client jabber pour communiquer avec d'autres entités sur le web (et je ne veux pas dire "proposer un client jabber à l'utilisateur"), ce que la plateforme PHP5/Apache ne peut pas faire
[^]Re: Marrant, ça...
il existe PHP-GTK qui permet de réaliser pas mal de choses, quant à l'acces par telnet c'est tout a fait envisageable avec les sockets.
-- Malk0 --
[^]Re: Marrant, ça...
En gros tu developpe une appli qui aura la meme interface sur une page web que sur une application/applet java ?
Plus exactement les 2 vues (HTML, SWING ou autre) accederont aux memes objets côte serveur. Les interfaces ne seront pas identiques pour autant. Tout simplement parce qu'il y a une difference entre mode connecte et deconnecte et que les composants de formulaires ne sont pas les memes (tres peu evolues en html).
peut on systematiquement avoir l'equivalent HTML d'une applet/application java
Euh je ne comprends pas bien la question mais comme j'ai dit juste au dessus les IHM ne sont pas les memes en HTML et en client lourd. Et il n'existe pas de moyen de generer automatiquement un client a partir d'un autre.
[^]Re: Marrant, ça...
Et il n'existe pas de moyen de generer automatiquement un client a partir d'un autre.
Mais si : http://wings.mercatis.de/tiki-index.php?page=Demo(...)
Bon ok c'est un peu beaucoup lent, mais c'etais juste pour dire hein...
[^]Re: Marrant, ça...
j'ai pas compris la ? je ne vois pas ce qui empeche de reutiliser du code php ?
Rien n'empeche de reutiliser du code en PHP
Simplement le nombre de librairies est plus important en Java. Tout simplement parce qu'en general, ces librairies peuvent etre reutilisees dans des clients lourds ET legers.
Si on prend l'exemple du graphique, compare JFreeChart et JPgraph
Le premier (Java) peut etre utilise en SWING et dans des servlets. Le deuxieme ne sera utilise que pour les appli web (a moins que bcp de gens de fasse du PHP-GTK mais je ne crois pas...). Bref plus d'utilisateurs/de developpeurs => meilleure qualite + de fonctions etc etc.
ben justement, a partir de quel niveau ca devient interessant, parceque c'est ca que j'essais de determiner?
Quand tu commences a voir plein d'objets a stocker en BD ca devient tres utile de programmer en Java. Tu peux utiliser des couches de persistence comme Hibernate (http://hibernate.sf.net(...)) qui n'ont pas d'equivalent en PHP... Pas besoin de gerer une centrale nucleaire pour voir les apports de Java rassure toi :)
[+] [^]Re: Marrant, ça...
> pas d'encapsulation !!!
laissez moi rire, les classes php (4 et 5) sont assez complete pour pouvoir réaliser de jolis framework objet, alors arretez donc avec la soit disante supériorité de java et C++. Avec php tout est beaucoup plus dynamique et rapide a developper.
cepandant, dans un contexte contractuel, php4 n'est pas la panacée puisqu'on peut acceder aux membres de la classe.
[^]Re: Marrant, ça...
peut être malgré tout que le modèle objet Java est un peu aidé par la nature du serveur ...
Je m'explique : qu'en est-il du chargement d'une hierarchie objet en PHP ? elle est intégralement rechargée à chaque appel non ? en Java, les classes mères sont cachées et leur rechargement est un peu plus pêchu je dirais.
mes 2¢
[^]Re: Marrant, ça...
vi c'est pour ca qu'il ne faut pas comparer java a php mais J2EE à PHP/serveur web(souvent apache).
Enfin si j'ai lancé la question c'etait pour ca.
[^]Re: Marrant, ça...
cepandant, dans un contexte contractuel, php4 n'est pas la panacée puisqu'on peut acceder aux membres de la classe.
Hum, c'est pas ca qu'on appelle l'encapsulation ? Tu viens donc exactement de dire ce que j'ai dit plus haut !
[^]Re: Marrant, ça...
tu confonds encapsulation et protection des données membres. Enfin peut-etre que tu as raison et que je suis le "hors norme". Souvent je constate une grande facon de voir les choses et dans vocabulaire employé en fonction de les langages utilisés par les gens. Je constate que bien des gens pensent C++ au lieu de penser a un niveau un peu plus élevé, c'est a dire le niveau objet.
voici un extrait de wikipedia qui a tendance a te donner raison :
L'encapsulation pour les développeurs en informatique est l'idée de cacher l'information contenu dans un objet et de ne proposer que des méthodes de manipulation de cet objet, ainsi les propriété et axiomes associés au informations contenue dans l'objet seront assurés/validés par les méthodes de l'objet et ne seront plus de la responsabilité de l'utilisateur extérieur.
L'utilisateur extérieur ne pourra pas modifier directement l'information et risquer de mettre en péril les axiomes et les propriétés comportementales de l'objet.
cependant, dans un langage permissif tel que php(4), etant donné que la notion de contrat n'est plus formalisée par le langage, c'est au développeur de veiller au grain.
c'est un peu comme la notion de methode virtuelle ... en php, tout methode est dite virtuelle dans le sens ou elle est surchageable et a ligature dynamique (si je me plante pas dans la terminologie).
[^]Re: Marrant, ça...
tiens, voila quelqu'un qui assimile le terme encapsulation de la meme maniere que moi et pas dans le sens C++ !
http://www.tonymarston.net/php-mysql/good-bad-oop.html(...)
# 'Encapsulation' means that the class must define all the properties and methods which are common to all objects of that class. All those properties and methods must exist inside a single container or 'capsule', and must not be distributed across multiple locations.
Reference: encapsulation The localization of knowledge within a module. Because objects encapsulate data and implementation, the user of an object can view the object as a black box that provides services. Instance variables and methods can be added, deleted, or changed, but as long as the services provided by the object remain the same, code that uses the object can continue to use it without being rewritten.
juste dessous, il fait bien le distingo : encapsulation - protection de l'implémentation ...
[^]Re: Marrant, ça...
C'est pas sur le hello world que ce se joue. PHP est handicapé par le fait qu'il fonctionne soit en CGI soit en module d'apache.
Quand il veut faire persister un truc entre deux requêtes HTTP (un panier d'articles par exemple) PHP doit avoir recours à un moyen de persistence quelquonque (bd par exemple). J2EE lui fonctionne avec une serveur : les différents threads ont accès à un même espace mémoire. Amuse toi à implémenter un panier d'article avec J2EE et avec php puis benche les deux applis. Le panier J2ee fonctionnerra uniquement en ram (car la session est en ram) et le panier PHP sera sérialisé sur le disque à chaque requête. Java va consommer plus de ram mais être rapide et monter en charge, et PHP va flinguer la base ou le disque.
[^]Re: Marrant, ça...
je vois ce que tu veux dire, simplement ton exemple est mauvais.
Le panier comme tu dis sera stocké en DB, la DB à un cache en ram, il n'y aura pas plus d'accés disque qu'avec J2EE.
par contre est ce que quelqu'un a des graphe de bench au niveau de l'utilisation ram/disk sur des applications equivalentes ? (entre php/apache et j2ee)
[^]Re: Marrant, ça...
Ca dépend si tu compare à mod-php ou php-cgi.
Avec php-cgi c'est incomparable, avec mod-php je sais pas, j'imagine que les sessions peuvent être stockées en ram aussi non (mais là c'est des histoires d'implémentations) ?
[^]Re: Marrant, ça...
en ram aussi vivi mais j'ai enfin compris ce qui me manquerai vraiment entre PHP et J2EE.
ce n'est pas la persistance des données, ca y a toujours moyen de ce debrouiller.
C'est la persistance des processus.
A part la grosse magouille, je ne peut pas laisse tourner une tache de fond sur mon apache.
Enfin je vois bien une methode, mais il faudrai un serveur web pur php, plus une normalisation etc ... je ne pense pas que ca esiste deja.
[^]Re: Marrant, ça...
Non, mon exemple n'est pas si mauvais que ça : pour ajouter ou enlever un élément du panier, ca va donner un insert ou un delete dans la bd. Et toute base qui se respecte écrit les modifications sur le disque de manière synchrone dans le log des transactions (et laisse trainer le tuple dans le cache en ram dans le cas d'un insert). Sans compter le transfert des données par le réseau vers la BD...
[^]Re: Marrant, ça...
>>> Et toute base qui se respecte écrit les modifications sur le disque de manière synchrone
La j'ai un gros doute, en plus c'est quoi une base "qui se respecte" ?
Pour moi un SGBD qui se respecte est celui qui fait ce qu'on lui demande, qui correspond au besoin, et qui permet de rapidement faire une restauration en cas de crash (voire eviter le crash).
Donc j'insiste mais a part ecrire une application susceptible de gérer les états d'une centrale nucleaire, pour un site marchant, meme consequant ton exemple est mauvais.
Pourquoi ?
Parce que tant que le client n'a pas validé sa demande, il est inutile (J2EE ou pas d'ailleur) de stoquer quoi que ce soit en base. tout peut se faire via cookie ou simple parametre post sur une page HTML. Ce qui va dégager des ressource sur le serveur, donc necessister un serveur moins puissant, donc moins cher. De plus que l'on ait 1 ou 100000000000000 clients ce n'est pas ca qui pénalisera le serveur.
Ensuite, la remarque :
Sans compter le transfert des données par le réseau vers la BD
n'a pas lieu d'être, même un particulier peut se payer du 100Mb a la maison, imagine ce que peu se payer une société qui a un site marchand encaissant des miliers de connexions par heure (faut au moins ca pour rentabilier le cout d'exploitation d'un J2EE).
Et pour finir avec le coup des "log de transaction", a moins que tu ne parle d'un Oracle sur un raw device (ou sybase) , ca revient au meme.
Ton log est un fichier, l'ecriture est géré par le noyau (je prend le cas d'un linux), auquel cas la notion de cache en ecriture existe aussi et ont retomber sur mon exemple précérend!
[^]Re: Marrant, ça...
La petite nouveauté de PHP 5, c'est SQLite. Moteur (sommaire, certes, mais suffisant pour cet optique) de base de données SQL complètement intégré et qui peut stocker ses bases/tables en RAM.
Avec la capacité de sérialiser un objet PHP, on peut espérer un mécanisme de persistence à moyen terme d'objets (moyen terme === entre plusieurs requêtes HTTP formant un ensemble logique, selon moi).
Cependant, je suis d'accord pour dire que le temps de sérialisation / désérialisation sera impactant. Une idée pour comparer ça au mécanisme de J2EE pour conserver des objets dans la VM ? Impact du délai entre 2 requêtes ?
[^]Re: Marrant, ça...
Il y a plein de "juste milieu" : n'importe quel langage avec lequel tu peux faire un serveur autonome (cad lancé en permanence). Après c'est un problème de confort, les librairies plus où moins pratiques etc...
Jette un coup d'oeuil à http://twistedmatrix.com(...)