Discussion :

[toure32]

Bonjour a tous,
je suis entrain d'ecrire une appli en delphi. l'appl doit etre installer sur plusieurs machines.
je veux que chaque instance en execution sur les differentes machines puissent s'envoyer des msg.
ex: lorsque une istance fais un ajout dans la BD elle doit informer les autres instance sur le reseau.
Merci de m'aider.

[ShaiLeTroll]

Allez le plus simple reste le TCP\IP

D5 : Voir TClientSocket et TServerSocket
D6 : Idem, voir composant Indy
D7 : TTcpClient et TTcpServer, ou Indy
...

Ensuite, qui sera le serveur, il en faut un pour qu'il sache sur qui se connecté, bon tu peux aussi, tester les IP d'une plage (192.168.1.1 à 192.168.1.253 par exemple), et dès que l'un fonctionne tu te connecte dessus, et celui te donnera les IP des autres programmes existants, l'absence de serveur peu rendre la gestion des communications compliqués ...

Ensuite, si tu te débrouille bien en DB :
InterBase, FireBird : voir TIBEvent, cela doit permettre de gérer ce genre de chose
Oracle, SQL Server, Sybase : les Triggers (ou l'autre truc dans je n'ai pas le nom en mémoire) doivent aussi permettre de gérer ce genre de chose, comme rafraichir les vues

Paradox, HyperFile, MySQL 4 : Bon, retour au TCP\IP

[Laurent Dardenne]

A priori c'est plus un système de notification sur le serveur SGBD qu'il te faut ,un peu comme Advanced Queuing sous Oracle.

Ou développer une solution comme le dit ShaiLeTroll au sein d'un trigger mais sur le serveur SGBD.
Ensuite il faut savoir si ton serveur est et sera tjr sous Windows ou pas (choix du langage) et si l'application utilisera tjr le même moteur de SGBDR (+ implémentations).

Je suppose que seules les machines connectées au SGBD sont ciblées ?
Existera-til un backup de la base ?
etc.

Mais pour le moment c'est plus de l'architecture que du dev.

Ce genre de truc on sait où ça commence jamais où ça s'arrête

[Graffito]

Bonjour,

On pourrait passer par une appli centrale, mais ce n'est pas, d'après ce que j'ai compris, l'option choisie.

Si toutes les appli sont au même niveau, elles peuvent écrire des messages horodatés dans une table de notification.
Chaque appli doit alors consulter périodiquement cette table de notification pour lire les messages en instance et identifier ceux qui lui sont destiné et, par la même occasion, supprimer les messages qui lui sont exclusivement destinés ou les messages obsolètes (émis depuis plus de n minutes).

[Laurent Dardenne]

On pourrait passer par une appli centrale,

Oui c'est une possibilité.

Si toutes les appli sont au même niveau, elles peuvent écrire des messages horodatés dans une table de notification.

C'est en gros un des principes AQ d'Oracle.

Chaque appli doit alors consulter périodiquement cette table de notification pour lire les messages en instance

Oui mais là c'est du pooling pas de l'événementiel. Bon c'est une solution mais ensuite il faut voir la charge et la volumétrie. De ce coté après 3 posts on est un peu court en informations.

ou les messages obsolètes (émis depuis plus de n minutes).

Entre autres, il y a aussi les connexions fantômes.

En reprenant AQ, et oui on se référe tjr à ce qu'ont connait le plus, c'est lors de la connexion à la base que l'utilisateur s'abonne au systéme de notification. Sa déconnexion supprime son abonnement.

En même temps :

ex: lorsque une instance fait un ajout dans la BD elle doit informer les autres instances sur le réseau.

quel est l'objectif de cet événement ?

Est-ce un ajout sur n'importe quelle table ?

[Gaadek]

Etant donné que ta base doit se trouver sur un poste unique (vu qu'à priori, tes applis vont modifier une seule et même base), qui plus est sur une machine en permanence active (sinon tes applis ne pourrons pas modifier la base), je pencherais pour le développement d'une petite application qui ferait office de serveur et qui serait la seule à accéder à la base:

Appli_1 <-----|
Appli_2 <-----|
Appli_3 <-----|----> Appli_serveur <---> Base de données
Appli_4 <-----|
Appli_n <-----|

Ainsi, toutes les Appli_x sont des clients de Appli_serveur, et celle cette dernière est autorisée à consulter/modifier la DB.

Les intérêts:
1) D'une part, tu centralises tes opérations d'accès à la BD sur un seul poste, l'appli_serveur, et donc en cas de modif, tu n'as pas à redistribuer toutes les applications clientes.

2) Ta base de données devant être toujours accessible, le programme appli_serveur le sera aussi, donc pas de problème d'échange de données.

3) Une parties des informations sera disponible depuis appli_serveur, donc pourra être redistribuée sans accéder à la base de données.

Les inconvénients:
1) Il faut développer une nouvelle appli

2) Ce n'est pas évident que tu puisses installer ce logiciel sur le poste de la BD, et dans ce cas c'est plutôt problématique car tu perds pas mal d'avantages sur cette solution.