Journal Apache/PHP et J2EE

Posté par  .
Étiquettes : aucune
0
18
oct.
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é.

  • # Avec j2ee j'ai un serveur

    Posté par  (site web personnel) . Évalué à 5.

    Ce qui me permet d'effectuer des actions quand l'utilisateur n'est pas là : par exemple dans une appli de caltos web, envoyer un mail 15 min avant le rdv. Avec du php, je dois avoir recours à un outils externe genre cron + php-cgi.

    • [^] # Re: Avec j2ee j'ai un serveur

      Posté par  . Évalué à -3.

      Heu, tu peux détailler stp ?

      je suppose que ton serveur ne devine pas tout seul qu'il faut envoyer un mail,

      donc je supose que tu dois ecrire une parti serveur qui va checker les rdvs et envoyer le mail,

      je supose toujours que tu dois "activer/lancer" l'action de checker les rdvs pour envoyer les mails ?

      Si tel est le cas tu peu faire la meme chose avec PHP/apache (uniquement sans cron ni programme externe).

      • [^] # Re: Avec j2ee j'ai un serveur

        Posté par  . Évalué à 2.

        le script PHP qui va envoyer le mail 15 minutes avant un RDV, il est lancé par quoi dans ton idée ?

        Qui le déclenche ? l'utilisateur vient gentiment rafraichir sa page 15 minutes avant son RDV ?

        • [^] # Re: Avec j2ee j'ai un serveur

          Posté par  . Évalué à -3.

          Otes moi d'un doute, t'a une jolie applet java (ou alors une application java) pour faire ca ?

          • [^] # Re: Avec j2ee j'ai un serveur

            Posté par  . Évalué à 1.

            Ôte moi d'un doute : tu fais de l'humour là ?

            • [^] # Re: Avec j2ee j'ai un serveur

              Posté par  . Évalué à -1.

              Absoluement pas. je te l'ai dis, je ne suis pas expert J2EE donc je pose simplement une question.

              • [^] # Re: Avec j2ee j'ai un serveur

                Posté par  . Évalué à 0.

                Si tu as un serveur, il tourne en permanence. Il n'est pas triggeré par la visite d'une page.

                Avec J2EE, c'est le serveur tout seul qui va envoyer le mail automatiquement. En _très_ gros, ton serveur contient un cron. En PHP, tu es obligé de passer par un job cron pour déclencher un script qui enverra le mail.

                Et niveau portabilité, bonjour cron sous windows (par exemple)

              • [^] # Re: Avec j2ee j'ai un serveur

                Posté par  . Évalué à 2.

                Tu n'as pas pigé que la différence est qu'une appli web en j2ee ou autre, est lancée en permanence, ce qui facilite la persistance et qui permet de faire des choses sans intervention du client qui visite une page.
                Un autre exemple plus frappant que l'email : tu peux réagir à d'autres actions qu'un timer, par ex pour mon jeu de scrabble, je peux réagir à des messages jabber, je peux controler mon programme par telnet etc...

          • [^] # Re: Avec j2ee j'ai un serveur

            Posté par  (site web personnel) . Évalué à 1.

            Non soit je lance un Timer depuis le init d'un servlet (ce qui marche en j2ee standard), soit j'utilise les fonctions de schéduling de jboss.

  • # Filer le design des pages à un graphiste

    Posté par  . Évalué à 1.

    Avec un Framework MVC (JSF ou struts par ex.), je peux filer le design des pages à un graphiste qui va utiliser Dreamweaver et qui ne connait rien à la prog. Ca s'appel la séparation logique - présentation.

  • # Sérieusement...

    Posté par  (site web personnel) . Évalué à 3.

    Avec J2EE, on peut remplir sa deuxième barette de 512Mo de RAM, alors qu'avec PHP, on sait pas quoi en faire !
    C'est où la sortie ?

    "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

    • [^] # Re: Sérieusement...

      Posté par  . Évalué à 2.

      Ah tiens, je croyais qu'avec Java, entre le moment ou tu envoie ta requete et le moment ou la page arrive tu as le temps d'aller te faire un café (d'ou l'icône...)


      Poussez pas, c'est par là =====> []

  • # Marrant, ça...

    Posté par  . Évalué à 6.

    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...

      Posté par  . Évalué à 0.

      lol, juste un gag :)

      ecrire hello world , une fois pour J2EE , une fois pour PHP/apache

      • [^] # Re: Marrant, ça...

        Posté par  . Évalué à 3.

        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...

          Posté par  . Évalué à 0.

          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...

            Posté par  . Évalué à 3.

            HelloWorld.jsp:


            <%="Hello World"%>

            • [^] # Re: Marrant, ça...

              Posté par  . Évalué à -3.

              et tu le met ou ton jsp ?

              • [^] # Re: Marrant, ça...

                Posté par  . Évalué à 2.

                DTC !

              • [^] # Re: Marrant, ça...

                Posté par  . Évalué à 2.

                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...

              Posté par  . Évalué à 2.

              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...

            Posté par  . Évalué à 2.

            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...

              Posté par  . Évalué à 0.

              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...

                Posté par  . Évalué à 1.

                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...

                  Posté par  . Évalué à 0.

                  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...

                    Posté par  . Évalué à 2.

                    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...

                      Posté par  . Évalué à 0.

                      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...

                        Posté par  . Évalué à 1.

                        Ha bon, comment tu fais pour envoyer un message jabber à une appli php par ex ?

                        • [^] # Re: Marrant, ça...

                          Posté par  . Évalué à 0.

                          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...

                            Posté par  . Évalué à 1.

                            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...

                              Posté par  . Évalué à -1.

                              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...

                                Posté par  . Évalué à 1.

                                ok, mais la, exit php-cgi et mod-php...

                                • [^] # Re: Marrant, ça...

                                  Posté par  . Évalué à 0.

                                  vivi en plus, exit apache et serveur, ou ca devient de la GROSSSSE magouille.

                            • [^] # Re: Marrant, ça...

                              Posté par  . Évalué à 2.

                              Je ne te parle pas d'envoyer un message jabber mais d'en *recevoir* un ! Ce qui implique d'avoir un serveur multi-protocoles

                              ca marche tres bien la preuve un client jabber en php http://webmessenger.blitzaffe.com(...)

                              • [^] # Re: Marrant, ça...

                                Posté par  . Évalué à 4.

                                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...

                                  Posté par  . Évalué à 0.

                                  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?

                                  • [^] # Re: Marrant, ça...

                                    Posté par  . Évalué à 4.

                                    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...

                  Posté par  . Évalué à 2.

                  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.

              • [^] # Re: Marrant, ça...

                Posté par  . Évalué à 1.

                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...

            Posté par  . Évalué à 2.

            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...

          Posté par  . Évalué à -1.

          > 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...

            Posté par  . Évalué à 1.

            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...

              Posté par  . Évalué à 0.

              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...

            Posté par  . Évalué à 0.

            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...

              Posté par  . Évalué à 2.

              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...

            Posté par  . Évalué à 1.

            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...

        Posté par  (site web personnel) . Évalué à 2.

        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...

          Posté par  . Évalué à 0.

          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...

            Posté par  . Évalué à 1.

            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...

              Posté par  . Évalué à 1.

              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...

            Posté par  (site web personnel) . Évalué à 1.

            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...

              Posté par  . Évalué à 1.

              >>> 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...

            Posté par  . Évalué à 1.

            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...

      Posté par  . Évalué à 2.

      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(...)

  • # Tolérance aux pannes

    Posté par  . Évalué à 4.

    Avec n'importe quel serveur J2EE, je peux faire de la tolérance au pannes (persistance de session sur plusieurs serveurs, donc sans impact utilisateur).
    Un serveur tombe, pas grave, je suis redirigé sur un autre serveur qui possède également ma session.

    Avec PHP, je suis pas au courant d'une solution qui permette ca.

    • [^] # Re: Tolérance aux pannes

      Posté par  . Évalué à 0.

      meme réponse que plus haut, vous parlez d'applet/application en mode connecté (pke si la connexion n'est pas persistante, rien n'est plus facile que de monter un cluster et de distribuer la session, meme en bash :) ).

      • [^] # Re: Tolérance aux pannes

        Posté par  . Évalué à 2.

        Je vois pas très bien de quoi tu parles.

        Moi je parle d'un site web, utilisant des servlet ou un Framework MVC, et tournant sur un serveurs J2EE type JBoss.

        Tu viens sur un site marchant, t'as déja 3 articles dans ton panier, et la le serveur tombe. Avec J2EE, ca peux etre transparent si tu as au moins 2 serveurs et que tu as configure le failover.

        • [^] # Re: Tolérance aux pannes

          Posté par  . Évalué à -1.

          ben heu .... tu peux faire la meme chose avec n'importe quel serveur apache en fait.

      • [^] # Re: Tolérance aux pannes

        Posté par  (site web personnel) . Évalué à 3.

        Non, ils parlent de session au sens web, genre avec un session-id ou un cookie.

  • # Entre php et java mon coeur balance du côté de python

    Posté par  . Évalué à 6.

    Mis à part le petit troll qui s'est glissé, voilà pourquoi j'utilise python à la place de php, et pour les mêmes raisons j'aurai pu utiliser java...

    D'abord une raison suplémentaire qui a été décrite maintes fois, j2ee n'est pas un langage mais une norme qui défini des comportements standards. On pourrait très bien imaginer un php compatible j2ee, mais pour l'instant ce n'est pas le cas.

    Mais revenons aux choses plus terre à terre.

    Au début j'ai utilisé php par obligation car c'était le seul langage disponible chez mon hébergeur. J'utilisais windev pour faire des applications windows, bash pour faire des scripts d'admin, C pour faire des jeux, C++ pour faire des GUI etc... C'était très pénible d'avoir à changer mes habitudes à chaque programme.

    Aujourd'hui j'utilise python, je me suis fait des bibliothèques que je peux aussi bien utiliser pour du web (j'ai un dédié) que pour de la gestion, des jeux etc... Et je ne change quasiment plus jamais de langage. Voilà ce qui ne serait pas possible en PHP. Cela est d'autant plus important pour des applications complexes où la partie interface web n'est qu'une toute petite partie. Java aurait très bien pu faire l'affaire, mais je l'ai laissé tomber pour des raisons de confort on va dire (et de phylosophie).

    Ensuite il y a tout un tas de petits avantages purement techniques (code plus propre, possibilité de se passer d'un serveur apache etc...) mais ça rentre dans le domaine du troll.

  • # Laisse moi rire ...

    Posté par  (site web personnel) . Évalué à 5.

    Ton journal pue la mauvaise foi jusqu'en Alaska.

    Déjà, si tu veux une application ou l'utilisateur entre des données et reçoit un résultat comme tu dis, je ne pense pas que ça soit plus compliqué en J2EE qu'avec PHP.

    form.jsp (je mets juste la partie intéressante du fichier) :

    <form action="result.jsp">
    Name : <input type="text" name="name">
    </form>

    result.jsp :

    Hello <%= request.getParameter("name") %> !


    Très complèxe non ? Après si tu veux faire ça proprement avec un modèle MVC et tout, forcément il faut que tu utilises un framework style struts. Ce n'est pas compliqué mais il faut le temps de se familiariser avec (de la même manière que si tu utilises un framework PHP).

    Maintenant, pour ce qui est de faire des choses en plus avec J2EE qu'avec PHP:

    Imaginons une application où l'utilisateur peut soumettre des requêtes (ce que tu veux comme requête, disons un l'envoie d'un calcul). La requête HTTP arrive sur la machine A, une base de donnée sur la machine B est mise à jour, puis A envoie le calcul via une message queue sur la machine C contenant le moteur de calcul. La main est rendue à l'utilisateur dès que le message est envoyé à C. Bien entendu tout ceci dans une même transaction distribuée et fault tolerant. Lorsque C a fini le calcul, A est automatiquement notifié (sans action de l'utilisateur) et met à jour le statut et le résultat dans B. L'utilisateur peut aussi consulter la liste des calculs envoyés et leur statut / résultat.

    Implémente ceci avec J2EE et avec PHP et donne nous le résultat.

    Je n'ai rien à ajouter.

    • [^] # Re: Laisse moi rire ...

      Posté par  . Évalué à -3.

      T'es cretin toi ou quoi ? c'est pas de la mauvaise foi, JE NE CONNAIS PAS BIEN J2EE !!!!!!!!!!!!

      je ne voyais donc pas bien son interet par rapport à une plateforme PHP/apache.

      Si tu avais un peu lu, tu aurais vu que justement, et aprés que des gens moins violant aient donné leurs avis, jai vu l'interet de J2EE (au moins un, et de taille) par rapport à une plateforme J2EE.

      et c'est justement ce que tu dis.

      Alors avant de gueuler, LIS.

      • [^] # Re: Laisse moi rire ...

        Posté par  (site web personnel) . Évalué à 5.

        Je sais bien que tu ne connais pas J2EE et j'ai suivi le thread où on a déjà expliqué 1000x en quoi J2EE et PHP n'étaient pas similaires.

        Après toutes les explications que tu as reçue, revenir en demandant "qu'est ce que J2EE à de plus", tout en laissant entendre qu'à part de la complexité, il n'y à rien, excuse moi mais c'est un minimum trollesque et plus probablement teinté d'un peu de mauvaise foi.

        • [^] # Re: Laisse moi rire ...

          Posté par  . Évalué à -2.

          non et justement, le truc c'est qu'en cherchant les differences on tombe soit sur des articles bien technique de 100 pages, soit sur des trolls justement, mais rien que je n'ai trouvé qui donne simplement une reponse claire, immédiatement comprehensible par le novice J2EE et qui soit quasi infaisable en PHP:

          C'est a dire la pesistance des processus.

    • [^] # Re: Laisse moi rire ...

      Posté par  . Évalué à 2.

      bon je me suis fais moinser, disons plus calmement que si tu avais lu le reste du journal, tu aurais vu que oui tu as raison, que non ce n'etait pas de la mauvaise foi, que tout simplement je n'avais pas concience de cette notion de persistance et qu'il suffit d'expliquer pour que je comprenne.

  • # Au dela du troll

    Posté par  . Évalué à 2.

    Chaque language a ses avantages.

    PHP est très rapide à apprendre. c'est la solution la plus répendu chez les hebergeurs pour pages perso (ou grand public). C'est rapide pour faire une page dynamique. Un grand nombre de projet libre l'utilise pour des wikis, album photos, et plein d'autres choses sympas.

    JAVA est plus puissant et surtout plus professionnel,
    mais également plus complexe à apprendre (c'est un language objet est non du script).
    La compatibilité et la pérténité des dev est très grande (compatibilité ascendante entre les versions et également norme J2EE entre les différents serveurs en plus bien sur du multiplateforme).
    C'est également un sujet très (trop ?) vaste qui en rebuttera plus d'un, mais qui est quand meme aujourd'hui devenu un standard de fait dans les grandes sociétés.


    Donc il suffit d'utiliser chaque language dans la situation qui lui convient.

    Un site Web dynamique développé par 3-4 personnes et hébergé par online: php

    Un site de banque en ligne qui envois des SMS de notification de découvert et doit être maintenable dans 5 ans: J2EE

  • # PS

    Posté par  (site web personnel) . Évalué à 6.

    On teste pas une plateforme comme J2EE en faisant un Hello World.

    Ensuite il n'y a sûrement pas grand chose que tu ne puisse pas faire en PHP par rapport à J2EE. Donc celà ne sert pas à grand chose d'essayer de trouver un exemple.

    J2EE est plus complexe que PHP, c'est un fait. Mais pourquoi ? Ils se sont amusés à compliquer J2EE pour enmerder le programmeur ? Ben non. C'est juste qu'il y a pleins de notions et de principes de fonctionnement à assimiler pour pouvoir faire de grosses applications (pas un hello world) sans avoir à tout re-concevoir, de nombreuses briques complexes mais bien utiles étant présentes en STANDARD (pooling, transactions, etc.) et surtout qui s'intègrent avec l'existant de façon élégante.

    On ne code pas (j'ai pas dis on peut pas) les composant métiers en PHP, PHP n'est qu'une façade et est fortement limité aux applications Web.

    Voilà, donc PHP peut être une alternative à J2EE lorsque l'application concernée est une application orientée web, qui n'a pas vraiment besoin de s'intégrer à un existant.
    Les pro-PHP ne comprennent pas ce que J2EE peut faire en plus (bah vi ils en ont jamais eu besoin), alros que les pro-J2EE voient clairement les limitations qu'apporte PHP.

    Après peut-être que PHP pourra plus tard prétendre concurrencer J2EE au niveau de l'intégration (grâce à Sun par exemple), mais en l'état actuel ces 2 plateformes ne sont comparables que sur une petit sous-ensemble d'application.

    Voilà, c'est mon avis et je le partage avec moi-même.

    • [^] # Re: PS

      Posté par  . Évalué à 1.

      il suffit d'expliquer a un pro-php comme moi et il peu comprendre.

      Je vois donc maintenant l'interet de cette plateforme et mes deux principale limitations qui sont celles de php.

      La première est la persistance des processsus coté serveurs. (la plus importante en fait)

      La deuxiement, l'interface graphique, rien n'est défini par defaut pour le faire en PHP. (tres contraignant aussi mais peut génant sans la premiere)

      la troisieme: Normalisation: briques metiers: maintenance etc ... ca je reste pour ma part, persuadé que ca dépend des équides de dev et du chef de projet. J'ai vu des usine à gaz impossible à maintenir ecrite en java (tres precisement la gestion des cartes a puces chez schlumberger) et truc fabuleux ecrit en java (application de surveillance et monitring réseau (clone de Patrol/HP openvien). Et j'ai également des truc fabuleux comme pourris ecrit en c,c++ fortran et meme perl. (je parle de grosse applis proprietaire, pas du site web du gamin du coin).

      Mais effectivement les deux premiers points n'ont pas d'equivalent viable a l'heure actuelle pour faire de grosse applis distribués et portable.

      • [^] # Re: PS

        Posté par  . Évalué à 2.

        > La première est la persistance des processsus coté serveurs.

        comment est-ce qu'on fait :

        - pour garder le meme processus utilisateur au fil des connexions,
        - sans pour autant saturer le serveur en memoire alloue
        - et ou processus ou thread systeme.

        sur un serveur peu chargé tout réside en memoire,cc'est parfait, il y a unicité enttre process et contexte utilisateur

        dans un contexte plus chargé, les sessions sont certainement déchargée sur le disque non ? du coup, cela se raproche etrangement de ce qui se fait de maniere un peu moins transparent en php. Mais ce n'est pas trop complexe a gerer tout de meme une session.

        • [^] # Re: PS

          Posté par  . Évalué à 1.

          Avec j2ee il doit y avoir des mécanismes hypers sophistiqués, style les sessions sur une machine séparée, en base de donnée etc...
          Mais sinon, plus simplement, le noyau (linux) sait très bien gérer ce genre de choses. (l'inverse aussi : ne pas aller chercher sur disque chaque script php).
          La différence sur un serveur c'est que c'est toi qui peut choisir ce qui doit rester en mémoire et ce qui ne doit pas...
          Ensuite, en java je sais pas, mais on peut faire un serveur asynchrone, dans ce cas il n'y a qu'un seul process et 1 ou 2 threads (voir twistedmatrix)

          • [^] # Re: PS

            Posté par  . Évalué à 0.

            > Avec j2ee il doit y avoir des mécanismes hypers sophistiqués, style les sessions sur une machine séparée, en base de donnée etc...

            c'est pour cela que je fais confiance a Linux et php ;-)

        • [^] # Re: PS

          Posté par  (site web personnel) . Évalué à 1.

          > - pour garder le meme processus utilisateur au fil des connexions

          Pas utile. Java utilise des threads qui partagent tous le même espace mémoire.

          > - sans pour autant saturer le serveur en memoire alloue

          La mémoire est partagée donc chaque thread ne consomme que la "stack" allouée par le noyau (4Ko je crois) + l'espace utilisé pour le TLS (thread local storage) (Voir aussi la classe ThreadLocal en java). En gros sur du noyau 2.6 c'est pas un pb. Sur du 2.4 sans NPTL c'est un peu moins drôle, mais on parle de java, pas de linux.

          > - et ou processus ou thread systeme.

          Voir les annonces d'Ingo Molnar quand NPTL a été mergé dans le noyau (100000 threads avec une latence très faible sur PIV monoproc). C'est sur qu'a une époque reculée (2.4 sans NTPL), à partir de 300 process le noyau linux ne bougait plus. Maintenant no-souci.

          En plus en java la bonne pratique est plutot de mettre le moins de choses possible dans la session et de consacrer ta ram a des caches LRU globaux pour éviter les requêtes en BD. En gros tu ne met quasiment rien dans la session et tu caches tout ce qui vient de la BD au niveau du serveur d'appli.

  • # Workflows

    Posté par  . Évalué à 2.

    J'ai une question sérieuse : comment spécifier et implémenter des workflows avec J2EE ? C'est plutôt du genre moteur greffé au serveur ou code à la mimine (généré au mieux) ?

    Je précise qu'il s'agit de workflows de type machine à état pour représenter un SI documentaire.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.