Passer au contenu

.NET : l’application distribuée selon Microsoft

Après J2EE de Sun, .NET prône le développement orienté composants et se révèle parfaitement adapté à la production d’applications exploitant des services web.

Avec .NET, Microsoft dévoile sa vision des systèmes d’information orientés composants. Comme pour J2EE, l’adoption de l’architecture .NET passe par celle du modèle de développement qui lui est associé : outillage technique (Visual Studio .NET, IIS 5.0, etc.), méthodes de codage et d’assemblage des composants… Les deux architectures sont assez proches et s’appuient sur un découpage désormais classique des applications en trois parties logiques : interface utilisateur sur client léger (navigateur web), composants mettant en ?”uvre la logique applicative sur un premier serveur, et l’accès aux données sur le dernier tiers. Une application .NET se décompose en fichiers texte contenant du code ASP (Active Server Page), du code HTML, des procédures stockées, etc. Outre le serveur web (IIS 5.0), le tiers central est un environnement d’exécution comprenant le CLR (Common Language Runtime) et la bibliothèque de classes .NET. Le CLR offre les services techniques nécessaires au déploiement de l’architecture .NET : isolation des classes (gestion des versions, conflits de noms, etc.), cache mémoire (données et traitement) et allocation des ressources aux applications. .NET installe sur ce même tiers deux types de composants : les ASP.NET Web Forms et les classes ADO.NET. Les premiers sont chargés de la logique applicative et de la génération dynamique de l’interface utilisateur (code HTML, structures XML, etc.). Les seconds sont chargés des accès aux données de SQL Server, mais aussi de toute base aux standards OLE DB et ODBC. Ces accès se font par des procédures stockées, encapsulées au sein de classes spécifiques. L’emploi de ces procédures est, selon Microsoft, le seul moyen de préserver l’intégrité et la cohérence des données, tout en respectant l’esprit du modèle 3-tiers.Les composants métier, les Web Forms, assurent la génération des pages web dynamiques. Ces composants (stockés au sein de fichiers texte, d’extension .aspx), compatibles avec le modèle ASP classique, sont écrits en C#, Jscript ou VB et peuvent naturellement contenir du code HTML statique. Une fois développé, chaque Web Form est compilé dynamiquement par le module d’exécution CLR, lors de son premier appel par une application cliente (appel de l’URL associée à la ressource).Pour développer les applications .NET, dont les Web Forms, Microsoft a peaufiné Visual Studio .NET. Cette version adaptée de l’environnement de développement offre des fonctions pratiques facilitant la production, l’intégration et la mise au point des applications : conception des Web Forms à l’aide d’un éditeur Wysiwyg, navigateur d’objets, gestionnaire de configuration, kit de développement d’applications pour terminaux mobiles (PDA et Pocket PC avec Windows CE, téléphones cellulaires WAP), etc. Plus avant, la création d’une application ASP.NET nécessite celle d’un répertoire virtuel sur le serveur web. Ce répertoire doit contenir au minimum un fichier d’extension .aspx (ou .asmx) dont le premier appel provoque la compilation et la création d’une instance de l’application. La configuration de production des applications .NET est décrite dans un fichier spécifique contenant des directives de déploiement nécessaires à chaque contexte d’exécution.

Le cas particulier des services web

Face médiatique de .NET, les services web sont développés à partir d’extensions spécifiques de .NET, comme la gestion complète en natif de Soap et d’UDDI. Les services web, très proches des Web Forms, partagent avec ceux-ci les grands principes de l’architecture : ils sont adressables par URL, codés en C#, Jscript ou VB et peuvent faire appel aux mêmes ressources (Server Controls notamment). Une extension de fichier propre (.asmx) et l’emploi d’une directive spéciale (Web Service) les distinguent toutefois des composants ASP.NET. Cette directive informe .NET que le composant doit être considéré comme un service web, ce qui implique une localisation par UDDI, une découverte dynamique des méthodes publiques proposées, un accès par des requêtes Soap en HTTP… Un proxy au format WSDL peut être généré automatiquement sur simple appel de l’outil Web Service Description Language fourni en standard. Enfin, l’utilisation (facultative) de SQL Server 2000 OpenXML 2.0 facilite le développement de services web ou verts et plus généralement de toute application XML. Cette extension du SGBDR simplifie et uniformise notamment les échanges entre les classes ADO.NET, les objets ASP.NET ainsi que les procédures stockées.

Une puissante gestion du cache

Dans le cadre des applications distribuées orientées services, les performances sont principalement conditionnées par un système efficace de gestion de la mémoire cache. Dans ce cadre, .NET propose des techniques sophistiquées d’optimisation, qui peuvent être adaptées à chaque contexte de production.Le premier appel d’une ressource cachée (page, données, etc.) donne lieu au chargement de la mémoire cache. Le deuxième appel de cette même ressource donnera lieu à un simple transfert depuis la mémoire cache, sans provoquer d’analyse (parsing) ou de compilation de code, ni d’exécution de procédure stockée ou de requête SQL. Un délai est associé à chaque ressource afin de procéder, lorsque nécessaire, au rechargement du cache. Ce délai est spécifié lors du développement du composant, il peut aussi être contrôlé dynamiquement..NET propose trois modes de gestion du cache : chargement du code complet d’une page HTML dynamique, fragmentation de la page et association à chaque fragment d’un délai spécifique ?” cette technique permet d’optimiser au mieux les performances pour des pages dont certains champs varient d’un appel à un autre ?” et, enfin, développement complet par le développeur d’une politique de gestion du cache en fonction des objets concernés.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Laurent Maury