Show
Ignore:
Timestamp:
02/13/08 18:47:52 (2 years ago)
Author:
haypo
svm:headrev:

c624a6cb-57d4-0310-9736-a25a8df6d016:12805
svk:copy_cache_prev:
8095
Message:

Ortographe, typographie, franglais, et langage familier.

Files:
1 modified

Legend:

Unmodified
Added
Removed

  • mirror/edenwall/nulog2/trunk/doc/nucentral.rst

    r8101 r8102  
    6565 
    6666 
    67 Techniquement, un appel se déroule comme suit:: 
     67Techniquement, un appel se déroule comme suit : 
    6868 
    6969   Supposons un composant compA attaché à NuCentral2 et cherchant à appeler 
    … …  
    7575   * NuCentral2 vérifie si le composant est un module local... 
    7676     Si c'est le cas : 
     77 
    7778       * NuCentral2 localise que le composant est attaché à NuCentral1, fait 
    7879         un appel par SOAP à celui-ci. 
    … …  
    8384       * NuCentral2 reçoit le résultat et le renvoie à compA qui aura été 
    8485         bloqué pendant le temps de la demande. 
     86 
    8587     Si jamais compB est attaché à NuCentral2 : 
     88 
    8689       * NuCentral2 appele la fonction directement compB.serv1, puis retourne 
    8790         tout de suite le résultat. 
    … …  
    9093 
    9194Note: le fonctionnement du dialogue entre les serveurs **NuCentral**, notament 
    92 pour la synchronisation des données, sera décrit dans le chapitre **II. NuCentral-to-NuCentral**. 
     95pour la synchronisation des données, sera décrit dans le chapitre `NuCentral-to-NuCentral`_. 
    9396 
    9497Le problème 
    … …  
    123126synchrone ou non. 
    124127 
    125 Un service taggée **synchrone** fonctionnnerait ainsi : 
     128Un service taggé **synchrone** fonctionnnerait ainsi : 
     129 
    126130  * Elle renverra obligatoirement le résultat tout de suite. 
    127131 
    128132Un service taggé **asynchrone** aurait le comportement suivant : 
     133 
    129134  * Si elle retourne un objet de type Deferred, il sera transmis tel quel 
    130135    à la procédure appelante. 
    … …  
    138143pour le composant, que ce service soit *local* ou *distant*. 
    139144 
    140 Le déroulement d'un appel à une fonction asynchrone serait le suivant:: 
     145Le déroulement d'un appel à une fonction asynchrone serait le suivant : 
    141146 
    142147   Un composant compA attaché à NuCentral2 veut appeller compB.serv1, 
    … …  
    146151     de NuCentral2. 
    147152   * NuCentral2 détermine la localisation du composant. Deux cas se 
    148      distingues alors. 
     153     distinguent alors. 
    149154     Si compB est local: 
     155 
    150156       * NuCentral2 fait appel à la fonction du service directement. 
    151157       * Si le résultat renvoyé est un Deferred, il le transmet directement 
    … …  
    155161       * La procédure appelante ajoute un callback au Deferred afin de 
    156162         récupérer le résultat. 
     163 
    157164     Si compB est distant: 
     165 
    158166       * NuCentral2 fait un appel SOAP à NuCentral1. 
    159167       * NuCentral1 appelle le service. 
    … …  
    175183L'intérêt principal de NuCentral réside dans la transparence qu'il apporte 
    176184pour l'appel de fonctions d'un composant à un autre, quelque soit la 
    177 localisation physique de celui-ci (en local ou à distance). 
     185localisation physique de celui-ci (local ou distant). 
    178186 
    179187La réalisation de ceci passe par une mise en relation de différents **NuCentral**, 
    180188afin que lorsqu'un composant présent sur un NuCentral souhaite appeler un service, 
    181 NuCentral sache où il se trouve et y fasse la requète. 
     189NuCentral sache où il se trouve et y fasse la requête. 
    182190 
    183191Design 
    … …  
    186194La mise en réseau des différents NuCentral devrait être faite en étoile. 
    187195 
    188 En effet, un **NuCentral Master** serait désigné, et les **NuCentral esclaves** 
     196En effet, un **NuCentral maître** serait désigné, et les **NuCentral esclaves** 
    189197s'y connecteraient au lancement et à chaque mise à jour de leur liste de composants. 
    190198 
    191 Voici à quoi devrait ressembler le schema:: 
    192  
    193     .-----------. 
    194     |  Slave 1  |---------                    .-----------. 
    195     +-------+---'        |        ------------|  Slave 2  | 
    196     | comp1 |           \|/      \|/          +-------+---' 
     199Voici à quoi devrait ressembler le schema : :: 
     200 
     201    .-------------. 
     202    |  Esclave 1  |-------                    .-------------. 
     203    +-------+-----'      |        ------------|  Esclave 2  | 
     204    | comp1 |           \|/      \|/          +-------+-----' 
    197205    | comp2 |           .-------------.       | comp3 | 
    198206    '-------'           |             |       | comp4 | 
    199                         |   Master    |       | comp5 | 
     207                        |   Maître    |       | comp5 | 
    200208                        |             |       '-------' 
    201209                        '-----+-------+ 
    … …  
    204212                          |   '-------' 
    205213                          | 
    206                   .-----------. 
    207                   |  Slave 3  | 
    208                   +-------+---' 
     214                  .-------------. 
     215                  |  Esclave 3  | 
     216                  +-------+-----' 
    209217                  | comp6 | 
    210218                  '-------' 
    … …  
    213221------------ 
    214222 
    215 La détermination du status de **Master** ou **Slave** se fait par 
     223La détermination du status de **Maître** ou **Esclave** se fait par 
    216224le simple fait qu'un serveur possède ou non dans sa configuration 
    217 un serveur SOAP auquel se connecter afin de s'anoncer. 
    218  
    219 L'esclave ne pourra pas accepter de requettes d'anonce. 
     225un serveur SOAP auquel se connecter afin de s'annoncer. 
     226 
     227L'esclave ne pourra pas accepter de requête d'annonce. 
    220228 
    221229En revanche, on peut supposer qu'un *réseau* de NuCentral pourra 
    222 être lui même déporté à un autre. C'est à dire qu'un NuCentral Master 
     230être lui même déporté à un autre. C'est à dire qu'un NuCentral Maître 
    223231pourrait se connecter à un autre NuCentral, comme esclave cette fois, 
    224 afin d'anoncer tous les composants qu'il possède. Le problème dans ce 
     232afin d'annoncer tous les composants qu'il possède. Le problème dans ce 
    225233schema là est qu'un autre NuCentral Client serait susceptible de se connecter 
    226 à ce Master alors qu'il voulait accéder au Slave 3. 
     234à ce Maître alors qu'il voulait accéder à l'Esclave 3. 
    227235 
    228236En bref ce cas est peut être compliqué à gérer alors qu'il peut paraitre inutile. 
    229237 
    230238Le serveur défini dans sa configuration son mot de passe, et les clients doivent 
    231 anoncer dans l'appel de fonction le mot de passe. 
     239annoncer le mot de passe dans l'appel de fonction. 
    232240 
    233241On passe uniquement la liste des composants et pas des services. 
    … …  
    236244--------- 
    237245 
    238 Le déroulement d'une anonce se fait dans les grandes lignes ainsi :: 
    239  
    240   -> Connexion de Slave2 à Master1 par SOAP, appel une fonction 
    241      en passant le mot de passe et la liste des composants 
    242   <- Réponse de Master1 avec la liste de ses composants et de 
     246Le déroulement d'une annonce se fait de cette manière : :: 
     247 
     248  -> Connexion de l'Esclave2 au Maître1 par SOAP, appel une fonction 
     249     en passant le mot de passe et la liste des composants. 
     250  <- Réponse du Maître1 avec la liste de ses composants et de 
    243251     ceux des autres esclaves. 
    244   <- Master1 envoie la liste des composants de Slave2 à tous 
     252  <- Maître1 envoie la liste des composants d'Esclave2 à tous 
    245253     les autres esclaves. 
    246254 
    247 Par la suite, Slave2 peut réenvoyer sa liste afin de la mettre à jour, ce qui 
    248 informera tous les autres esclaves. Du coup Slave2 pourra lui même être prévenu 
     255Par la suite, Esclave2 peut réenvoyer sa liste afin de la mettre à jour, ce qui 
     256informera tous les autres esclaves. Du coup Esclave2 pourra lui même être prévenu 
    249257des mises à jour. 
    250258 
    251 Chaque Slave a maintenant la liste complète des composants disponibles et leur localisation. 
     259Chaque Esclave a maintenant la liste complète des composants disponibles et leur localisation. 
    252260Il sera ainsi aisé à celui-ci de se connecter **directement** au NuCentral concerne. 
    253261 
    … …  
    261269 
    262270En effet, bien qu'à la fermeture *propre* de **NuCentral**, celui-ci devrait 
    263 avoir l'amabilité d'informer le Master de son indisponibilité, il est probablement 
     271avoir l'amabilité d'informer le Maître de son indisponibilité, il est probablement 
    264272possible qu'il disparaisse subitement en cas de crash, de coupure de courant, de 
    265273réseau, etc. 
    266274 
    267 Une solution peut se situer dans un système de ping par SOAP, mais cela me parraît 
    268 d'une laideur sans nom. 
     275Une solution peut se situer dans un système de ping par SOAP, mais cela me paraît 
     276être une solution peu élégante. 
    269277 
    270278Une seconde solution serait que lorsqu'un NuCentral tente de se connecter à un NuCentral 
    271 qui est censé être up, si il échoue, il prévient le master de ceci qui met à jour la liste. 
     279censé être disponible et qu'il échoue, il prévient le maître qui met à jour la liste. 
    272280 
    273281Sécurité 
    … …  
    276284Quelques questions de sécurité se posent. Tout d'abord du point de vue de l'authentification 
    277285des esclaves. Le choix d'utiliser un mot de passe est plus correct, surtout que celui-ci 
    278 passera en crypté par SSL. 
    279  
    280 Ensuite, l'authentification du master est plus importante. Lorsque celui-ci fait son 
    281 anonce aux esclaves, il devrait anoncer également un mot de passe ou une connerie 
    282 de ce genre. 
     286sera transmis dans un tunnel chiffré (SSL). 
     287 
     288Ensuite, l'authentification du maître est plus importante. Lorsque celui-ci fait son 
     289annonce aux esclaves, il devrait annoncer également un mot de passe ou autre. 
    283290 
    284291Enfin, les composants doivent être empêchés d'appeler une fonction de synchronisation 
    … …  
    291298^^^^^^ 
    292299 
    293 Dans le présent brouillon, je décris un cas d'utiliser ou tous les nucentral sont 
     300Dans le présent brouillon, je décris un cas d'utilisation où tous les Nucentral sont 
    294301sur le même réseau. 
    295302 
    296303En effet, considérons la topologie réseau suivante:: 
    297304 
    298    .--------.    | 
    299    | Slave1 |    |       .--------. 
    300    '--------'    |       | Slave2 | 
    301         \        |       '--------' 
     305   .----------.  | 
     306   | Esclave1 |  |       .----------. 
     307   '----------'  |       | Esclave2 | 
     308        \        |       '----------' 
    302309         \       |      / 
    303310          \      |     / 
    304311           .----------. 
    305            |  Master  | 
     312           |  Maître  | 
    306313           '----------' 
    307314                 | 
    308315                 | 
    309316 
    310 On a un Slave2 qui n'a pas d'accès direct à Slave1 par le réseau. 
    311  
    312 Le Slave2 ne pourra ainsi pas se connecter au Slave1 si il veut 
    313 faire une requette que celui-ci possède. 
    314  
    315 Ceci est un cas relativement tordu, mais à considérer peut être je pense. 
     317On a un Esclave2 qui n'a pas d'accès direct à Esclave1 par le réseau. 
     318 
     319L'Esclave2 ne pourra ainsi pas se connecter au Esclave1 si il veut 
     320faire une requête que celui-ci possède. 
     321 
     322Ceci est un cas relativement tordu, mais qu'il faut peut être considérer. 
     323