Discussion :

[Jean_Benoit]

Bonjour,

Comment intégrer du code Java dans du code PHP?

[benwit]

Qu'entends tu par intégrer du code Java dans du code PHP ?

Le pages PHP (langage interprété) sont traités par le "serveur PHP" pour retourner du code html.
Les JSP sont transformés en servlet par le serveur Java puis executées pour retourner du code html.
Quand au code Java, compilé en bytecode par 'javac', ce bytecode est executée par une JVM.

Si tu as des pages PHP, des pages JSP, un serveur PHP et un serveur Java, tu peux à mon avis appeler une page JSP à partir d'une page PHP et vice versa via l'utilisation des URL.

Eventuellement, mais je ne connais pas assez php (à confirmer donc), tu peux peut être faire un appel système en PHP (sur le serveur) pour executer un bout de code Java.

A ma connaissance, tu ne peux faire autre chose.
Maintenant, tu peux vouloir aussi convertir du code Java en code PHP ?
Je ne sais pas s'il existe un convertisseur ? mais je te souhaite bon courage.

[Jean_Benoit]

Merci pour ces infos.
Du coup je voudrais bien voir le xhtml généré par un source php, faut peut-être inclure un flag du genre -verbose?
Jai tenté "enregistrer la page sous..", mais je récupère que les données finales.
En fait mon souci c'est le problème des sessions multiples en php/xhtml qui accèdent à une même ligne en mysql, comment faire un lock pour éviter les doubles mises à jour avant commit, j'ai bien récupéré un lien sur un source php juste pour ça, mais je me disais qu'en Java la gestion des verrous est plus simple, j'ai vu des exemples avec les threads.
De plus il y a aussi le problème des résultats de query volatiles, c'est à dire qu'il faut rééxécuter la query chaque fois qu'on rafraîchit ou change de page, parce que les résultats sont de type "resource" , là aussi Java serait bien utile pour créer un tampon paginable, genre les résultats sont conservé en ram ou écrits sur disque selon la disponibilité des ressources système.

[benwit]

Il faut distinguer de choses dans une application web qui repose sur une architecture client/serveur.

Le serveur (la même ou plusieurs machines pour les différents serveurs) :
- serveur web qui retourne les pages statiques (html, css, js, ...), les images, sons, ... ou les pages dynamiques après les avoir demandé au
- serveur d'application qui fabriques des pages (html, xml, ...) à partir de données qui se trouve dans des fichiers ou à partir des données fournies par un
- serveur de base de données qui contient des données dans des tables, ...

Le client (ou plutôt devrai-je dire les clients) qui sont les navigateurs web (firefox, ie, ...) sur les pc des utilisateurs.

Les clients envoient des requetes HTTP au serveur WEB qui retourne une réponse.

Une fois qu'on se représente mieux le fonctionnement.
Il faut comprendre que les JSP sont interprétés par un serveur d'application (Tomcat, WebSphere, ...) et les php par un serveur php (je ne sais pas si on parle de serveur d'app dans ce cas mais le principe est le même) qui retourne leur résultat.
C'est pour cela qu'un client en affichant le code source de la page ou en l'enregistrant sur son disque dur ne verra jamais le code source php ou jsp mais uniquement le résultat généré ! (même si l'url indique .jsp ou .php qui sert uniquement au serveur)


Pour la suite, je parlerai uniquement de ce que je connais le mieux : Java.

Lorsque chacun des clients se connecte au serveur, généralement, chacun d'eux dispose de leur propre session. Pour éviter le problème que tu soulignes, il faut que dans le code java, les insertions en bdd se fassent dans des transactions. J'imagine qu'il en est de même en php.

Pour ce qui est du problème de rééxécution à chaque rechargement, c'est du au processus même de communication qui est synchrone.

• Le client envoit une requête (HTTP) au serveur Web/App
  Le serveur Web/App envoit une requete SQL au serveur de BDD
  Le serveur de BDD retourne le resultat de la requete SQL au serveur Web/App.
  Le serveur Web/App retourne une page fabriquée avec ces données au client.

Pour chaque client, la requete est rééxécutée à chaque fois et pour un même client, elle est rééxécutée à chaque rechargement de la page.
Maintenant, il est possible comme tu dis, de stocker des résultats en session sur le serveur (RAM) ou sur disque (CACHE) mais il faut être conscient que ça peut vite devenir problématique coté serveur (1 session à 1Mo) sera multiplé par 1000 si tu as 1000 clients, etc ...

C'est pour éviter d'avoir à recharger la page en totalité (page qui repose par exemple sur plusieurs requetes SQL) et pour permettre une communication asynchrone que s'est développée AJAX (Javacript + XML coté client).

Pour conclure, je te dirai qu'il existe en Java des solutions à tes problèmes. Maintenant, je serai étonné qu'il n'existe pas le même genre de solution en PHP car par exemple, AJAX est également utilisable en PHP.

[MrEddy]

On peut integrer du java dans des pages php, mais personellement je n'ai pas réussi vraiment a l'utiliser. Mon script java fonctionnait une seule fois et ensuite obligé de redemarrer les serveurs web pour refaire fonctionner les appels de fonction java dans du php.

cf: http://fr3.php.net/manual/fr/ref.java.php

[Jean_Benoit]

Là tu soulèves le problème de la distinction entre application client-serveur et application internet/intranet. Pourrais-t-on dire que dès que le client est un browser, on est en intranet? L'utilisation de PHP/Xhtml permet de standardiser les interfaces (à condition que tout le monde utilise Internet Explorer) (( les concepteurs de xhtml ont prévu des forms pour dialoguer avec une base de données, malheureusement, il se sont limités au formulaire maître, si on veut le formulaire détails il faut passer par des solutions commerciales genre Micro Olap)). Alors qu'avec Java, on est en propriétaire. PHP 5 présente des possibilités objet. D'où le débat: PHP ou Java?
J'ai bien bossé sur Java mais malheureusement je ne vois pas du tout comment modéliser en oo, alors qu'en relationnel, c'est limpide.
Sinon j'ai vu qu'il existe déjà des xdbms basés sur XML.
Merci pour les infos sur AJAX, j'aurai pas à réinventer la roue.

[benwit]

Pour moi, le client-serveur est avant tout une architecture. Le client peut être lourd (desktop, ex : Swing) ou léger (browser, ex : IE).

Une application web repose sur ce type d'architecture (on parle de n-tiers suivant le nombre de serveur : serveur web, d'application, de bdd, vidéo, ...)

Bien entendu, on peut faire tourner l'application sur un pc et avoir le browser qui affiche l'interface. Cela n'en reste pas moins à mon sens une application client/serveur même si le client et le serveur sont sur la même machine.

Pour moi, dès qu'un client est un broswer, je dis qu'on a affaire à une application web.
Un intranet est un ensemble de services internet (par exemple un serveur web) internes à un réseau local, c'est-à-dire accessibles uniquement à partir des postes d'un réseau local, ou bien d'un ensemble de réseaux bien définis, et invisible de l'extérieur.

C'est vrai que la modélisation d'une application Web en OO est moins limpide. Pour moi, cela vient du fait que la plupart du temps (pour ne pas dire toujours), la persistance des objets se fait dans un sgbdr et qu'à un moment ou à un autre, il faut un mapping objet/relationnel.