j'aimerais avoir quelques avis éclairés... et potentiellement différents de
celui des grands cabinets de conseil.
Pour un vraiment grand projet (genre 4000 utilisateurs simultanés, en
national) sur une application métier assez sophistiquée, je suis à peu près
contraint contractuellement sur une infrastructure J2EE - ce qui, quoi qu'il
en soit, est a priori adapté à la circonstance (sécurité, montée en charge
etc) et au budget (significatif). L'outil Eclipse sera vraisemblablement
utilisé pour le développement.
Ma question concerne la partie GUI.
J'ai envie d'inciter le groupe projet à étudier l'opportunité d'utiliser
PHP5 pour le développement des interfaces utilisateurs : il me semble à tort
ou à raison que celà aurait plusieurs avantages : rapport temps de
développement / qualité de l'interface finale favorable notamment.
Mais je m'interroge sur les inconvénients potentiels :
- est-ce une architecture exotique ?
- vais-je de toute façon devoir utiliser des applets Java pour les fonctions
client un peu trop complexes pour PHP qui est exécuté sur le serveur (si je
ne m'abuse) ?
- l'absence d'intelligence sur le client va t'elle me pénaliser ?
- est-ce que je vais plus perdre à mélanger deux langages qu'y gagner ?
etc etc
bref, est-ce farfelu de faire du J2EE pour les composants de base, et PHP
pour le front end ?
Oui.Sans utiliser d'xml pour communiquer entre les 2, je ne vois pas trop comment cela peut etre possible.
Il existe un nombre infini de manières pour communiquer entre les deux.
OK, il y a effectivement plusieurs façons de faire, mais sont-elles réalistes niveau temps de développement et performances ?
Pour le fun, je rajouterais bien une couche .NET entre les deux.
ça m'intéresserait de savoir comment tu instancies une classe java en PHP et réciproquement....
Avec les modules expérimentaux correspondants.
Le terme "expérimental" me pose problème sur une appli avec 4000 utilisateurs simultanés... T'aurais un lien pour ma culture ? Merci
John Gallet
Re,
Pour le fun, je rajouterais bien une couche .NET entre les deux. Facile : il suffit de mettre deux webservices entre les trois. Tu prends
de préférence des machines qui tournent sur 3 OS différents, situées à des emplacements physiques différents, avec des liaisons chiffrées sur TCP au lieu d'UDP ou même mieux une petite encapsulation de TCP/IP sur X25 pour une des liaisons et tu t'inscris dans la foulée aux Jeux Olympiques dans la catégorie "course à la rame" ;-)
Le terme "expérimental" me pose problème sur une appli avec 4000 utilisateurs simultanés...
C'est pile poil ce que j'en disais aussi. Enfin tout dépend de ce qu'elle fait (critique ou pas) et du temps de développement que ça gagne.
T'aurais un lien pour ma culture ? Le manuel au moins : http://fr2.php.net/manual/en/ref.java.php
Lionel, qui n'a tjs pas compris ce que php venait faire dans cette histoire...
Seul l'auteur de la question connait les flux de données qui entrent et sortent de cette application donc il est seul à pouvoir répondre, mais je te donne un exemple d'architecture : tu achètes/loues en license auprès d'un éditeur un schéma de base de données et des API en java qui te permettent d'alimenter en batch et/ou en temps réel cette base (flux de cotation et d'informations boursières par exemple). La base est donc maintenue à jour en INSERT/UPDATE/DELETE par du full java. Parallèlement, tu as envie de te faire des GUIs (aka "clickodromes" de consultation et des batchs d'extraction pour alimenter d'autre choses internes. Tu peux très bien ne pas disposer des APIs d'accès (parce qu'elles n'existent pas, parce qu'elles coûtent cher, parce qu'elles sont super complexes alors que tu en as besoin de 5%,... il y a plein de raisons possibles tout à fait recevables). Dans ce cadre là, tu pourrais parfaitement utiliser une autre technologie (PHP) pour tous les accès en lecture seule. En particulier si tu utilises déjà cette techno par ailleurs et que ton but est d'intégrer ces données dans un existant d'une techno différente. Une fois de plus (je vais finir par me la coller en signature, celle là) : à chaque problème technique la solution qui lui est la plus appropriée. On ne peut pas avoir d'a priori tant qu'on ne connait pas le cahier des charges et les flux in/out de l'application (et surtout, les API existantes permettant d'y accéder).
JG
Re,
Pour le fun, je rajouterais bien une couche .NET entre les deux.
Facile : il suffit de mettre deux webservices entre les trois. Tu prends
de préférence des machines qui tournent sur 3 OS différents, situées à
des emplacements physiques différents, avec des liaisons chiffrées sur
TCP au lieu d'UDP ou même mieux une petite encapsulation de TCP/IP sur
X25 pour une des liaisons et tu t'inscris dans la foulée aux Jeux
Olympiques dans la catégorie "course à la rame" ;-)
Le terme "expérimental" me pose problème sur une appli avec 4000
utilisateurs simultanés...
C'est pile poil ce que j'en disais aussi. Enfin tout dépend de ce
qu'elle fait (critique ou pas) et du temps de développement que ça
gagne.
T'aurais un lien pour ma culture ?
Le manuel au moins : http://fr2.php.net/manual/en/ref.java.php
Lionel, qui n'a tjs pas compris ce que php venait faire dans cette
histoire...
Seul l'auteur de la question connait les flux de données qui entrent et
sortent de cette application donc il est seul à pouvoir répondre, mais
je te donne un exemple d'architecture : tu achètes/loues en license
auprès d'un éditeur un schéma de base de données et des API en java qui
te permettent d'alimenter en batch et/ou en temps réel cette base (flux
de cotation et d'informations boursières par exemple). La base est donc
maintenue à jour en INSERT/UPDATE/DELETE par du full java.
Parallèlement, tu as envie de te faire des GUIs (aka "clickodromes" de
consultation et des batchs d'extraction pour alimenter d'autre choses
internes. Tu peux très bien ne pas disposer des APIs d'accès (parce
qu'elles n'existent pas, parce qu'elles coûtent cher, parce qu'elles
sont super complexes alors que tu en as besoin de 5%,... il y a plein de
raisons possibles tout à fait recevables). Dans ce cadre là, tu pourrais
parfaitement utiliser une autre technologie (PHP) pour tous les accès en
lecture seule. En particulier si tu utilises déjà cette techno par
ailleurs et que ton but est d'intégrer ces données dans un existant
d'une techno différente. Une fois de plus (je vais finir par me la
coller en signature, celle là) : à chaque problème technique la solution
qui lui est la plus appropriée. On ne peut pas avoir d'a priori tant
qu'on ne connait pas le cahier des charges et les flux in/out de
l'application (et surtout, les API existantes permettant d'y accéder).
Pour le fun, je rajouterais bien une couche .NET entre les deux. Facile : il suffit de mettre deux webservices entre les trois. Tu prends
de préférence des machines qui tournent sur 3 OS différents, situées à des emplacements physiques différents, avec des liaisons chiffrées sur TCP au lieu d'UDP ou même mieux une petite encapsulation de TCP/IP sur X25 pour une des liaisons et tu t'inscris dans la foulée aux Jeux Olympiques dans la catégorie "course à la rame" ;-)
Le terme "expérimental" me pose problème sur une appli avec 4000 utilisateurs simultanés...
C'est pile poil ce que j'en disais aussi. Enfin tout dépend de ce qu'elle fait (critique ou pas) et du temps de développement que ça gagne.
T'aurais un lien pour ma culture ? Le manuel au moins : http://fr2.php.net/manual/en/ref.java.php
Lionel, qui n'a tjs pas compris ce que php venait faire dans cette histoire...
Seul l'auteur de la question connait les flux de données qui entrent et sortent de cette application donc il est seul à pouvoir répondre, mais je te donne un exemple d'architecture : tu achètes/loues en license auprès d'un éditeur un schéma de base de données et des API en java qui te permettent d'alimenter en batch et/ou en temps réel cette base (flux de cotation et d'informations boursières par exemple). La base est donc maintenue à jour en INSERT/UPDATE/DELETE par du full java. Parallèlement, tu as envie de te faire des GUIs (aka "clickodromes" de consultation et des batchs d'extraction pour alimenter d'autre choses internes. Tu peux très bien ne pas disposer des APIs d'accès (parce qu'elles n'existent pas, parce qu'elles coûtent cher, parce qu'elles sont super complexes alors que tu en as besoin de 5%,... il y a plein de raisons possibles tout à fait recevables). Dans ce cadre là, tu pourrais parfaitement utiliser une autre technologie (PHP) pour tous les accès en lecture seule. En particulier si tu utilises déjà cette techno par ailleurs et que ton but est d'intégrer ces données dans un existant d'une techno différente. Une fois de plus (je vais finir par me la coller en signature, celle là) : à chaque problème technique la solution qui lui est la plus appropriée. On ne peut pas avoir d'a priori tant qu'on ne connait pas le cahier des charges et les flux in/out de l'application (et surtout, les API existantes permettant d'y accéder).
JG
Thierry Boudet
On 2005-05-24, Lionel wrote:
bref, est-ce farfelu de faire du J2EE pour les composants de base, et PHP pour le front end ? Oui.Sans utiliser d'xml pour communiquer entre les 2, je ne vois pas trop
comment cela peut etre possible.
En informatique, quand tu as un problème, il y a toujours quelqu'un qui suggère le remède XML.
A ce moment, tu as deux problèmes.
-- _/°< coin
On 2005-05-24, Lionel <SPAMcoollATfreePOINTfr@news.free.fr> wrote:
bref, est-ce farfelu de faire du J2EE pour les composants de base,
et PHP pour le front end ?
Oui.Sans utiliser d'xml pour communiquer entre les 2, je ne vois pas trop
comment cela peut etre possible.
En informatique, quand tu as un problème, il y a toujours
quelqu'un qui suggère le remède XML.
bref, est-ce farfelu de faire du J2EE pour les composants de base, et PHP pour le front end ? Oui.Sans utiliser d'xml pour communiquer entre les 2, je ne vois pas trop
comment cela peut etre possible.
En informatique, quand tu as un problème, il y a toujours quelqu'un qui suggère le remède XML.
A ce moment, tu as deux problèmes.
-- _/°< coin
Lionel
Thierry Boudet wrote:
En informatique, quand tu as un problème, il y a toujours quelqu'un qui suggère le remède XML. A ce moment, tu as deux problèmes.
Tiens, encore qqun qui a lu une phrase qui lui a plu et que la ressort à toutes les sauces même quand elle n'a rien à voir avec le post original. Je n'ai en aucun cas suggéré d'utiliser xml, c'est plutot l'inverse.
Thierry Boudet wrote:
En informatique, quand tu as un problème, il y a toujours
quelqu'un qui suggère le remède XML.
A ce moment, tu as deux problèmes.
Tiens, encore qqun qui a lu une phrase qui lui a plu et que la ressort à
toutes les sauces même quand elle n'a rien à voir avec le post original.
Je n'ai en aucun cas suggéré d'utiliser xml, c'est plutot l'inverse.
En informatique, quand tu as un problème, il y a toujours quelqu'un qui suggère le remède XML. A ce moment, tu as deux problèmes.
Tiens, encore qqun qui a lu une phrase qui lui a plu et que la ressort à toutes les sauces même quand elle n'a rien à voir avec le post original. Je n'ai en aucun cas suggéré d'utiliser xml, c'est plutot l'inverse.
Thierry Boudet
On 2005-05-30, Lionel wrote:
Thierry Boudet wrote:
En informatique, quand tu as un problème, il y a toujours quelqu'un qui suggère le remède XML. A ce moment, tu as deux problèmes.
Tiens, encore qqun qui a lu une phrase qui lui a plu et que la ressort à toutes les sauces même quand elle n'a rien à voir avec le post original.
Pas avec le post original, mais avec celui-ci: ---------------- Message-ID: <42933cbb$0$10512$
La seule technologie qui pourrait faire passerelle entre des composants J2EE et un script PHP c'est xml. ----------------
-- _/°< coin
On 2005-05-30, Lionel <SPAMcoollATfreePOINTfr@news.free.fr> wrote:
Thierry Boudet wrote:
En informatique, quand tu as un problème, il y a toujours
quelqu'un qui suggère le remède XML.
A ce moment, tu as deux problèmes.
Tiens, encore qqun qui a lu une phrase qui lui a plu et que la ressort à
toutes les sauces même quand elle n'a rien à voir avec le post original.
Pas avec le post original, mais avec celui-ci:
----------------
Message-ID: <42933cbb$0$10512$636a15ce@news.free.fr>
La seule technologie qui pourrait faire passerelle entre des composants J2EE
et un script PHP c'est xml.
----------------
En tronquant tout le contexte, on peut faire dire n'importe quoi à n'importe qui.
FU2.
Spot
Lionel disait le 26/05/2005 09:55:
ça m'intéresserait de savoir comment tu instancies une classe java en PHP et réciproquement....
Avec les modules expérimentaux correspondants.
Le terme "expérimental" me pose problème sur une appli avec 4000 utilisateurs simultanés... T'aurais un lien pour ma culture ? Merci
Salut, perso je bosse sur un projet php5 + java ou j'interface des classes j ava grace a ca : http://php-java-bridge.sourceforge.net/ (JSR 223) et ca marche super bien. Apres je ne sais effectivement pas ce que ca peut donner sur une appli enormement solicitée, mais en tout cas, j'ai été carrement bluffé par les temps de reponse de ce fameux bridge, une fois que la VM java est chargée et residente, ca depote mechant. a coté l'extension java de php4 fait doucement rigoler.
Voilou
A ++ xavier
PS: je viens de voir qu'il y a meme un bridge .NET maintenant, il y en a a qui ca va encore donner des idées ;)
Lionel disait le 26/05/2005 09:55:
ça m'intéresserait de savoir comment tu instancies une classe java
en PHP et réciproquement....
Avec les modules expérimentaux correspondants.
Le terme "expérimental" me pose problème sur une appli avec 4000
utilisateurs simultanés...
T'aurais un lien pour ma culture ?
Merci
Salut,
perso je bosse sur un projet php5 + java ou j'interface des classes j
ava grace a ca : http://php-java-bridge.sourceforge.net/ (JSR 223) et ca
marche super bien. Apres je ne sais effectivement pas ce que ca peut
donner sur une appli enormement solicitée, mais en tout cas, j'ai été
carrement bluffé par les temps de reponse de ce fameux bridge, une fois
que la VM java est chargée et residente, ca depote mechant. a coté
l'extension java de php4 fait doucement rigoler.
Voilou
A ++
xavier
PS: je viens de voir qu'il y a meme un bridge .NET maintenant, il y en a
a qui ca va encore donner des idées ;)
ça m'intéresserait de savoir comment tu instancies une classe java en PHP et réciproquement....
Avec les modules expérimentaux correspondants.
Le terme "expérimental" me pose problème sur une appli avec 4000 utilisateurs simultanés... T'aurais un lien pour ma culture ? Merci
Salut, perso je bosse sur un projet php5 + java ou j'interface des classes j ava grace a ca : http://php-java-bridge.sourceforge.net/ (JSR 223) et ca marche super bien. Apres je ne sais effectivement pas ce que ca peut donner sur une appli enormement solicitée, mais en tout cas, j'ai été carrement bluffé par les temps de reponse de ce fameux bridge, une fois que la VM java est chargée et residente, ca depote mechant. a coté l'extension java de php4 fait doucement rigoler.
Voilou
A ++ xavier
PS: je viens de voir qu'il y a meme un bridge .NET maintenant, il y en a a qui ca va encore donner des idées ;)
