.Net Remoting

1. .Net Remoting

2. Plan de cours • Domaines d’applications: • Programmation distribuées. • Utilisation des namespaces: • System.Serializable. • System.Runtime. • System.Runtime.Remoting. • System.Runtime.Serialization. • Pré requis: • Domaines d’application. • Interfaces. • Notion abordées: • Marshalisation. • Sérialisation. • Formatteurs d’objets • Canaux de communications.

3. Définition • .Net Remoting est l’infrastructure de la platefrome .net qui permet à des objets situés dans des domaines d’applications différents, de pouvoir se connaître et de pouvoir communiquer entre eux.

4. Objectif

5. Marshalisation et sérialisation • .Net Remoting présente 2 solutions pour l’appel de méthodes sur des objets distants: • Marshaling By Reference (MBR) • Marshaling By Value (MBV)

6. Marshaling By Reference • Appel de l’objet distant au travers un proxy transparent. • Nécessite: • D’avoir un accès que les métadonnées du type distant soient accessible à la compilation. • L’objet serveur doit dériver de la classe MarshalByRefObject.

7. DEMO 1 MBR Code client et serveur dans le même assemblage. Domaine d’application client et serveur dans le même processus.

8. Marshalling By Value • Fabrication locale d’un clone de l’objet distant (via serialisation et deserialisation). • Le clone prend exactement le même état que l’objet distant au moment de sa création. • Le clone n’est pas un objet distant il n’y a donc pas besoin de proxy transparent. • Aucun constructeur n’est appelé sur le clone, car il a déjà été appelé sur l’objet distant. • Nécessite : • De pouvoir charger l’assemblage distant. • L’objet distant ne doit pas contenir de références vers des objets non clonables.

9. Comportement: • L’état du clone et de l’objet original sont indépendants. • Les changements de l’un n’affecte pas l’autre.

10. DEMO 2 MBV Code client et serveur dans le même assemblage. Domaine d’application client et serveur dans le même processus.

11. UnWrap • Le .net framework scinde l’opération de récupération d’un objet distant en 2 étapes: • Récupération d’une instance de classe. • UnWrappage de cette instance. ObjectHandle hObj = appDomain.CreateInstance("Remoting_Demo3_MBR", "Foo"); Foo obj = (Foo)hObj.Unwrap(); • Il est possible d’effectuer les deux opérations simultanément via: Foo obj = (Foo)appDomain.CreateInstanceAndUnwrap("Remoting_Demo3_MBR", "Foo");

12. Demo3 Avec MBR Pas d’appel de constructeur de classe car le proxy n’est pas de même type que l’objet distant Avec MBV Le constructeur de d’instance n’est pas appelé lors de la création du clone

13. Domaine d’application du Client Assemblage contenant le code du client. Assemblage(s) contenant seulement les métadonnées de types des objets serveurs. Domaine d’application du Serveur Assemblage contenant le code de l’hôte. Assemblage(s) contenant les implémentations des objets serveurs et des métadonnées des types des objets serveurs. Architecture distribuée

14. Responsabilité d’un hôte • Créer un ou plusieurs canaux. • Exposer des classes ou des objets serveurs accessibles par les clients au travers d’URIs (Universal Ressource Identifier). • Mode d’accès. • Nom du serveur. • Identification de la ressource. • Maintenir le processus qui contient les objets serveur (gestion de la durée de vie).

15. Canaux • Objet permettant la communication à travers le réseau. • Un canal est identifié par: • Le port utilisé pour la communication, • Le protocole de communication servant à transporter les données (TCP, HTTP, IPC,…), • Le formatage des données, décrivant la façon dont celle-ci sont écrient (binaire, SOAP, XML,…) • Pour établir une communication il faut 2 canaux avec le même protocole et le même formatage de données, un coté client et un coté serveur.

16. Formatteurs

17. Activation d’objet • En .Net Remoting on parle d’activation d’objet et non de création. • L’activation regroupe l’ensemble des processus induit entre la demande de création et la mise à disponibilité de l’objet distant. • Différents modes d’activation: • Activation par le Serveur • singleCall. • Singleton. • Activation par le Client

18. Activation par le serveur • Le client n’a pas a connaitre la classe dont l’objet distant est instance mais uniquement les interfaces d’accès à cet objet. • Les définitions d’interfaces sont regroupées dans un ou plusieurs assemblage spécialement prévu à cet effet. • Ces assemblages sont connu par les clients et par l’hôte exposant l’objet distant. • Ces assemblages jouent le rôle de métadonnées de type des objets serveurs. • Dans l’activation serveur, les objets sur le serveurs sont créés lors de l’appel d’une méthode. • Les objets ne sont pas créés au moment de la déclaration d’une instance avec ‘new’. • Un objet activé par le serveur peut être créé en tant que ‘Singleton’ ou ‘SingleCall’

19. Architecture • Interface.dll • Regroupe les déclarations des interfaces implémentées par les objets distribués. • L’utilisation d’une interface permet de ne stocker chez le client qu’une description des classes auxquelles il a accès. • Les interfaces permettent aussi de pouvoir mettre à jour le code de l’objet publié, sans toucher aux clients. • Serveur.exe • Implémente les types des objets distribués. • Référence Interface.dll qui permet de définir les accès aux objets distribués. • Contient le code de gestion du serveur permettant la publication des objets distribués. • Client.exe • Référence Interface.dll pour pouvoir accéder aux objets distants. • Contient le code permettant d’établir l’accès distant aux objets. • Contient le code métier de l’application cliente exploitant les objets distribués.

20. SingleCall • Le système d’accès distant crée un objet pour chaque méthode cliente appelant l’objet distant.

21. Démo 4 Net Remoting Activation par le serveur: single Call

22. Singleton

23. Activation client

24. Gestion de la durée de vie

25. Configuration du serveur

26. Configuration du Client

27. Modèle de déploiement

28. Sécurisation