Je viens solliciter les lumières usenetiennes car un débat houleux agite
actuellement la petite société pour laquelle je travaille, et je manque
d'éléments pour étayer mon point de vue, qui me semble pourtant frappé
du sceau du bon sens :)
Nous développons un système d'information comportants plusieurs
applications qui travaillent sur des données communes, nos applications
vont être essentiellement de deux types : des applications graphiques
écrites en Python et wxPython d'une part, des application web faites en
mod_perl d'autre part. Ces applications tirent leurs données de
plusieurs bases PostgreSQL lesquelles stockent certaines informations
communes de façon redondante (ce qui est mal et doit être modifié).
D'autre part, ces applications partagent de nombreuses entités métier
communes.
Actuellement, certains décideurs préssés préconisent d'implémenter les
clients wxPython comme des clients lourds attaquant directement la base
de données. De mon côté il me semble qu'il faudrait mutualiser les
entités métiers, et une bonne partie de la logique applicative sur un
serveur d'application pour réduire le code du soft client à la gestion
de la GUI et à la communication avec le dit serveur. Le problème c'est
que je ne connait rien à l'informatique distribuée et que, d'après les
décideurs sus-cités, les technologies de type CORBA et consorts sont
trop complexes et présentent une courbe d'apprentissage trop raide.
Pourtant je reste convaincu qu'en mettant la logique applicative sur les
clients on va aboutir à de la duplication de fonctionnalités et à des
problèmes de maintenance. De plus, je frémis à l'idée d'embarquer des
requêtes SQL dans les clients et de leur ouvrir le port du SGBD. Enfin,
il y a des objectif de déploiement de clients sur des machines avec des
contraintes de perf (PDA, tablettes).
Voila pour le contexte, vous m'avez suivi jusqu'ici ? Génial :) Voici
mes questions maintenant :
- Quelles technologies d'informatique distribuée compatible Perl et
Python ?
- Quelles implémentations ?
- Quelle courbe d'apprentissage ?
- Pensez vous que je suis fou et que attaquer la bdd directement c'est
très bien ?
ps : Comme nous faisons plus de Python que de Perl, je positionne le suivi
sur fr.comp.lang.python.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Michel Hiver
Alex Marandon wrote:
Bonjour,
Je viens solliciter les lumières usenetiennes car un débat houleux agite actuellement la petite société pour laquelle je travaille, et je manque d'éléments pour étayer mon point de vue, qui me semble pourtant frappé du sceau du bon sens :)
Nous développons un système d'information comportants plusieurs applications qui travaillent sur des données communes, nos applications vont être essentiellement de deux types : des applications graphiques écrites en Python et wxPython d'une part, des application web faites en mod_perl d'autre part. Ces applications tirent leurs données de plusieurs bases PostgreSQL lesquelles stockent certaines informations communes de façon redondante (ce qui est mal et doit être modifié). D'autre part, ces applications partagent de nombreuses entités métier communes.
Actuellement, certains décideurs préssés préconisent d'implémenter les clients wxPython comme des clients lourds attaquant directement la base de données. De mon côté il me semble qu'il faudrait mutualiser les entités métiers, et une bonne partie de la logique applicative sur un serveur d'application pour réduire le code du soft client à la gestion de la GUI et à la communication avec le dit serveur. Le problème c'est que je ne connait rien à l'informatique distribuée et que, d'après les décideurs sus-cités, les technologies de type CORBA et consorts sont trop complexes et présentent une courbe d'apprentissage trop raide.
Pourtant je reste convaincu qu'en mettant la logique applicative sur les clients on va aboutir à de la duplication de fonctionnalités et à des problèmes de maintenance. De plus, je frémis à l'idée d'embarquer des requêtes SQL dans les clients et de leur ouvrir le port du SGBD. Enfin, il y a des objectif de déploiement de clients sur des machines avec des contraintes de perf (PDA, tablettes).
Voila pour le contexte, vous m'avez suivi jusqu'ici ? Génial :) Voici mes questions maintenant :
- Quelles technologies d'informatique distribuée compatible Perl et Python ?
Si tu veux des web services, SOAP (avec SOAP::Lite). Si tu veux juste echanger des structures de donnes, YAML, RDF ou XML.
- Quelles implémentations - Quelle courbe d'apprentissage ?
SOAP::Lite et YAML sont tres faciles.
- Pensez vous que je suis fou et que attaquer la bdd directement c'est très bien ?
Ca depend. Si ta BDD est concue de maniere a garantir l'integrite des donnees grace a des contraintes, ca ne pose pas de probleme majeur AMHA.
Par contre, si l'integrite des donnees doit etre garantie en partie par du code Python ou Perl, ca serait kamikaze de laisser cette fonctionalite au niveau du client puisque un client malicieux serait capable de chibrer l'integrite des donnees.
Alex Marandon wrote:
Bonjour,
Je viens solliciter les lumières usenetiennes car un débat houleux agite
actuellement la petite société pour laquelle je travaille, et je manque
d'éléments pour étayer mon point de vue, qui me semble pourtant frappé
du sceau du bon sens :)
Nous développons un système d'information comportants plusieurs
applications qui travaillent sur des données communes, nos applications
vont être essentiellement de deux types : des applications graphiques
écrites en Python et wxPython d'une part, des application web faites en
mod_perl d'autre part. Ces applications tirent leurs données de
plusieurs bases PostgreSQL lesquelles stockent certaines informations
communes de façon redondante (ce qui est mal et doit être modifié).
D'autre part, ces applications partagent de nombreuses entités métier
communes.
Actuellement, certains décideurs préssés préconisent d'implémenter les
clients wxPython comme des clients lourds attaquant directement la base
de données. De mon côté il me semble qu'il faudrait mutualiser les
entités métiers, et une bonne partie de la logique applicative sur un
serveur d'application pour réduire le code du soft client à la gestion
de la GUI et à la communication avec le dit serveur. Le problème c'est
que je ne connait rien à l'informatique distribuée et que, d'après les
décideurs sus-cités, les technologies de type CORBA et consorts sont
trop complexes et présentent une courbe d'apprentissage trop raide.
Pourtant je reste convaincu qu'en mettant la logique applicative sur les
clients on va aboutir à de la duplication de fonctionnalités et à des
problèmes de maintenance. De plus, je frémis à l'idée d'embarquer des
requêtes SQL dans les clients et de leur ouvrir le port du SGBD. Enfin,
il y a des objectif de déploiement de clients sur des machines avec des
contraintes de perf (PDA, tablettes).
Voila pour le contexte, vous m'avez suivi jusqu'ici ? Génial :) Voici
mes questions maintenant :
- Quelles technologies d'informatique distribuée compatible Perl et
Python ?
Si tu veux des web services, SOAP (avec SOAP::Lite). Si tu veux juste
echanger des structures de donnes, YAML, RDF ou XML.
- Quelles implémentations
- Quelle courbe d'apprentissage ?
SOAP::Lite et YAML sont tres faciles.
- Pensez vous que je suis fou et que attaquer la bdd directement c'est
très bien ?
Ca depend. Si ta BDD est concue de maniere a garantir l'integrite des
donnees grace a des contraintes, ca ne pose pas de probleme majeur AMHA.
Par contre, si l'integrite des donnees doit etre garantie en partie par
du code Python ou Perl, ca serait kamikaze de laisser cette
fonctionalite au niveau du client puisque un client malicieux serait
capable de chibrer l'integrite des donnees.
Je viens solliciter les lumières usenetiennes car un débat houleux agite actuellement la petite société pour laquelle je travaille, et je manque d'éléments pour étayer mon point de vue, qui me semble pourtant frappé du sceau du bon sens :)
Nous développons un système d'information comportants plusieurs applications qui travaillent sur des données communes, nos applications vont être essentiellement de deux types : des applications graphiques écrites en Python et wxPython d'une part, des application web faites en mod_perl d'autre part. Ces applications tirent leurs données de plusieurs bases PostgreSQL lesquelles stockent certaines informations communes de façon redondante (ce qui est mal et doit être modifié). D'autre part, ces applications partagent de nombreuses entités métier communes.
Actuellement, certains décideurs préssés préconisent d'implémenter les clients wxPython comme des clients lourds attaquant directement la base de données. De mon côté il me semble qu'il faudrait mutualiser les entités métiers, et une bonne partie de la logique applicative sur un serveur d'application pour réduire le code du soft client à la gestion de la GUI et à la communication avec le dit serveur. Le problème c'est que je ne connait rien à l'informatique distribuée et que, d'après les décideurs sus-cités, les technologies de type CORBA et consorts sont trop complexes et présentent une courbe d'apprentissage trop raide.
Pourtant je reste convaincu qu'en mettant la logique applicative sur les clients on va aboutir à de la duplication de fonctionnalités et à des problèmes de maintenance. De plus, je frémis à l'idée d'embarquer des requêtes SQL dans les clients et de leur ouvrir le port du SGBD. Enfin, il y a des objectif de déploiement de clients sur des machines avec des contraintes de perf (PDA, tablettes).
Voila pour le contexte, vous m'avez suivi jusqu'ici ? Génial :) Voici mes questions maintenant :
- Quelles technologies d'informatique distribuée compatible Perl et Python ?
Si tu veux des web services, SOAP (avec SOAP::Lite). Si tu veux juste echanger des structures de donnes, YAML, RDF ou XML.
- Quelles implémentations - Quelle courbe d'apprentissage ?
SOAP::Lite et YAML sont tres faciles.
- Pensez vous que je suis fou et que attaquer la bdd directement c'est très bien ?
Ca depend. Si ta BDD est concue de maniere a garantir l'integrite des donnees grace a des contraintes, ca ne pose pas de probleme majeur AMHA.
Par contre, si l'integrite des donnees doit etre garantie en partie par du code Python ou Perl, ca serait kamikaze de laisser cette fonctionalite au niveau du client puisque un client malicieux serait capable de chibrer l'integrite des donnees.
Alex Marandon
In article <3fa3946b$0$115$, Jean-Michel Hiver wrote:
- Quelles technologies d'informatique distribuée compatible Perl et Python ?
Si tu veux des web services, SOAP (avec SOAP::Lite). Si tu veux juste echanger des structures de donnes, YAML, RDF ou XML.
Je ne "veux" pas particulièrement des web services, je veux une solution pour faire des appels de méthodes distants entre objets éventuellement implémentés dans deux langages différents.
J'ai fais quelques tests avec XML-RPC, et j'ai constaté des performances assez décevantes. XML-RPC n'est de toute façon pas adapté en terme de fonctionalités, contrairement à SOAP qui semble l'être. Je rappelle que nous avons des application interactive et non-web avec des contraintes de temps de réaction.
Je doute qu'une solution à base de XML soit adaptée, étant donnée la verbosité, et donc la lourdeur de cette technologie. Mais je peux tout à fait me tromper. Des retours d'expérience (idéalement en production) là-dessus ?
- Quelles implémentations - Quelle courbe d'apprentissage ?
SOAP::Lite et YAML sont tres faciles.
Ok.
- Pensez vous que je suis fou et que attaquer la bdd directement c'est très bien ?
Ca depend. Si ta BDD est concue de maniere a garantir l'integrite des donnees grace a des contraintes, ca ne pose pas de probleme majeur AMHA.
Disons que les contraintes "native" du SGBD peuvent préserver l'intégrité des données jusqu'à un certain point de granularité (typage, intégrité référentielle). En l'occurence nos données exigent des contraintes qui doivent être exprimées par des algorithmes spécifiques. Cela pourrait être implémenté à coup de triggers, mais étant donné la caractère anti-productif du SQL procédural (en tout cas dans l'implémentation PostgreSQL) je crois plus efficace d'implémenter ces contrôles en langage de script. Pour répondre à ceux qui me feraient remarquer que PostgreSQL permet d'écrire des procédure stockées en langages de script, je signale que l'interface Python est cassée, que celle en Perl ne permet pas de faire des trigger et que celle en TCL ne me parait guère plus productive que le PL/SQL. Houla je suis bien OT là, désolé.
Par contre, si l'integrite des donnees doit etre garantie en partie par du code Python ou Perl, ca serait kamikaze de laisser cette fonctionalite au niveau du client puisque un client malicieux serait capable de chibrer l'integrite des donnees.
:)) On est d'accord.
In article <3fa3946b$0$115$65c69314@mercury.nildram.net>, Jean-Michel
Hiver wrote:
- Quelles technologies d'informatique distribuée compatible Perl et
Python ?
Si tu veux des web services, SOAP (avec SOAP::Lite). Si tu veux juste
echanger des structures de donnes, YAML, RDF ou XML.
Je ne "veux" pas particulièrement des web services, je veux une solution
pour faire des appels de méthodes distants entre objets éventuellement
implémentés dans deux langages différents.
J'ai fais quelques tests avec XML-RPC, et j'ai constaté des performances
assez décevantes. XML-RPC n'est de toute façon pas adapté en terme de
fonctionalités, contrairement à SOAP qui semble l'être. Je rappelle que
nous avons des application interactive et non-web avec des contraintes
de temps de réaction.
Je doute qu'une solution à base de XML soit adaptée, étant donnée la
verbosité, et donc la lourdeur de cette technologie. Mais je peux tout à
fait me tromper. Des retours d'expérience (idéalement en production)
là-dessus ?
- Quelles implémentations
- Quelle courbe d'apprentissage ?
SOAP::Lite et YAML sont tres faciles.
Ok.
- Pensez vous que je suis fou et que attaquer la bdd directement c'est
très bien ?
Ca depend. Si ta BDD est concue de maniere a garantir l'integrite des
donnees grace a des contraintes, ca ne pose pas de probleme majeur AMHA.
Disons que les contraintes "native" du SGBD peuvent préserver
l'intégrité des données jusqu'à un certain point de granularité (typage,
intégrité référentielle). En l'occurence nos données exigent des
contraintes qui doivent être exprimées par des algorithmes spécifiques.
Cela pourrait être implémenté à coup de triggers, mais étant donné la
caractère anti-productif du SQL procédural (en tout cas dans
l'implémentation PostgreSQL) je crois plus efficace d'implémenter ces
contrôles en langage de script. Pour répondre à ceux qui me feraient
remarquer que PostgreSQL permet d'écrire des procédure stockées en
langages de script, je signale que l'interface Python est cassée,
que celle en Perl ne permet pas de faire des trigger et que celle en TCL
ne me parait guère plus productive que le PL/SQL. Houla je suis bien OT
là, désolé.
Par contre, si l'integrite des donnees doit etre garantie en partie par
du code Python ou Perl, ca serait kamikaze de laisser cette
fonctionalite au niveau du client puisque un client malicieux serait
capable de chibrer l'integrite des donnees.
In article <3fa3946b$0$115$, Jean-Michel Hiver wrote:
- Quelles technologies d'informatique distribuée compatible Perl et Python ?
Si tu veux des web services, SOAP (avec SOAP::Lite). Si tu veux juste echanger des structures de donnes, YAML, RDF ou XML.
Je ne "veux" pas particulièrement des web services, je veux une solution pour faire des appels de méthodes distants entre objets éventuellement implémentés dans deux langages différents.
J'ai fais quelques tests avec XML-RPC, et j'ai constaté des performances assez décevantes. XML-RPC n'est de toute façon pas adapté en terme de fonctionalités, contrairement à SOAP qui semble l'être. Je rappelle que nous avons des application interactive et non-web avec des contraintes de temps de réaction.
Je doute qu'une solution à base de XML soit adaptée, étant donnée la verbosité, et donc la lourdeur de cette technologie. Mais je peux tout à fait me tromper. Des retours d'expérience (idéalement en production) là-dessus ?
- Quelles implémentations - Quelle courbe d'apprentissage ?
SOAP::Lite et YAML sont tres faciles.
Ok.
- Pensez vous que je suis fou et que attaquer la bdd directement c'est très bien ?
Ca depend. Si ta BDD est concue de maniere a garantir l'integrite des donnees grace a des contraintes, ca ne pose pas de probleme majeur AMHA.
Disons que les contraintes "native" du SGBD peuvent préserver l'intégrité des données jusqu'à un certain point de granularité (typage, intégrité référentielle). En l'occurence nos données exigent des contraintes qui doivent être exprimées par des algorithmes spécifiques. Cela pourrait être implémenté à coup de triggers, mais étant donné la caractère anti-productif du SQL procédural (en tout cas dans l'implémentation PostgreSQL) je crois plus efficace d'implémenter ces contrôles en langage de script. Pour répondre à ceux qui me feraient remarquer que PostgreSQL permet d'écrire des procédure stockées en langages de script, je signale que l'interface Python est cassée, que celle en Perl ne permet pas de faire des trigger et que celle en TCL ne me parait guère plus productive que le PL/SQL. Houla je suis bien OT là, désolé.
Par contre, si l'integrite des donnees doit etre garantie en partie par du code Python ou Perl, ca serait kamikaze de laisser cette fonctionalite au niveau du client puisque un client malicieux serait capable de chibrer l'integrite des donnees.
:)) On est d'accord.
Jean-Michel Hiver
J'ai fais quelques tests avec XML-RPC, et j'ai constaté des performances assez décevantes. XML-RPC n'est de toute façon pas adapté en terme de fonctionalités, contrairement à SOAP qui semble l'être. Je rappelle que nous avons des application interactive et non-web avec des contraintes de temps de réaction.
Errr... Juste pour ton info, SOAP est base sur un protocole HTTP et XML. Mais ca ne se voit pas.
J'ai fais quelques tests avec XML-RPC, et j'ai constaté des performances
assez décevantes. XML-RPC n'est de toute façon pas adapté en terme de
fonctionalités, contrairement à SOAP qui semble l'être. Je rappelle que
nous avons des application interactive et non-web avec des contraintes
de temps de réaction.
Errr... Juste pour ton info, SOAP est base sur un protocole HTTP et XML.
Mais ca ne se voit pas.
J'ai fais quelques tests avec XML-RPC, et j'ai constaté des performances assez décevantes. XML-RPC n'est de toute façon pas adapté en terme de fonctionalités, contrairement à SOAP qui semble l'être. Je rappelle que nous avons des application interactive et non-web avec des contraintes de temps de réaction.
Errr... Juste pour ton info, SOAP est base sur un protocole HTTP et XML. Mais ca ne se voit pas.
Alex Marandon
In article <3fa3a016$0$113$, Jean-Michel Hiver wrote:
J'ai fais quelques tests avec XML-RPC, et j'ai constaté des performances assez décevantes. XML-RPC n'est de toute façon pas adapté en terme de fonctionalités, contrairement à SOAP qui semble l'être. Je rappelle que nous avons des application interactive et non-web avec des contraintes de temps de réaction.
Errr... Juste pour ton info, SOAP est base sur un protocole HTTP et XML. Mais ca ne se voit pas.
Au niveau du code utilisateur, je sais bien. Mais au niveau des perfs est-ce que ça ne se voit pas ?
Le fait d'encapsuler les données dans du XML, puis le tout dans des requêtes HTTP, puis de désencapsuler le tout à l'autre bout, ça ne plombe pas les perfs ?
fu2 fctx
In article <3fa3a016$0$113$65c69314@mercury.nildram.net>, Jean-Michel
Hiver wrote:
J'ai fais quelques tests avec XML-RPC, et j'ai constaté des performances
assez décevantes. XML-RPC n'est de toute façon pas adapté en terme de
fonctionalités, contrairement à SOAP qui semble l'être. Je rappelle que
nous avons des application interactive et non-web avec des contraintes
de temps de réaction.
Errr... Juste pour ton info, SOAP est base sur un protocole HTTP et XML.
Mais ca ne se voit pas.
Au niveau du code utilisateur, je sais bien. Mais au niveau des perfs
est-ce que ça ne se voit pas ?
Le fait d'encapsuler les données dans du XML, puis le tout dans des
requêtes HTTP, puis de désencapsuler le tout à l'autre bout, ça ne
plombe pas les perfs ?
In article <3fa3a016$0$113$, Jean-Michel Hiver wrote:
J'ai fais quelques tests avec XML-RPC, et j'ai constaté des performances assez décevantes. XML-RPC n'est de toute façon pas adapté en terme de fonctionalités, contrairement à SOAP qui semble l'être. Je rappelle que nous avons des application interactive et non-web avec des contraintes de temps de réaction.
Errr... Juste pour ton info, SOAP est base sur un protocole HTTP et XML. Mais ca ne se voit pas.
Au niveau du code utilisateur, je sais bien. Mais au niveau des perfs est-ce que ça ne se voit pas ?
Le fait d'encapsuler les données dans du XML, puis le tout dans des requêtes HTTP, puis de désencapsuler le tout à l'autre bout, ça ne plombe pas les perfs ?
