Ajout des cours 2 et 3

Cours Archi Client-Serveur/Architecture Client-Serveur.md

@@ -14,8 +14,6 @@ Les différentes "versions" de Java :
 
 - JEE : Entreprise
 
-
-
 Rapide rappel sur l'UML :
 
 | NomClasse               | Nom de l'objet                   |
@@ -53,3 +51,77 @@ RMI a une structure en couches
 | Stub                                                                                               |                                                            | Skell                                                          |
 
 À chaque appel à un objet distant, stub intercepte l'appel, et le communique au skell qui interroge l'objet, puis retransmet le résultat au stub qui le communique à l'appli.
+
+---
+
+*21/11/17 - Cours 2*
+
+Rappels sur RMI : Stub / Skel, RMIResgistry... Répétition du schéma de la sctructure au tableau.
+
+## Modèle de programmation
+
+D'abord l'interface : pour que le client connaisse l'alias + ce que fait l'objet
+
+Puis la classe qui implémente l'interface
+
+---
+
+*09/02/17 - Cours 3*
+
+## Conclusion
+
+RMI : client/serveur en java. C'est un peu vieux mais ça permet de comprendre comment ça fonctionne. 
+Les autres architectures qu'on va voir ensuite sont globalement basées sur la même philosophie.
+
+Se concentrer sur la communication plus que sur le traitement.
+
+
+
+# CORBA
+
+Même philosophie que RMI
+
+Architecture d'objets distribués (voir pdf) => architecture globale. 
+
+Le principe de fonctionnement est celui de RMI : client /serveur - appelant / appelé . 
+L'objectif est de pouvoir assurer cette communication, comme pour RMI
+
+## Architecture
+
+- Notion de client et de serveur
+
+- Couche TCP IP
+
+Chacun fait ce qu'il veut avec les objets. L'idée est que chaque demande se fasse dans un langage générique. 
+
+On implémente un BUS logiciel (ORB) dans lequel on fait passer les demandes. Dedans on a un traducteur qui traduit la demande en un format générique et la véhicule au serveur, qui retraduit. Les adaptateurs qui font la traduction sont les OA 
+
+### IDL
+
+Il y a toujours besoin d'une interface qui permet de savoir tout ce qu'on peut implémenter. Ici c'est IDL : un fichier texte dans un langage particulier qui implémente l'interface. Ce fichier est partagé par le client et le serveur.
+À partir de IDL, il y a une projection pour implémenter l'interface, chacun à sa façon selon s'il s'agit du client ou du  serveur. À l'issue de cette projection, IDL se décompose en 6 fichiers.
+
+On doit définir un module pour chaque "élément" (à préciser), on peut pas en envoyer seuls. 
+
+```ini
+    Module { 
+       Interface {  
+          Attributs : type nom options;   
+          Méthodes : type retour, statut, nom, paramètres type de passage (in ou out ou inout en entré en sortie ou les deux) 
+       }  
+    }
+```
+
+Tout modification au niveau de l'objet implique une régénération complète : on évite donc !
+
+### Suite
+
+On a aussi un daemon (daemon ORB = orb ), qui a le même fonctionnement qu'ailleurs : en tache de fond, il orchestre les communications.
+
+Ordre de démarrage :
+
+- orbd
+
+- serveur
+
+- client