Architecture distribuée

Le
Alex Marandon
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 ?

- 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.
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Jean-Michel Hiver
Le #139364
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
Le #139363
In article 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
Le #139362
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
Le #139361
In article 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


Poster une réponse
Anonyme