[Experts] Norme CORBA (IIOP) en PHP

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : [Experts] Norme CORBA (IIOP) en PHP

par zeus » 25 févr. 2008, 17:41

Vu ce qu'annonce la PHP Team, je ne pense que que CORBA sur PHP ais un avenir sur PHP ...

Je pense qu'implémenter une interface CORBA pour PHP permettrai surtout de découvrir le dessous de son fonctionnement, et éventuellement de se mettre le pied à l'étrier pour d'autres langages (comme le Java)

par Hywan » 25 févr. 2008, 17:26

Surtout que XML-RPC est très bien intégré à PHP. Je pense notamment aux paquetages de PEAR qui est très bien écrit et très performant (celui de Hoa aussi normalement ^^ il est plus modulaire que celui de PEAR).

Enfin bref, les solutions ne manquent pas en XML-RPC.
Néanmoins, j'aimerais savoir si CORBA a encore un avenir devant lui ou pas ? C'est plus rapide que XML-RPC j'imagine (c'est même sûr). Tu pourrais me faire un petit comparatif rapide ? Car ça m'intéresse, et si CORBA a encore un avenir devant lui, alors je pourrai imaginer programmer une interface pour PHP.

par zeus » 25 févr. 2008, 15:48

la couche de transformation des instances PHP est flux IIOP (flux de données utilisé par CORBA) n'est pas implémentée en PHP, et je ne me sens pas de partir dans ce développement :?
Ca dépend, ce serait long ou compliqué (le cummule n'est pas autorisé ;-)) ?
Surtout long et donc couteux :?
Si la norme est écrite clairement et sans ambiguïté, ça se fait. PHP 5 utilise pas ultra bien la réflexion (introspection), mais suffisament pour faire des merveilles. Si Java implémente CORBA, on n'a a travailler que sur PHP, ça évite déjà la moitié du boulot ;-)
Effectivement, je suis bien d'accord avec toi, et juste pour le sport, à titre privée, ça serait un beau challenge. Or, je ne suis pas sûr que mes supérieurs soient d'accord pour m'accorder des développeurs pendant quelques semaines pour développer une couche CORBA en PHP ;)

Visiblement, vu les réponses, soit on utilise PHP/Perl, soit on va finalement faire du XML/RPC

par Hywan » 25 févr. 2008, 15:44

la couche de transformation des instances PHP est flux IIOP (flux de données utilisé par CORBA) n'est pas implémentée en PHP, et je ne me sens pas de partir dans ce développement :?
Ca dépend, ce serait long ou compliqué (le cummule n'est pas autorisé ;-)) ? Si la norme est écrite clairement et sans ambiguïté, ça se fait. PHP 5 utilise pas ultra bien la réflexion (introspection), mais suffisament pour faire des merveilles. Si Java implémente CORBA, on n'a a travailler que sur PHP, ça évite déjà la moitié du boulot ;-).

Mais l'idée de Perl est également très intéressante, j'y jette un oeil :).

par zeus » 25 févr. 2008, 14:16

Tout à fait, et je te remercie de l'avoir lancée ...

C'est à coup d'idée que l'on avance ;)

par momox » 25 févr. 2008, 14:10

Sinon, développer mon propre principe de sérialisation (comme toute couche développée par mes soins) est une solution que je voudrais repousser le plus possible car cela rajoute une couche non-compilée et donc par définition plus lente.
Ce n'étais qu'une idée ;)

par zeus » 25 févr. 2008, 14:08

Effectivement, le principe sous-jasent est de vérifier que les objets transmis valide une interface commune à 2 langages.

Sinon, développer mon propre principe de sérialisation (comme toute couche développée par mes soins) est une solution que je voudrais repousser le plus possible car cela rajoute une couche non-compilée et donc par définition plus lente.

par momox » 25 févr. 2008, 13:57

Globalement, tu as une classe en php et une classe en java qui fonctionnent de la même manière ?
Interopérabilité des langages, pas mal, pas mal :D
Et avec une sorte de sérialize qui fonctionnerait avec la même syntaxe en java et en php ?

par zeus » 25 févr. 2008, 13:24

@Berzemus: Merci pour ces liens, j'avoue que je n'y avais pas pensé :oops:
Je regarde ça avec intérêt ;)

@momox: CORBA est une norme, pas un langage. Le principe est que le client lance une requête en transmettant des objets, que le serveur récupère ces objets et les utilises pour son traitement puis réponde lui même des objets instanciés.
L'énorme avantage de CORBA, c'est qu'il est possible de ne pas avoir le même langage sur le client et sur le serveur, mais de manipuler des objets instanciés tout de même.
Or, comme le dit Berzemus, la couche de transformation des instances PHP est flux IIOP (flux de données utilisé par CORBA) n'est pas implémentée en PHP, et je ne me sens pas de partir dans ce développement :?

En tout cas, merci à tous pour vos idées et votre participation qui m'aide pas mal :pouce:

par Berzemus » 25 févr. 2008, 12:16

de ce que j'ai pu glaner en suivant la discussion avec intérêt, CORBA a connu son instant de gloire juste avant que le web ne posa son (immense) cul sur le devant de la scène, provoquant la chute rapide quasi-instantanée de corba (perçu jusque la comme le nouveau graal). PHP n'a donc plus connu cette époque, et les maigres efforts (j'ai retrouvé les mêmes) sont restés vains, puisque le coeur n'y était plus.

Mais d'autres langages (et je pense très fort à Perl) ont, a ce qu'il paraît, un support efficace de corba (petit lien). Et vu l'intégration possible entre perl et php petit lien au hasard, c'est peut-être une voie possible..

maintenant, je m'y connais ni en perl, ni en java, ni en corba, ni en cuisine sud-américaine, alors bon.. mais ce serait fun :twisted:

par momox » 25 févr. 2008, 11:54

Globalement, quel est le principe de ce CORBA ?
Si j'a bien compris ce que tu cherches a résumer, tu as une machine, sur laquelle tu vas faire tourner une applicatoin java qui va te renvoyer des données, sous quel format, je ne sais pas.
Ton but a toi, c'est de récuperer ensuite ces données sous PHP et de pouvoir les exploiter ?

A partir de ca, on peut voir deux choses.
Comment PHP va récuperer ces données ? (sockets, fonction particulière d'un module tierce partie particulier, ...)
Comment PHP va traiter ces données ? (parseur ou fonction particulière d'un module tierce partie particulier)

Quelles sont les solutions que tu envisageais avec les divers modules que tu avais cités dans ton premier post ?

par iclo » 25 févr. 2008, 01:37

J'ai dû utiliser du Corba en Java, à une époque, c'est vrai que c'est assez puissant, et que cela semble convenir très bien à ce que tu dois faire.
Mais visiblement, comme tu l'as dit, il y a pas grand chose comme projet de corba sous php disponible.

Je ne sais pas si RMI est mieux loti ?

Bonne continuation en tout cas ;)

par Hywan » 25 févr. 2008, 01:14

Si en plus tu veux faire du sharding ... T'es pas simple hein :lol:.

par zeus » 25 févr. 2008, 01:08

Une réponse n'est jamais idiote, elle permet toujours de voir des choses différentes.

Sinon, comme pour momox, cette solution ne me convient pas dans le sens où elle permet de faire communiquer Java et PHP lors de l'exécution d'un même processus.
Alors que j'aimerais faire communiquer 2 processus sur 2 machines différentes ;)

par Jules Petibidon » 25 févr. 2008, 00:57

Hello,

Réponse sans doute idiote vu comme elle est facile mais ça suffit pas ça ?
http://www.php.net/manual/fr/ref.java.php