J'aimerais savoir comment il serait possible de faire communiquer une appli
JAVA et un script Python, est ce que je peux utiliser des méthodes type
sémaphore ou socket (comme en C ) sur des plateformes Windows ? De plus je
ne peux pas utiliser jython car je suis obligé de me servir d'un interpréter
python.
J'ai pensé a faire des écritures / lectures successives mais étant donné que
le flux d'informations à transférer est important et il doit être instantané
ça parait difficile
J'aimerais savoir comment il serait possible de faire communiquer une appli JAVA et un script Python, est ce que je peux utiliser des méthodes type sémaphore ou socket (comme en C ) sur des plateformes Windows ?
"Sémaphore"? Comment tu transfère des infos d'un programme à un autre par un sémaphore? Ca sert juste à le synchro, non? Donc à part transférer un simple événement, je ne vois pas ce que tu peux faire d'autre...
J'ai pensé a faire des écritures / lectures successives mais étant donné que le flux d'informations à transférer est important et il doit être instantané ça parait difficile
"Flux important" et "instantané" risquent de se révéler etre des contraintes contradictoires...
Cela dit, sous Windows, j'ai utilisé avec succès les pipes nommés (si, si, ça existe; c'est un peu étrange quand on est habitué aux pipes nommés Unix, mais ça marche). Ca s'utilise assez simplement en Python via les routines de win32api (win32pipe pour etre précis); par contre, en Java, je ne sais pas du tout si on peut y accéder. Vu la philosophie de Java, ça m'étonnerait un peu, mais on ne sait jamais.
Sinon, il y a toujours des solutions portables et qui ne demandent pas beaucoup d'efforts: - XML-RPC [ http://www.xmlrpc.com/ ]: "built-in" dans les versions récentes de Python; dispo sans problème en Java. Pas franchement rapide (c'est quand meme construit au dessus du protocole http, donc ça demande à avoir un serveur Web et tout le tintouin...) - CORBA: j'ai jadis fait communiquer des applis Python <-> Java via CORBA avec Fnorb du coté Python [ http://www.fnorb.org ] et JacORB du coté Java [ http://www.jacorb.org ]. Ca marche, c'est facile, mais pour le coté instantané, c'est pas vraiment ça... Cela dit, c'est loin d'etre catastrophique, et il existe sans doute des ORB plus performants que ces deux-là. Pour plus d'infos sur ce qui est dispo voir http://www.objenv.com/cetus/oo_object_request_brokers.html ou http://www.puder.org/corba/matrix - ICE [ http://www.zeroc.com/ice.html ]: se propose comme une alternative plus légère à CORBA avec à peu près les memes fonctionnalités; ça a l'air interessant, ça fait ce que tu veux, mais je n'ai jamais essayé.
Tout ça évite de se bricoler une interface socket perso, qui risque de moins bien marcher pour des perfs équivalentes. Mais je le répète: transférer beaucoup d'info de programme à programme ne peut pas se faire sans impact sur les perfs...
HTH - Eric Brunel -
On Wed, 23 Feb 2005 21:19:26 +0100, Jack <jack@jack.com> wrote:
Bonjour,
J'aimerais savoir comment il serait possible de faire communiquer une appli
JAVA et un script Python, est ce que je peux utiliser des méthodes type
sémaphore ou socket (comme en C ) sur des plateformes Windows ?
"Sémaphore"? Comment tu transfère des infos d'un programme à un autre par un sémaphore? Ca sert juste à le synchro, non? Donc à part transférer un simple événement, je ne vois pas ce que tu peux faire d'autre...
J'ai pensé a faire des écritures / lectures successives mais étant donné que
le flux d'informations à transférer est important et il doit être instantané
ça parait difficile
"Flux important" et "instantané" risquent de se révéler etre des contraintes contradictoires...
Cela dit, sous Windows, j'ai utilisé avec succès les pipes nommés (si, si, ça existe; c'est un peu étrange quand on est habitué aux pipes nommés Unix, mais ça marche). Ca s'utilise assez simplement en Python via les routines de win32api (win32pipe pour etre précis); par contre, en Java, je ne sais pas du tout si on peut y accéder. Vu la philosophie de Java, ça m'étonnerait un peu, mais on ne sait jamais.
Sinon, il y a toujours des solutions portables et qui ne demandent pas beaucoup d'efforts:
- XML-RPC [ http://www.xmlrpc.com/ ]: "built-in" dans les versions récentes de Python; dispo sans problème en Java. Pas franchement rapide (c'est quand meme construit au dessus du protocole http, donc ça demande à avoir un serveur Web et tout le tintouin...)
- CORBA: j'ai jadis fait communiquer des applis Python <-> Java via CORBA avec Fnorb du coté Python [ http://www.fnorb.org ] et JacORB du coté Java [ http://www.jacorb.org ]. Ca marche, c'est facile, mais pour le coté instantané, c'est pas vraiment ça... Cela dit, c'est loin d'etre catastrophique, et il existe sans doute des ORB plus performants que ces deux-là. Pour plus d'infos sur ce qui est dispo voir http://www.objenv.com/cetus/oo_object_request_brokers.html ou http://www.puder.org/corba/matrix
- ICE [ http://www.zeroc.com/ice.html ]: se propose comme une alternative plus légère à CORBA avec à peu près les memes fonctionnalités; ça a l'air interessant, ça fait ce que tu veux, mais je n'ai jamais essayé.
Tout ça évite de se bricoler une interface socket perso, qui risque de moins bien marcher pour des perfs équivalentes. Mais je le répète: transférer beaucoup d'info de programme à programme ne peut pas se faire sans impact sur les perfs...
J'aimerais savoir comment il serait possible de faire communiquer une appli JAVA et un script Python, est ce que je peux utiliser des méthodes type sémaphore ou socket (comme en C ) sur des plateformes Windows ?
"Sémaphore"? Comment tu transfère des infos d'un programme à un autre par un sémaphore? Ca sert juste à le synchro, non? Donc à part transférer un simple événement, je ne vois pas ce que tu peux faire d'autre...
J'ai pensé a faire des écritures / lectures successives mais étant donné que le flux d'informations à transférer est important et il doit être instantané ça parait difficile
"Flux important" et "instantané" risquent de se révéler etre des contraintes contradictoires...
Cela dit, sous Windows, j'ai utilisé avec succès les pipes nommés (si, si, ça existe; c'est un peu étrange quand on est habitué aux pipes nommés Unix, mais ça marche). Ca s'utilise assez simplement en Python via les routines de win32api (win32pipe pour etre précis); par contre, en Java, je ne sais pas du tout si on peut y accéder. Vu la philosophie de Java, ça m'étonnerait un peu, mais on ne sait jamais.
Sinon, il y a toujours des solutions portables et qui ne demandent pas beaucoup d'efforts: - XML-RPC [ http://www.xmlrpc.com/ ]: "built-in" dans les versions récentes de Python; dispo sans problème en Java. Pas franchement rapide (c'est quand meme construit au dessus du protocole http, donc ça demande à avoir un serveur Web et tout le tintouin...) - CORBA: j'ai jadis fait communiquer des applis Python <-> Java via CORBA avec Fnorb du coté Python [ http://www.fnorb.org ] et JacORB du coté Java [ http://www.jacorb.org ]. Ca marche, c'est facile, mais pour le coté instantané, c'est pas vraiment ça... Cela dit, c'est loin d'etre catastrophique, et il existe sans doute des ORB plus performants que ces deux-là. Pour plus d'infos sur ce qui est dispo voir http://www.objenv.com/cetus/oo_object_request_brokers.html ou http://www.puder.org/corba/matrix - ICE [ http://www.zeroc.com/ice.html ]: se propose comme une alternative plus légère à CORBA avec à peu près les memes fonctionnalités; ça a l'air interessant, ça fait ce que tu veux, mais je n'ai jamais essayé.
Tout ça évite de se bricoler une interface socket perso, qui risque de moins bien marcher pour des perfs équivalentes. Mais je le répète: transférer beaucoup d'info de programme à programme ne peut pas se faire sans impact sur les perfs...
HTH - Eric Brunel -
Do Re Mi chel La Si Do
Bonjour !
bricoler une interface socket perso, qui risque de moins bien marcher pour des perfs équivalentes
Heu... J'ai lu, récemment un test comparatif des performances, qui montrait que les traitements raw_socket étaient entre 50 à 80 fois plus rapide qu'XML-RPC ; et 200 à 300 fois plus rapides que SOAP. CORBA s'en sortait mieux, étant, seulement, 2 à 3 fois plus lent.
Et, quand on voit la facilité d'utilisation des sockets, avec Python...
A titre d'info, pour un usage inter-applications sur un même poste, passer par des sockets est quand même 500 fois plus lent qu'utiliser COM, selon des tests perso. Mais COM n'est pas toujours facile, et reste purement windows.
@-salutations -- Michel Claveau
Bonjour !
bricoler une interface socket perso, qui risque de moins bien marcher
pour des perfs équivalentes
Heu... J'ai lu, récemment un test comparatif des performances, qui montrait
que les traitements raw_socket étaient entre 50 à 80 fois plus rapide
qu'XML-RPC ; et 200 à 300 fois plus rapides que SOAP.
CORBA s'en sortait mieux, étant, seulement, 2 à 3 fois plus lent.
Et, quand on voit la facilité d'utilisation des sockets, avec Python...
A titre d'info, pour un usage inter-applications sur un même poste, passer
par des sockets est quand même 500 fois plus lent qu'utiliser COM, selon des
tests perso. Mais COM n'est pas toujours facile, et reste purement windows.
bricoler une interface socket perso, qui risque de moins bien marcher pour des perfs équivalentes
Heu... J'ai lu, récemment un test comparatif des performances, qui montrait que les traitements raw_socket étaient entre 50 à 80 fois plus rapide qu'XML-RPC ; et 200 à 300 fois plus rapides que SOAP. CORBA s'en sortait mieux, étant, seulement, 2 à 3 fois plus lent.
Et, quand on voit la facilité d'utilisation des sockets, avec Python...
A titre d'info, pour un usage inter-applications sur un même poste, passer par des sockets est quand même 500 fois plus lent qu'utiliser COM, selon des tests perso. Mais COM n'est pas toujours facile, et reste purement windows.
@-salutations -- Michel Claveau
Franck Pommereau
Eric Brunel wrote:
Sinon, il y a toujours des solutions portables et qui ne demandent pas beaucoup d'efforts:
J'ajouterai D-Bus (http://freedesktop.org/wiki/Software_2fdbus) qui est vraiment facile à utiliser. Il transporte les données en binaire, ce qui est plus efficace que la plupart des systèmes qui sérialisent (en contrepartie, ce n'est pas forcément portable sans précaution entre différentes architectures matérielles).
Franck
Eric Brunel wrote:
Sinon, il y a toujours des solutions portables et qui ne demandent pas
beaucoup d'efforts:
J'ajouterai D-Bus (http://freedesktop.org/wiki/Software_2fdbus) qui est
vraiment facile à utiliser. Il transporte les données en binaire, ce qui
est plus efficace que la plupart des systèmes qui sérialisent (en
contrepartie, ce n'est pas forcément portable sans précaution entre
différentes architectures matérielles).
Sinon, il y a toujours des solutions portables et qui ne demandent pas beaucoup d'efforts:
J'ajouterai D-Bus (http://freedesktop.org/wiki/Software_2fdbus) qui est vraiment facile à utiliser. Il transporte les données en binaire, ce qui est plus efficace que la plupart des systèmes qui sérialisent (en contrepartie, ce n'est pas forcément portable sans précaution entre différentes architectures matérielles).
Franck
Eric Brunel
On Thu, 24 Feb 2005 14:36:04 +0100, Do Re Mi chel La Si Do wrote:
bricoler une interface socket perso, qui risque de moins bien marcher pour des perfs équivalentes
Heu... J'ai lu, récemment un test comparatif des performances, qui montrait que les traitements raw_socket étaient entre 50 à 80 fois plus rapide qu'XML-RPC ; et 200 à 300 fois plus rapides que SOAP. CORBA s'en sortait mieux, étant, seulement, 2 à 3 fois plus lent.
Attention à tout faire rentrer dans le comparatif: vu que tu communiques entre deux langages différents, il va falloir encoder tes objets de façon portable, les transférer et les décoder de l'autre coté. S'il y a beaucoup de données et/ou qu'elles un peu compliqués, tu risques de perdre beaucoup de temps dans cette partie. Cela dit, ton comparatif correspond à peu près à ce que j'ai constaté d'expérience: CORBA est plutot pas mal (et encore: je n'utilisais pas les ORBs les plus rapides), mais XML-RPC, c'est pas une flèche...
A titre d'info, pour un usage inter-applications sur un même poste, passer par des sockets est quand même 500 fois plus lent qu'utiliser COM, selon des tests perso. Mais COM n'est pas toujours facile, et reste purement windows.
Je ne sais pas bien ce que COM utilise comme mécanisme de communication de bas niveau. Ce n'est manifestement pas des sockets; des pipes nommés peut-etre? Je n'ai jamais fait de tests de perfs avec les pipes nommés; peut-etre que ça va 10 fois plus vite que COM ;-) ? Mais il restera toujours le problème de l'encodage/décodage... - Eric Brunel -
On Thu, 24 Feb 2005 14:36:04 +0100, Do Re Mi chel La Si Do <enleverlesO.OmcO@OmclaveauO.com> wrote:
bricoler une interface socket perso, qui risque de moins bien marcher
pour des perfs équivalentes
Heu... J'ai lu, récemment un test comparatif des performances, qui montrait
que les traitements raw_socket étaient entre 50 à 80 fois plus rapide
qu'XML-RPC ; et 200 à 300 fois plus rapides que SOAP.
CORBA s'en sortait mieux, étant, seulement, 2 à 3 fois plus lent.
Attention à tout faire rentrer dans le comparatif: vu que tu communiques entre deux langages différents, il va falloir encoder tes objets de façon portable, les transférer et les décoder de l'autre coté. S'il y a beaucoup de données et/ou qu'elles un peu compliqués, tu risques de perdre beaucoup de temps dans cette partie. Cela dit, ton comparatif correspond à peu près à ce que j'ai constaté d'expérience: CORBA est plutot pas mal (et encore: je n'utilisais pas les ORBs les plus rapides), mais XML-RPC, c'est pas une flèche...
A titre d'info, pour un usage inter-applications sur un même poste, passer
par des sockets est quand même 500 fois plus lent qu'utiliser COM, selon des
tests perso. Mais COM n'est pas toujours facile, et reste purement windows.
Je ne sais pas bien ce que COM utilise comme mécanisme de communication de bas niveau. Ce n'est manifestement pas des sockets; des pipes nommés peut-etre? Je n'ai jamais fait de tests de perfs avec les pipes nommés; peut-etre que ça va 10 fois plus vite que COM ;-) ? Mais il restera toujours le problème de l'encodage/décodage...
- Eric Brunel -
On Thu, 24 Feb 2005 14:36:04 +0100, Do Re Mi chel La Si Do wrote:
bricoler une interface socket perso, qui risque de moins bien marcher pour des perfs équivalentes
Heu... J'ai lu, récemment un test comparatif des performances, qui montrait que les traitements raw_socket étaient entre 50 à 80 fois plus rapide qu'XML-RPC ; et 200 à 300 fois plus rapides que SOAP. CORBA s'en sortait mieux, étant, seulement, 2 à 3 fois plus lent.
Attention à tout faire rentrer dans le comparatif: vu que tu communiques entre deux langages différents, il va falloir encoder tes objets de façon portable, les transférer et les décoder de l'autre coté. S'il y a beaucoup de données et/ou qu'elles un peu compliqués, tu risques de perdre beaucoup de temps dans cette partie. Cela dit, ton comparatif correspond à peu près à ce que j'ai constaté d'expérience: CORBA est plutot pas mal (et encore: je n'utilisais pas les ORBs les plus rapides), mais XML-RPC, c'est pas une flèche...
A titre d'info, pour un usage inter-applications sur un même poste, passer par des sockets est quand même 500 fois plus lent qu'utiliser COM, selon des tests perso. Mais COM n'est pas toujours facile, et reste purement windows.
Je ne sais pas bien ce que COM utilise comme mécanisme de communication de bas niveau. Ce n'est manifestement pas des sockets; des pipes nommés peut-etre? Je n'ai jamais fait de tests de perfs avec les pipes nommés; peut-etre que ça va 10 fois plus vite que COM ;-) ? Mais il restera toujours le problème de l'encodage/décodage... - Eric Brunel -
Do Re Mi chel La Si Do
Re
Je ne connais rien sur l'aspect technique interne de COM. A mon avis, c'est un truc propriétaire en diable. Par contre, pour les formats de données courants (string, entier, flottant, date, tableaux (collection) des mêmes), COM a défini un format spécial. Tout est converti en "Com-variant-unicode" (l'expression est de moi, je ne connais pas le nom microsoftien du truc).
Et tous les logiciels compatibles COM savent traduire/lire/écrire ce format. Pour Python, c'est fait par PyWin (ou Ctypes).
Enfin, il faudrait dire "devraient savoir", car beaucoup n'ont pas toutes les possibilités de lecture/écriture. Par exemple, Paradox ne sait pas lire ou écrire les collections (tableaux). Il ne peut même pas lire plus d'une valeur de retour à la fois.
Mais tout ça est très loin d'être parfait. Les strings sont à "zéro terminal", je ne sais pas transférer du binaire (donc pas de graphisme, ni de son), etc.
Pour donner une idée des performances : j'ai une application, qui dialogue par COM avec un serveur Python ; ce dernier communique par COM avec Excel. Pour envoyer, depuis la 1ère application, 50 000 lignes sur 4 colonnes (dont 3 strings de 25 caractères, et un entier), à Excel, en passant par le serveur Python, il me faut moins de 2 secondes.
C'est vraiment rapide.
Par contre, je n'ai pas testé DCOM (Distant-COM), car, en ce moment, tout le monde désactive ça, pour de (fausses) raisons de sécurité. Fausses, car les quelques failles trouvées sont comblées depuis longtemps. Mais les habitudes sont prises, et ça devient dur de trouver un réseau, chez un client, qui accepte DCOM.
Autre chose : les pipes nommés. Je n'ai affaire à eux que chez quelques clients, pour faire de la connexion à SQL-server. Et, je n'ai jamais regardé ce que ça pouvait donner avec Python. Si tu avais un petit exemple Python, facile, et avec des docstrings en français... Mais ne fais rien exprès. La grippe ayant transformé mon retard, de chronique à monstrueux !
@-salutations -- Michel Claveau
Re
Je ne connais rien sur l'aspect technique interne de COM. A mon avis, c'est
un truc propriétaire en diable. Par contre, pour les formats de données
courants (string, entier, flottant, date, tableaux (collection) des mêmes),
COM a défini un format spécial. Tout est converti en "Com-variant-unicode"
(l'expression est de moi, je ne connais pas le nom microsoftien du truc).
Et tous les logiciels compatibles COM savent traduire/lire/écrire ce format.
Pour Python, c'est fait par PyWin (ou Ctypes).
Enfin, il faudrait dire "devraient savoir", car beaucoup n'ont pas toutes
les possibilités de lecture/écriture. Par exemple, Paradox ne sait pas lire
ou écrire les collections (tableaux). Il ne peut même pas lire plus d'une
valeur de retour à la fois.
Mais tout ça est très loin d'être parfait. Les strings sont à "zéro
terminal", je ne sais pas transférer du binaire (donc pas de graphisme, ni
de son), etc.
Pour donner une idée des performances : j'ai une application, qui dialogue
par COM avec un serveur Python ; ce dernier communique par COM avec Excel.
Pour envoyer, depuis la 1ère application, 50 000 lignes sur 4 colonnes (dont
3 strings de 25 caractères, et un entier), à Excel, en passant par le
serveur Python, il me faut moins de 2 secondes.
C'est vraiment rapide.
Par contre, je n'ai pas testé DCOM (Distant-COM), car, en ce moment, tout le
monde désactive ça, pour de (fausses) raisons de sécurité. Fausses, car les
quelques failles trouvées sont comblées depuis longtemps. Mais les habitudes
sont prises, et ça devient dur de trouver un réseau, chez un client, qui
accepte DCOM.
Autre chose : les pipes nommés. Je n'ai affaire à eux que chez quelques
clients, pour faire de la connexion à SQL-server. Et, je n'ai jamais
regardé ce que ça pouvait donner avec Python. Si tu avais un petit exemple
Python, facile, et avec des docstrings en français... Mais ne fais rien
exprès. La grippe ayant transformé mon retard, de chronique à monstrueux !
Je ne connais rien sur l'aspect technique interne de COM. A mon avis, c'est un truc propriétaire en diable. Par contre, pour les formats de données courants (string, entier, flottant, date, tableaux (collection) des mêmes), COM a défini un format spécial. Tout est converti en "Com-variant-unicode" (l'expression est de moi, je ne connais pas le nom microsoftien du truc).
Et tous les logiciels compatibles COM savent traduire/lire/écrire ce format. Pour Python, c'est fait par PyWin (ou Ctypes).
Enfin, il faudrait dire "devraient savoir", car beaucoup n'ont pas toutes les possibilités de lecture/écriture. Par exemple, Paradox ne sait pas lire ou écrire les collections (tableaux). Il ne peut même pas lire plus d'une valeur de retour à la fois.
Mais tout ça est très loin d'être parfait. Les strings sont à "zéro terminal", je ne sais pas transférer du binaire (donc pas de graphisme, ni de son), etc.
Pour donner une idée des performances : j'ai une application, qui dialogue par COM avec un serveur Python ; ce dernier communique par COM avec Excel. Pour envoyer, depuis la 1ère application, 50 000 lignes sur 4 colonnes (dont 3 strings de 25 caractères, et un entier), à Excel, en passant par le serveur Python, il me faut moins de 2 secondes.
C'est vraiment rapide.
Par contre, je n'ai pas testé DCOM (Distant-COM), car, en ce moment, tout le monde désactive ça, pour de (fausses) raisons de sécurité. Fausses, car les quelques failles trouvées sont comblées depuis longtemps. Mais les habitudes sont prises, et ça devient dur de trouver un réseau, chez un client, qui accepte DCOM.
Autre chose : les pipes nommés. Je n'ai affaire à eux que chez quelques clients, pour faire de la connexion à SQL-server. Et, je n'ai jamais regardé ce que ça pouvait donner avec Python. Si tu avais un petit exemple Python, facile, et avec des docstrings en français... Mais ne fais rien exprès. La grippe ayant transformé mon retard, de chronique à monstrueux !
@-salutations -- Michel Claveau
pbouige
In article <421dda04$0$28572$, Franck Pommereau wrote:
J'ajouterai D-Bus (http://freedesktop.org/wiki/Software_2fdbus) qui est vraiment facile à utiliser. Il transporte les données en binaire, ce qui est plus efficace que la plupart des systèmes qui sérialisent (en contrepartie, ce n'est pas forcément portable sans précaution entre différentes architectures matérielles).
Il y a un wrapper pour python ??
Cordialement
In article <421dda04$0$28572$79c14f64@nan-newsreader-06.noos.net>,
Franck Pommereau wrote:
J'ajouterai D-Bus (http://freedesktop.org/wiki/Software_2fdbus) qui est
vraiment facile à utiliser. Il transporte les données en binaire, ce qui
est plus efficace que la plupart des systèmes qui sérialisent (en
contrepartie, ce n'est pas forcément portable sans précaution entre
différentes architectures matérielles).
In article <421dda04$0$28572$, Franck Pommereau wrote:
J'ajouterai D-Bus (http://freedesktop.org/wiki/Software_2fdbus) qui est vraiment facile à utiliser. Il transporte les données en binaire, ce qui est plus efficace que la plupart des systèmes qui sérialisent (en contrepartie, ce n'est pas forcément portable sans précaution entre différentes architectures matérielles).
Il y a un wrapper pour python ??
Cordialement
Franck Pommereau
Philippe Bouige wrote:
J'ajouterai D-Bus (http://freedesktop.org/wiki/Software_2fdbus) qui est [...]
Il y a un wrapper pour python ??
Oui, il est fourni d'office.
F.
Philippe Bouige wrote:
J'ajouterai D-Bus (http://freedesktop.org/wiki/Software_2fdbus) qui est
[...]
