Services Web

nécessaire
de savoir comment elles sont mises en oeuvre pour s’en servir. Comme les composants
COM, ils ont des interfaces bien définies. L’interface d’un service Web, que Microsoft
appelle contrat, décrit les messages que le serveur Web acceptera et générera.
Marque d’une évolution franche par rapport à  Window DNA, l’architecture à  n niveaux
de Microsoft basée sur COM, les applications construites avec le .NET Framework
n’utilisent pas le protocole propriétaire DCOM (Distributed DOM) de Microsoft.
à€ la place, Microsoft construit .NET sur les standards XML émergeants et le protocole
SOAP (Simple Object Access Protocole). Le protocole SOAP utilise un schéma d’encodage
XML pour permettre l’appel de procédure distante (RPC) via le protocole HTTP.
(Pour plus d’information sur SOAP, lisez l’article de Microsoft  » SOAP : Simple
Object Access Protocole  » à  l’adresse http://www.msdn.microsoft.com/sml/general/soapspec.asp.)
Les développeurs n’utiliseront plus COM et COM+ pour créer des applications .NET,
mais ces modèles logiciels ne disparaissent pas. Le Microsoft .NET Framework utilisera
COM et COM+ comme des services intermédiaires et, parmi ces services, de nombreux
feront appel à  des objets COM sous-jacents.

La plupart des building-block services de Microsoft .NET seront disponibles aussi
bien online que offline. On pourra appeler un service sur un poste de travail
standalone classique, sur un service local, ou à  travers l’Internet. On pourra
utiliser les building-block services .NET sur toute plate-forme qui supporte XML.
Cependant, Windows.NET offrira le meilleur environnement pour créer et exploiter
les services Web et Microsoft optimisera les clients Windows pour distribuer les
services Web vers toutes sortes de devices.

La Figure 3 présente une vue d’ensemble des services Web que comprendra le Microsoft
.NET Framework. De façon très similaire aux machines virtuelles Java, le langage
commun d’exécution de Microsoft .NET tourne au dessus du service d’OS de base.
Toujours à  l’instar de Java, le runtime en langage commun n’exécute pas de code
spécifique à  la machine. à€ la place, le runtime en langage commun qui est un interpréteur
de code exécutable, exécute un langage indépendant du code source appelé Microsoft
Intermediate Language (MSIL). MSIL permet de constituer une couche d’abstraction
matérielle qui isole le code de l’application de la plate-forme hardware sous-jacente.
Théoriquement, on pourrait mettre en oeuvre un runtime MSIL sur une plate-forme
non Windows.

Pourtant, contrairement aux machines virtuelles Java, le runtime en langage commun
permet une intégration multi-langage approfondie car il permet au code d’hériter
de l’implémentation des objets et classes écrite dans n’importe quel langage compatible
.NET. Microsoft prévoit de fournir trois langages compatibles avec l’architecture
.NET : Visual Basic (VB), Visual C++ (VC++) et le nouveau C# de Microsoft. L’éditeur
travaille en outre avec d’autres fournisseurs pour intégrer d’autres langages
dans le .NET Framework. Bien que Java soit encore exclu des langages compatibles
avec .NET, des éditeurs tiers assureront probablement le support de Java, Perl,
Python, COBOL et autres langages.

Microsoft appelle les appels de code écrits pour le runtime en langage commun
du code géré, et les programmes qui produit ce code ne sont pas des fichiers EXE
ou DLL normaux. à  la place, Microsoft appelle ces programmes assemblages, qui
peuvent être constitués d’un seul fichier (à  l’instar des fichiers EXE actuels)
ou partie d’un assemblage de plusieurs fichiers (comme une DLL). Un manifeste,
contenu dans l’assemblage, définie la collection de composants qui constituent
l’assemblage.