DB_SPOOL est un middleware destine au transport de messages ou d'informations de tous type sur un systeme Unix ou sur un ensemble de systemes Unix.
DB_SPOOL est pensé selon un certain nombre de postulats :
- Lorsque deux applications doivent échanger des informations de facon asynchrone, leur mode de communication dépend souvent de la configuration de chaque application par rapport à l'autre. Sont-elles sur un reseau local ? sur la meme machine ? communiquent-elles via l'Internet ? ... Un middleware permet de s'affranchir de ce genre de questions et permet, via des fonctions, au développeur de joindre une autre application d'une facon unique quelles que soient les conditions de connexions.
- Un système de fichier est lent et peu performant pour passer un grand nombre de fichiers, il est préférable d'utiliser un fichier unique prévu a cet effet.
- Il est plus lent et plus pénalisant en termes de performances de laisser plusieurs process attaquer un même fichier de facon simultanée que d'avoir un seul process qui a pour charge de travailler avec ce fichier. DB_SPOOL a un process pour chaque spool a gérer et les programmes qui ont besoin d'échanger des informations avec ce spool parlent avec ce process. On ne gère pas de lock car cet unique process intermédiaire travaille en série et ne fait jamais deux choses a la fois.
- Un bon programme est un programme simple, c'est pour cela que DB_SPOOL propose un grand nombre de petits utilitaires que l'on peut reprendre dans un sens fonctionnel si cela est voulu. dir2spool.pl par exemple est capable de parser un fichier à insérer dans un spool, indépendement de son format, et de rajouter des options particulières telles que la priorité ou la période de validité. Très pratique pour donner priorité à un client donné juste apres une input.
- Indépendement des performances ou de la couche d'abstraction proposée au dévelopement, un middleware doit également offrir des fonctionnalités pour ameliorer l'administration système. Ainsi, fini les configurations multiples, les systèmes de remontés d'alarmes multiples, ... le serveur de configuration de DB_Spool sait en permanence l'état de chaque spool ou qu'il se trouve et offre, à toute application qui veut l'utiliser, un systeme de configuration centralisé.
- Systeme de routage fonctionnel ou de répartition de charge, voire de clusterisation de traitement de messages, DB_Spool sait gérer l'échec d'envoi et peut même automatiquement cesser d'emmettre sur un serveur qui aurait rendu l'ame.
- Pour échanger des transactions avec des serveurs distants, DB_Spool utilise une méthode de résolution de noms de spool vers IP distante, l'export d'une application d'un serveur vers un autres est simplifié car il suffit de modifier l'IP du spool associé dans le serveur de configuration pour que toutes les applications qui dépendent de ce serveur soient automatiquement à jour.
DB_Spool trouve sa place partout ou il s'agit de connecter des applications de facon asynchrone (connexion synchrone à venir), depuis un site web vers un système de billing, depuis des centres de traitement vers un serveur central, interconnexions d'applications de traitement de messages (SMS, Mail, transaction financieres (ou autres), système centralisé de messenging, ...).
Priorites = 5 niveaux disponibles
First in first out = oui dans chaque niveau de priorité
Format du spool = format DB ou gdbm selon disponibilité sur le système.
| Gestion des expiré = chaque spool a une valeur d'expiration des messages par défaut, possibilite de forcer la valeur pour un message donné |
Gestion des livraison differées = Oui, configurable par message
Gestion des ré-essais = Oui, de facon differée, configurable par spool
Status disponibles = new / sent / to_send
| Fonctionnement sécurisé = Oui, un spool peut etre synchrone et sauvegarder sa position sur disque a chaque modification. |
| Fonctionnement rapide = Oui, un spool peut travailler de facon asynchrone avec le disque. |
| Connexion inter-applicative asynchrone = Oui, jusqu'a un décallage de 100 000 transactions. |
Connexion inter-applicative synchrone = a venir
Aknowledgement de reception = a venir
Regulation de vitesse = Oui, voir regul.pl
Repartition de charge = Oui, voir repart.pl
Authentification a l'insertion = À venir
| Performances = de 10 a 700 transactions locales / sec en local, de 1 a 50 transactions reseaux / sec. |
DB_SPOOL dispose d'une librairie en Perl qui permet d'insérer, d'effacer et de demander un message, elle permet aussi d'en changer le status.
Il existe des options gerees par les spools (priority, ext, ...), mais il est tout à fait possible d'utiliser la table d'options de facon fonctionnelle et de rajouter autant d'options que l'on veut pour ses propres logiciels, cela n'interfère pas avec le fonctionnement des spools et permet d'avoir une infinité de fonctionnalités.
Le protocole de DB_SPOOL est fort simple et utilise des fichiers FIFOs. L'écriture de librairies en C ou tout autre langage ne devrait pas poser de problème.
DB_SPOOL fonctionne selon deux modes, un mode synchrone ou les fichiers de spools sont mises à jour a chaque modification, c'est un système plus lent mais très sur. Le mode asynchrone est beaucoup plus rapide, mais moins sur en cas de crash. Bien sur, dans les deux cas, les fichiers de spools sont synchronisés au moment de couper le systeme, on ne perd pas de message en relancant l'application.
En mode asynchrone, on atteint facilement 300 messages par seconde sur un PIII 700 sur un spool (en fait, c'est le nombre maxi de messages que la machine pourra traiter a la seconde) sous Linux.
Selon les systemes d'exploitations et le mode choisis, on peut en moyenne assurer de 10 a 1500 messages par secondes par machine (diviser par le nombre de spools).
Un certain nombres d'utilitaires sont fournis et peuvent servir en environnement de production :
- file2spool.pl permet d'envoyer dans un spool un message representé par un fichier ou passe par STDIN
- spool2file.pl va créer un fichier ou envoyer par la sortie standard le prochain message disponible d'un spool
- del.pl peut supprimer un message selon son index
- list.pl permet de lister les messages d'un spool
- status.pl permet de changer le status d'un message
- dir2spool.pl permet de prendre les fichiers dans un repertoire, de les parser afin de rajouter des options et de les envoyer dans un spool.
- get_max.pl et input_max.pl testent les performances d'un spool dans un environnement donne.
Voir les pages de documentation de chaque process et fichier de configuration, ainsi que le fichier README pour plus d'informations a propos de l'installation et de la configuration de DB_SPOOL.
Sur systemes Unix :
- Linux 2.2.x ou au dela.
- Solaris 8 Intel ou Sparc Edition.
- FreeBSD 4.2 ou au dela
- NetBSD 1.5.1 plateforme Sparc
DB_SPOOL devrait fonctionner normalement sur d'autres systemes Unix mais n'a pas encore ete teste.
Si vous arrivez a faire fonctionner DB_SPOOL sur d'autres systemes Unix informez m'en.
DB_SPOOL ne fonctionne pas sur OpenBSD 3.0 sur plateformes PC.
Stephane TOUGARD [email protected]
07/10/2002 1.0
- First version