|
|
 |
Microsoft .NET |
|
Plan
Objectif
Généralités
Schéma général de fonctionnement
Cycle de vie
Langages de développement
Espace de nom
Les assemblages
Gestion de la mémoire
Ouverture vers le monde non-pc
Reprise de l'existant
Paramétrage de l'application web
Gestion des transactions
Gestion des erreurs
Gestion des sessions
ADO.NET
Spécificité
Services Web
Les commentaires sur cet article
Objectif
Ce document a pour but de présenter l'architecture Microsoft .net.
Généralités
.NET utilise une machine virtuelle (CLR) qui fonctionne aujourd'hui pour 25 langages (mais pas le java) sous Windows.
Cependant, le portage sur d'autres OS est prévu:
| Editeur |
Produit |
Remarques |
| Corel |
CLI 1.0 |
Adaptation de CLR pour FreeBSD |
| Halcyon Software |
Java.NET |
Après le portage des pages ASP sous Java, Halcyon Sofware annonce la mise en production d'un serveur d'application Java .Net |
| Logiciel Libre |
DotGNU |
Southern Storm Sofware, adhérent de Free Software Foundation, propose une version beta d'un environnement d'exécution .Net open source (avec compilateur C#) |
| Ximilan |
Mono |
Implémentation open source de .Net Developement Framework. Permet de porter .Net sous Unix |
| Source 01 Informatique n°1668 (01/03/02) |
L'environnement de développement est confié à Visual Studio.net (sortie le 13 février 2002)
Cet AGL intègre tout : le code source, le navigateur web, l'administration de SQL Server, les outils de modélisation...
Les différents acteurs d'un projet utilisent le même outil pour tout faire!
Schéma général de fonctionnement
Cycle de vie
Les ASP ne sont plus interprétées par IIS mais compilées à la volée.
Le fichier source (une trentaine de langages supportés) est déjà compilé en fichier MSIL (MS Intermediate Language). Ce code intermédiaire est indépendant de la plate forme (Pocket PC, Windows 2000...), unique pour tous les langages. Il compose, avec des MetaData (sécurité, description, version...) et le manifest, une assembly. Ceci se présente sous forme d'une dll ou d'un fichier exe.
Le class loader va compiler le MSIL en code Natif une première fois (Pré JIT - Pré Juste In Time, étape non obligatoire).
Au premier accès à la page par un internaute, la CLR va compiler à la volée la classe afin de générer un composant .Net. Ainsi, pour les internautes, futurs consommateurs du même service, la classe déjà compilée sera utilisée (gain en performance évident). Un mécanisme permettra de détecter une différence entre la classe compilée (dll ou exe) et le fichier source (.asmx).
Ce mécanisme de compilation très efficace ressemblant aux systèmes des jsp, n'existait pas en ASP 3.
Langages de développement
A la différence des autres architectures qui ne comprennent que le langage Java, les serveurs de Microsoft et l'environnement de développement Visual Studio.NET comprennent tous langages de programmation conformes au CLS (Common Language Specification) comme l'ASP.net, le C# (prononcez Ci-Sharp, ce langage est un mélange de C++ et Java), le VB.net, l'Eiffel.net ... (plus d'une trentaine de langages).
Une application pourra donc être écrite avec plusieurs langages compatibles (une partie en ASP.net et une autre en cobol.net) et fonctionner sur le même serveur (la CLR comprendra tous ces langages).
Pourquoi utiliser plusieurs langages?
- Ceci peut être intéressant afin de pouvoir collaborer entre développeurs ne pratiquant pas les mêmes langages et afin de conserver le langage avec lequel on est le plus productif
- Il est également possible de réutiliser un certain module d'une application existante dans un langage qui n'est pas celui de notre application.
- Certaines tâches se prêtent mieux à un langage spécifique (qui n'est pas celui de notre application).
Espace de nom
Les espaces de nom (namespaces) permettent d'appeler les fonctions sans spécifier leur packages.
Par exemple, si on n'importe pas le namespace System (via la directive import en VB ou using en C#), on devra écrire System.Console.Write() à la place de Console.Write().De même, si on importe System.Console, on pourra écrire directement Write(). Les différentes façons d'importer ces espaces de noms ne se distinguent pas au niveau de l'optimisation du code car le même fichier MSIL résultera après la compilation de deux codes sources implémentant les espaces de noms différents.
Les assemblages
Chaque assembly a obligatoirement un manifest qui liste le contenu de l'assembly. Cet assembly regroupe des fichiers qui ont des liens logiques (exe, dll, images...). Par exemple, si notre fichier utilise des méthodes comme System.Console.Write() ou Now() (pour avoir l'heure courante), des assemblages extérieurs comme mscorlib.dll (DLL principale du CLR .NET) ou Microsoft.Visual Basic seront inclus. Il faut que les fichiers liés soient dans le même répertoire (ils ne sont pas inclus physiquement dans l'assembly, juste liés). L'utilitaire AL.exe permet (en ligne de commande, sans Visual Studio.NET) d'ajouter des fichiers dans une assembly.
Une assembly regroupe aussi des meta données comme la langue utilisée ou bien la version.
Les assemblies sont privées (utilisables uniquement pour nos applications) ou publiques (partagées avec tout le monde).
Pour les assemblies privées, le déploiement s'effectue par copier-coller sans avoir à entrer des informations dans la base de registre ou bien Active Directory (comme avec COM).
Pour les assemblies partagées, le déploiement est plus complexe. Il faut les placer dans le GAC (Global Assembly Cache). GACUTIL.exe permet en ligne de commande de gérer le GAC. Cependant, une gestion plus simple est possible via l'explorateur.
Un cryptage par clé public/privé pour vérifier l'intégrité du message (et non l'authenfication) peut être mis en place.
Dans l'exemple ci-dessus, on remarque qu'il existe plusieurs assemblies identiques dans des versions différentes dans le GAC (plus le problème des dll qui remplacent des anciennes et mettent en péril des anciennes applications). Ce mode de fonctionnement peut être modifié afin de permettre de ne plus utiliser une ancienne dll. Il suffit de créer un fichier nom-de-la-dll.dll.config contenant le code suivant (redirrection des appels de la version 1.0.451.11958 vers le version 2.0.451.19800) :
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="SharedTimeComponent" publickeyToken="496ed8bd1d362eb2" />
<bindingRedirect oldVersion="1.0.451.11958" newVersion="2.0.451.19800" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
La version est définie par 4 nombres. Par exemple, l'assembly Microsoft.VisualC a pour version 7.0.9254.59748 (voir l'image précédente). 7 représente le numéro de version majeure, 0 la version mineure, 9254 le numéro de compilation et enfin, 59748 le numéro de révision.
Gestion de la mémoire
Contrairement au C++ mais à la manière de Java, le programmeur n'a plus à se soucier de détruire ses objets, libérer sa mémoire. Il existe un Garbage Collector (GC) dans .NET qui libère de la pile tous les objets n'ayant plus de référence chez aucun des clients. Le GC se lance automatiquement (et périodiquement) ou via la méthode System.GC.Collect (si on a besoin de libérer expressement de la mémoire ou bien après l'utilisation de ressources critiques comme des connexions aux SGBD). La méthode finalize() permet d'effectuer du traitement au moment où l'objet est nettoyé.
Ouverture vers le monde non-pc
Une librairie d'objets classiques (comme un objet calendar) est intégrée à .net. Ces objets s'exécutent sur le serveur.
Le serveur génère automatiquement le code nécessaire pour gérer les processus habituels tel que le contrôle de checkbox. Ceci permet de ne plus faire de javascript pour contrôler, par exemple, un nombre de cases cochées et déporte ainsi ce travail sur le serveur. Les navigateurs (les clients) sont donc allégés ce qui permet d'introduire plus facilement des périphériques non pc (possédant souvent beaucoup moins de ressources et incapables de gérer des codes javascript complexes).
Reprise de l'existant
Faut-il refaire tous les développements qui sont en architecture DNA classique ?
Non, COM, COM+ (COM avec la gestion des transactions) et COM 1.5 (version COM d'XP) sont considérés comme des objets.net. Techniquement, il faut mettre en place un wrapper RCW (Runtime Callable Wrapper) appelé à l'éxécution, qui joue le role de l'intermédiaire entre COM et CLR. Ce wrapper peut être obtenu via l'utilitaire TlbImp.exe.
Il faut noter qu'il faut libérer la mémoire après destruction d'une instance de l'objet car le RCW est passé hors de portée (et donc innaccessible) mais l'objet COM qu'il enveloppe ne sera réellement libéré que lorsque le RCW sera nettoyé. Il faut donc soit appeler le GC (Sytem.GC.Collect) ou mieux (plus rapide) spécifier que l'on veut supprimer uniquement les objets COM via la méthode Sytem.GC.Runtime.InteropServices.Marshal.ReleaseComObject.
De la même façon, un objet.net sera considéré comme un objet COM via le wrapper CCW (COM Callable Wrapper). Ce wrapper peut être fait automatiquement via VisualStudio.NET. Il faut également créer des entrées dans le registre afin d'enregistrer notre objet COM (via l'utilitaire RegAsm.exe). Ce mécanisme n'est à utiliser que dans le cas où on ait un client COM qui collabore avec une dizaine d'objets COM et que l'on veut adjoindre un service provenant d'un objet .NET.
Pour transformer un objet COM en objet .NET, il faut retravailler le code. Par exemple, les indices de tableau en VB commence à 1 alors qu'il débute à 0 en VB.NET. Cependant, dans Visual Studio.NET, à l'ouverture d'un projet VB6, l'AGL suggère des solutions d'adaptation vers VB.NET.
Déploiement
Il n'y a pas de verrouillage des objets .net, un simple copier-coller du nouveau composant suffit pour déployer la nouvelle version. Au premier appel à ce composant, ASP.NET détectera que le fichier source à changer et compilera à la volée cette dernière version (JIT - Just In Time). On n'a plus les problèmes de vérouillage, d'enregistrement dans le registre comme avec COM.
Paramétrage de l'application web
Le paramètrage de l'application web est déporté dans des fichiers Web.config. Ce fichier xml gère toute la configuration relative au répertoire dont il dépend. Il est possible par exemple, de mettre en place le mode debugage (<compilation defaultlanguage="vb" debug="true">), régler les droits d'accès (<allows users="managers"><deny users="*">), gérer les paramètres de sessions...
S'il n'y a pas de fichier Web.config dans le répertoire courant, la configuration hérite du répertoire parent.
Gestion des transactions
A l'identhique de MTS ou COM+, .NET gère les transactions (avec les SGBD supportés, comme SQL Server). Une transaction permet de traiter un lot d'évenements et de réagir si un des évenements échoue (roll back) . Par exemple, dans le milieu bancaire, lors d'un virement de 100F du compte A vers le compte B, si apres le débit du compte A le crédit du compte B échoue, la transaction pourra permettre un roll back (afin de recréditer le compte A). Pour utiliser le système de commit/roll-back, il faut enregistrer l'objet .NET comme un objet COM et avec l'explorateur COM+, installer ce composant dans une application COM+. Regsvcx.exe permet de faire ce traitement en une passe.
Gestion des erreurs
On retrouve le mecanisme de Java ou du C++ avec les try(), catch(), finally() et throw(), pour tous les langages CLS.
Gestion des sessions
Le web étant en mode non-connecté, l'utilisation de session est indispensable dans les applications web. Cette session peut être gérée par un service système (ASP.NET State). Pour ce mode de fonctionnement, il faut positionner dans le Web.config l'attribut mode du tag session state à "state server".
Cependant, la session étant stocké sur le serveur, dans le cas d'une ferme de serveurs, un problème peut apparaître. En effet, les requêtes d'un même client peuvent être exécutées par des serveurs différents. Dans ce cas, il est possible de déporter le stockage des sessions sur un même serveur, ce qui entrainera, en outre, une surcharge du reseau. Afin d'optimiser le système, il serait intéressant de rerouter les requêtes d'un même client sur le même serveur qui stokerait alors en local, les objets sessions.
Dans le cas d'un nombre de clients très élevé, il est possible de stocker les états des sessions dans SQL Server 2000 (mode="sql server").
L'objet Application permet de stocker des données qui varient, propres à l'application, comme par exemple des offres promotionnelles. Il faut noter que cet objet est très différent d'une session dans le sens où il ne possède pas de lien avec l'utilisateur connecté mais qu'il est propre à l'application.
ADO.NET
ADO.NET supportant le xml en natif, est une couche dédiée aux connexions avec les SGBD.
Elle n'a pas subi de changements majeurs par rapport à ADO. Les RecordSet sont remplacés par des DataRecorder. Il existe aussi une nouvelle structure, le DataSet, qui offre la possibilité de manipuler une représentation virtuelle déconnectée de la base de données. Cependant, cette structure est très gourmande en ressources serveur.
Spécificité
Microsoft (dans .net) enrichit SOAP avec des fonctions de routage de messages (WS-Routing - Web Services Routing protocol - décrit l'intégralité de la route en XML) et de traitements conditionnels (WS-Referral - Web Services Referral protocol - informations contenues dans l'enveloppe SOAP). Soap intègrerait alors des fonctions de MOM (Middlewares asynchrones) et de courtier de messages. Ces protocoles font l'objet d'une proposition de normalisation.
La CLR, le CLS et le C# sont déjà déposés à l'ECMA.
Service Web
Ce modèle très intéressant et très récent sera traité dans un autre document.
WebServices : l'implémentation dans .net.
V 1.1
Dernière MAJ : 26 Mars 2002
Contact : Cédric Carbone
Les articles du Forum traitant du même sujet
N'hésitez pas à faire un commentaire sur ce sujet en cliquant sur le lien suivant
