Un article de OpenIHS.org.

UniComCtrl est un routeur de message sous forme de requêtes, champs, liste et bien d'autres type de donnée...

Sommaire 1 Fonctionnement général (clients <-> serveur <-> plugins) 1.1 Quel est l'intérêt de ce projet ? 1.2 Fonctionnement interne du serveur 2 Présentations des mode de fonctionnement 2.1 Fonctionnement d'un client 2.2 Fonctionnement d'un plugin

[modifier] Fonctionnement général (clients <-> serveur <-> plugins)

Tout d'abord, présentons un problème qui se rencontre souvent quand on désire réaliser une application réseau avec un système de requête, par exemple pour administrer un service...

[modifier] Quel est l'intérêt de ce projet ?

Immaginez-vous devant ce cas suivant :

Ici, les deux clients effectue des requêtes à l'application contrôlée. Si nous développons le fonctionnement de l'application, ça nous donne le schéma suivant :

À chaque connexion de la part d'un client, l'application crée une nouvelle tache associée à ce dernier. En plus cette application devra sans doute de l'authentification du client.

Voici maintenant une autre approche du problème :

Dans cette approche, nous avons placé un intermédiaire qui s'occupera des taches suivantes :

• Réception des connexion de la part des client.
• gestion de l'authentification des chacun de ceux-ci.

Voici ce que ça donne :

Cet intermédiaire est le serveur UniComCtrl. Celui-ci affecte une tache à chaque clients et aussi à l'application. Après une identification correcte de la part de chaque client et après avoir vérifié les droits d'accès à cette application, le serveur établit une liaison entre chaque clients et l'application contrôlée.

[modifier] Fonctionnement interne du serveur

Comme vous avez pus le constater ce serveur agit en quelque sorte comme intermédiaire... Mais ça ne s'arrête pas là !

À partir de maintenant nous allons parler de plugin à la place d'application contrôlée.

Ce serveur ne se limite pas à la connexion de plusieurs client à un plugin mais à une multitude de plugins.

Nous allons imaginer un cas d'utilisation avec deux clients et deux plugins nommés respectivement client1, client2, plugin1 et plugin2. Le client 1 se connecte et effectue la requête USE plugin2 en admettant qu'il ait les droits nécessaires. Le serveur établit alors un lien entre la tache client 1 et la tache plugin 2 comme ceci :

En suite le client 2 se connecte et effectue la requête USE ALL en admettant qu'il ait les droits nécessaires. Le serveur établit alors un lien entre la tache client 2 et la tache plugin 1 et un lien entre la tache client 2 et la tache plugin 2 comme ceci :

[modifier] Présentations des mode de fonctionnement

Comme vous avez pu le constater il y a deux sorte d'application, le plugin et le client, et donc deux fonctionnement à décrire. Il faut aussi noter qu'il y a deux mode de transmission de donnée : en mode synchrone et asynchrone.

Mode synchrone

Le client envoi une requête et reste bloqué jusqu'à ce que le plugin réceptionne la requête, traite la demande, transmette la réponse et que le client la réceptionne. C'est le cas lors d'un appel de la méthode query().

Mode asynchrone

Le client envoi une requête sans être bloqué. Le plugin réceptionne la requête, traite la demande, transmette la réponse et le client la réceptionne et la traite à ce moment la. On peux parler ici de fonctionnement évènementiel.

[modifier] Fonctionnement d'un client

[modifier] Fonctionnement d'un plugin