.net Remoting Chapitre 1 : Introduction au.net Remoting Maxime LAMURE I : Présentation... 2 II : Principe de base... 3 1.1 Introduction... 3 1.2 Architecture :... 4 III : Outils et compilateurs... 7 IV : Méthodes type de développement... 8 1 : Au niveau Serveur... 8 2: Au niveau Client... 8 V: Exemple simple: Hello World... 9 5.1 : Interface... 10 5.2 : Serveur... 11 5.3 : Client... 13 5.4 : Compilation... 13 5.5 : Exécution... 14 5.6 : Amusons nous et observons... 14 VI : Conclusion... 15 Annexe A : Liens... 16
I : Présentation Le but de cet article est de vous exposer ce qu est le.net Remoting le plus simplement possible. Pour ce faire, je ne vais pas détailler tous les aspects techniques, mais vous montrer un premier mécanisme d application en expliquant les bases nécessaires. A travers ce premier article, je vais expliquer les différentes notions nécessaires pour construire une application distribuée. Je présenterai un exemple simple en détaillant les différentes étapes. Des articles complémentaires insisteront plus sur les détails techniques, ainsi que les différentes façons de monter une application distribuée avec le.net Remoting. 2
II : Principe de base 1.1 Introduction La technologie.net Remoting (que j appellerai Remoting par la suite) est la dernière technologie de Microsoft permettant de faire de la programmation repartie en utilisant la plateforme.net. On parle de programmation répartie lorsqu on utilise plusieurs machines pour exécuter un processus. En d autres termes, une application qui tourne sur une machine A peut lancer un processus sur une machine B distante et récupérer le résultat. Domaine d application sur une Machine A Domaine d application sur une Machine B Pile d exécution Pile d exécution On appelle une méthode sur un objet. On récupère le résultat. On effectue le traitement d une méthode à la demande d un client. On retourne le résultat On a économisé le coût du traitement au détriment du serveur. On a effectué le traitement pour le client. L intérêt est de développer les traitements sur un serveur accessible par des applications clientes qui peuvent l interroger et récupérer les résultats. Les applications clientes sont donc plus légères. De plus, la technologie.net permet l interopérabilité entre les langages et les plateformes. Les applications clientes peuvent donc être développées dans des langages différents et tourner sur des systèmes différents. 3
1.2 Architecture : A : Fonctionnement Client Serveur Message Message Formateur Formateur Message Formaté Message Formaté Canal Canal Requête Réponse Les applications communiquent entre elles en s envoyant des messages. Pour ce faire, ces derniers sont codés, formatés afin qu ils puissent être envoyés sur le canal et transmis entre applications. Ce codage est assuré par des formateurs. Il peut être binaire (TCP), textuel avec SOAP-XML (HTTP) ou bien défini par le développeur. (cf article 2 pour plus de précision) B : Les proxies Les proxies sont les représentants locaux des objets distants. Quand on veut communiquer avec un objet distant, on créé un proxy qui sera la représentation locale de cet objet. Pour appeler les méthodes de l objet distant, il suffit de récupérer le proxy et d appeler les méthodes sur ce dernier. On peut donc dire qu au niveau client, une fois le proxy créé, on l utilise comme un objet local, sans se soucier du codage des messages. 4
C : Le rôle de l interface La question qu on peut se poser est comment une application cliente indépendante peut connaître le type d objet qu elle va recevoir. En d autres termes, lorsqu on demande une référence, il nous faut donner son type pour la récupérer. Pour palier à ce problème, le.net Remoting utilise les interfaces qui seront un moyen pour le serveur de publier le type de l objet ainsi que la signature de ses méthodes distantes. Le serveur devra donc implémenter cette interface. Un client peut connaître les méthodes de l objet distant grâce à cette interface mais aussi de récupérer une référence dans une variable de ce type (Voir l exemple chapitre V.2.3). Quand un client récupérera une référence, il pourra accéder aux méthodes dont la signature est donnée dans l interface et uniquement celles là. En effet, le serveur pourra développer d autres méthodes non accessibles à distance et donc, qui ne figureront pas dans l interface. D : Mode de passage des objets En.net, les objets sont passés par référence et les types primitifs (int, short ) par valeur. Mais cela est valable lorsque nous sommes dans le même domaine d application. En effet, la référence d un objet dans un domaine d application A n a plus de valeur dans le domaine d application B. Pour palier à cela, lorsque qu on passe des objets en paramètre ou en résultat d une fonction d un objet distant, le passage se fait alors par valeur. Pour ce faire, ils doivent implémenter l interface ISerializable. Enfin, si on veut qu un objet soit un objet distant, il doit dériver de MarshalByRefObject. E : Type d appels Lorsqu un client fait des appels sur un objet distant, il y a forcément la création d une instance de cet objet au niveau serveur. Nous allons voir les différentes solutions que nous avons à ce niveau. (voir V.5.6) Mode Singleton : Tous les messages entrant utilisent le même objet. En d autres termes, toutes les applications clientes qui font appel à un objet remote, utilisent la même instance de cet objet. On peut donc modifier l état de l objet distant par un appel et cet état sera conservé pour les appels suivants. Mode SingleCall : Chaque message entrant utilise une nouvelle instance de l objet. A chaque client est associé une nouvelle instance coté serveur. 5
F : Le Service de nommage En.net, pour qu un client récupère une référence sur un objet distant, il doit communiquer directement avec le serveur à partir d un port et d une URL. Nous verrons dans les prochains articles, qu il est possible de créer un service de nommage qui joue le rôle d un annuaire de références d objets distants. G : Le ramasse miette Les objets distants ont une durée de vie. En effet, si un objet n est plus utilisé, on peut dire que personne ne pointe sur lui et qu il est déréférencé. Au niveau serveur, il existe un mécanisme qui inspecte le domaine d application et qui supprime toutes les instances non référencées. On appelle cela le ramasse miette. Lorsqu un objet est créé, on lui associe une durée de vie. Quand elle atteint 0, cette instance est susceptible d être supprimée par le ramasse miette. Pour palier à cela, nous avons la possibilité d augmenter la durée de vie d un objet : Dès qu on utilise cet objet, sa durée de vie est initialisée à la valeur maximale. On peut directement augmenter la durée de vie d une instance à l aide de fonctions spécifiques. Enfin, on peut modifier les propriétés des ramasses miettes pour contrôler la durée de vie des objets. 6
III : Outils et compilateurs Pour développer des applications distribuées, il ne faut rien de plus que pour développer une application normale. Néanmoins, il est plus facile et donc plus productif d utiliser des IDE. Malgré son prix, je conseille fortement Visual Studio.net qui me parait être l IDE le plus complet à ce niveau. Sinon il existe un IDE gratuit, C# Builder, qui est très bien fait. Enfin, vous pouvez toujours utiliser un éditeur de texte pour taper votre code.net et compiler avec le compilateur (gratuit) de Microsoft fournit avec le framework. 7
IV : Méthodes type de développement Maintenant que nous avons les bases, nous allons voir les différentes fonctions, librairies que nous fourni.net pour nous aider à construire une application distribuée. 1 : Au niveau Serveur Tous d abord, il nous faut les trois packages suivant. using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Tcp ; Ils vont nous permettre de nous fournir les librairies pour les actions suivantes: Ouverture du canal selon un protocole et sur un port TcpChannel chan = new TcpChannel(8085); Enregistrement du canal ouvert précédemment ChannelServices.RegisterChannel(chan); Publication de son type avec l URI et le mode pour y accéder RemotingConfiguration.RegisterWellKnownServiceType(typeof( HelloServer), "HelloServer", WellKnownObjectMode.SingleCall); 2: Au niveau Client Ici aussi, on a besoin des packages suivants : using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Tcp; Ces librairies vont nous permettre d accéder à un objet distant On ouvre un canal récepteur en fonction d un protocole TcpChannel chan = new TcpChannel(); On enregistre ce canal ChannelServices.RegisterChannel(chan); On récupère l objet à partir de l URI et de l interface (pour le type d objet) IRemote.Expose obj = (IRemote.Expose)Activator.GetObject(typeof(IRemote.Expose), "tcp://localhost:8085/helloserver"); 8
V: Exemple simple: Hello World Fini la théorie et passons à la pratique. Pour bien comprendre le mécanisme, je vais vous montrer le code d une méthode d un objet distant renvoyant juste une chaîne de caractères. Je vais aussi vous montrer le code client pour accéder à cet objet et appeler cette méthode. Voici une idée de l arborescence générale : 9
5.1 : Interface 10
5.2 : Serveur 11
12
5.3 : Client 5.4 : Compilation Pour l interface : csc /target:library Expose.cs Pour le client: csc /reference:c:\chemin_interface\bin\debug\iremote.dll Client.cs Pour le serveur: csc /reference :c:\chemin_interface\bin\debug\iremote.dll Serveur.cs 13
5.5 : Exécution Au niveau client comme au niveau serveur, il suffit de lancer l exécutable généré précédemment (le serveur avant le client ;-) ). 5.6 : Amusons nous et observons Modifions quelques options pour vérifier la théorie, notamment le mode de configuration de l objet distant (single call, singleton) : Mode Single Call : On lance le serveur, puis plusieurs clients. Quand on quitte le serveur voila ce qui s affiche : Mode Singleton : Même chose, mais le serveur réagit différemment : 14
VI : Conclusion Le but de cet article est de vous montrer qu il n est pas difficile de monter une architecture distribuée. Certes, il faut acquérir quelques notions supplémentaires, et même si je n ai expliqué que le minimum à travers cet article, j espère que vous avez perçu le mécanisme de ce type de développement. Une fois ce mécanisme bien assimilé, je vous conseille de lire les prochains articles qui vous montreront la puissance du.net Remoting. 15
Annexe A : Liens http://alain.vizzini.free.fr/essi2reso2.html http://www.dotnetguru.org/articles/remotingrmi.htm http://www.dotnetguru.org/articles/reflexion/remotingdrawbacks/remotingdrawbacks.html http://www.microsoft.com/france/outils/imprime/info.asp?mar=/france/msdn/technologies/tec hnos/framework/info/netframremotingintro.html&css=& http://www.microsoft.com/france/outils/imprime/info.asp?mar=/france/msdn/technologies/tec hnos/framework/info/netframremoting.html&css=& 16