.Net Remoting

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.

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.

Objectif

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)

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.

DEMO 1 MBR

Code client et serveur dans le même assemblage.

Domaine d’application client et serveur dans le même processus.

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.

• Comportement:– L’état du clone et de l’objet original sont

indépendants.– Les changements de l’un n’affecte pas l’autre.

DEMO 2 MBV

Code client et serveur dans le même assemblage.

Domaine d’application client et serveur dans le même processus.

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");

Demo3

Avec MBR Pas d’appel de constructeur de classe car le proxy

n’est pas de même type que l’objet distantAvec MBV

Le constructeur de d’instance n’est pas appelé lors de la création du clone

Architecture distribuée

• 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.

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).

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.

Formatteurs

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

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’

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.

SingleCall

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

Démo 4 Net Remoting

Activation par le serveur: single Call

Singleton

Activation client

Gestion de la durée de vie

Configuration du serveur

Configuration du Client

Modèle de déploiement

Sécurisation