La version 3.0 du Microsoft .NET Framework propose un ensemble varié de technologies, qui répondent chacune à un défi important en matière de développement d'applications.

David Chappell
Chappell & Associates

Juillet 2006

S'applique à :
Développement Windows avec
.NET Framework 3.0 (auparavant WinFX)

Résumé : La version 3.0 du Microsoft .NET Framework propose un ensemble varié de technologies, qui répondent chacune à un défi important en matière de développement d'applications. (29 pages imprimées)

Description du .NET Framework 3.0
Mise en œuvre du .NET Framework 3.0 : scénario
Comprendre le .NET Framework 3.0 : les technologies
Accéder au .NET Framework 3.0 : options de distribution
Conclusion
Lectures complémentaires

Sur cette page

Description du .NET Framework 3.0
Mise en œuvre du .NET Framework 3.0 : scénario
Comprendre le .NET Framework 3.0 : les technologies
Accéder au .NET Framework 3.0 : options de distribution
Conclusion
Lectures complémentaires

Description du .NET Framework 3.0

Le développement d'applications est toujours axé sur le même objectif : créer le meilleur logiciel possible dans les délais les plus courts. Cependant, l'amélioration des plates-formes sur lesquelles les développeurs génèrent leurs applications place la barre toujours plus haut. Dans Windows, par exemple, l'interface Win32 initiale a été remplacée par .NET Framework, bien plus fonctionnel. Avec la version 1.0 du .NET Framework, publiée en 2002 et la version 2.0, publiée en 2005, les concepteurs et auteurs de logiciels Windows ont eu accès à un environnement nettement amélioré qui a dopé leur productivité.

Le .NET Framework 3.0 (auparavant WinFX) est la dernière étape en date de cette progression. Les applications reposant sur cette nouvelle version du Framework peuvent être créées avec Visual Studio 2005, un environnement familier pour la plupart des développeurs Windows. Mais le .NET Framework 3.0 est aussi une évolution, qui complète les fonctionnalités déjà disponibles dans la version 2.0 du Framework. La disponibilité du .NET Framework 3.0, qui sera proposé pour Windows Vista, Windows Server 2003 et Windows XP, est prévue pour fin 2006.

Cet article propose une vue d'ensemble du .NET Framework 3.0 et de ses composants. Il a pour objectif d'exposer le contenu de cette nouvelle version, d'examiner comment ses technologies peuvent être utilisées et d'expliquer brièvement ces dernières.

Création d'applications évoluées : les enjeux

De nos jours, créer une application type n'est guère aisé : les impératifs sont nombreux. Aux difficultés classiques telles que le travail sur les données stockées et l'octroi d'accès via un navigateur Web, qui conservent toute leur importance, s'ajoutent de nouveaux défis :

• Les entreprises adoptent une vision de plus en plus orientée processus de leurs activités. Comme la plupart des applications automatisent une partie du processus commercial, il peut être utile de rendre explicites dans le code les étapes de ce processus. Pour cela, une solution efficace consiste à faire appel à la technologie de workflow, approche qui impose la prise en charge d'applications à base de workflow.

• Fréquemment, les applications communiquent avec d'autres applications internes ou externes à l'entreprise. Les applications actuelles doivent aussi souvent s'intégrer à une architecture orientée service (SOA) et exposer certaines de leurs fonctionnalités sous forme de services interopérables accessibles à d'autres logiciels. La réalisation de ces objectifs nécessite la prise en charge des applications orientées service.

• Les utilisateurs d'une application ont généralement besoin d'un moyen de transférer des informations sur leur identité. La définition et l'utilisation de l'identité numérique s'effectue au moyen d'un large éventail de technologies et les problèmes tels que l'usurpation d'identité sont courants. Sachant cela, une application actuelle et ses utilisateurs peuvent bénéficier du contrôle utilisateur cohérent des identités numériques.

• Les exigences des interfaces utilisateurs modernes se sont considérablement accrues. Pour offrir une réelle valeur commerciale, il peut souvent être nécessaire de travailler avec différents types de documents, d'utiliser des graphiques bidimensionnels et tridimensionnels, d'afficher des vidéos, etc. Toutes ces capacités doivent être disponibles pour les clients Windows natifs et les navigateurs Web. Pour répondre à ces besoins, il convient d'adopter une approche unifiée vis-à-vis d'interfaces utilisateur diversifiées.

Sachant que les applications actuelles doivent souvent répondre à tout ou partie de ces défis, la plate-forme servant à les générer doit également les prendre en charge de manière cohérente et exploitable. C'est précisément l'objectif du .NET Framework 3.0 pour les applications Windows.

Répondre aux défis : éléments fournis par le .NET Framework 3.0

Comme le montre la figure 1, la version 3.0 du .NET Framework s'appuie sur les versions antérieures. En fait, aucun des éléments disponibles dans la version 2.0 du .NET Framework n'a changé, de sorte que les applications existantes créées pour cette version continueront à fonctionner comme auparavant. Cependant, le .NET Framework 3.0 ajoute quatre nouveaux composants : Windows Workflow Foundation, Windows Communication Foundation, Windows CardSpace et Windows Presentation Foundation. Dans cette section, nous examinerons brièvement les éléments fournis par le .NET Framework 2.0 et chacun des nouveaux composants.

Figure 1

Le .NET Framework 2.0 : une base généraliste pour les applications Windows

S'il est possible d'écrire des logiciels utilisant directement l'interface Win32, le .NET Framework est désormais devenu le principal environnement de création des nouvelles applications Windows. Voici quelques-uns de ses composants majeurs :

• ASP.NET, qui prend en charge la création d'applications accessibles sur le Web.

• ADO.NET, qui permet aux applications d'accéder aux données relationnelles ou autres.

• Windows Forms, qui prend en charge la création d'interfaces graphiques pour les applications Windows.

• System.XML, qui permet aux applications de travailler sur des données définies en XML, y compris en utilisant XSLT et XPath.

La version 2.0 a permis d'ajouter différentes fonctionnalités utiles à la version précédente, notamment une technologie nettement améliorée pour la création d'applications Web ASP.NET, la prise en charge d'applications 64 bits s'exécutant sur les versions 64 bits de Windows et une nouvelle approche pour le traitement des transactions. Si certaines parties du .NET Framework 2.0 sont rendues obsolètes par les nouveaux composants ajoutés dans la version 3.0, comme nous le verrons ultérieurement, les technologies de la version 2.0 restent fondamentales dans cette nouvelle version.

Windows Workflow Foundation : prise en charge des applications à base de workflow

Le workflow repose sur un principe simple : il s'agit d'une série d'étapes effectuées dans un ordre donné. D'aucuns pourraient même dire que toute application implémente un workflow, puisque d'une manière ou d'une autre, elle exécute un processus. Cependant, l'approche classique lors de la création d'applications en C# ou Visual Basic ou tout autre langage de programmation consiste à rendre les étapes de ce processus implicites dans le code. Si cette méthode fonctionne indiscutablement, le processus lui-même est profondément noyé dans la logique de programmation, ce qui le rend plus difficile à implémenter et modifier.

L'utilisation de la technologie de workflow pour implémenter une logique de processus peut être une solution efficace face à ce problème. Elle consiste, au lieu d'imbriquer la logique dans du code ordinaire, à définir explicitement chaque étape du processus, puis à l'exécuter dans un moteur de workflow. Ainsi, l'implémentation du processus lui-même est bien plus claire.

Les moteurs de workflow n'ont rien de nouveau ; plusieurs d'entre eux sont aujourd'hui disponibles pour Windows et d'autres systèmes. Microsoft offre même des moteurs de workflow intégrés dans certains de ses produits. Cependant, comme le workflow constitue une approche de plus en plus courante pour la création d'applications, il semblait censé d'offrir une technologie de workflow unique pour Windows. C'est précisément l'objectif de Windows Workflow Foundation (dont l'acronyme officiel est WF). En proposant une technologie de workflow commune pour Windows, WF permet de bâtir n'importe quelle application de type workflow sur la même base. Les logiciels fournis par Microsoft, y compris Microsoft Office 2007 System et Windows SharePoint Services, ainsi que des applications créées par d'autres éditeurs, utiliseront WF.

Offrir une technologie commune de workflow présente cependant un certain nombre de difficultés. Par exemple, comment adopter une méthode unique pour répondre aux besoins variés des différentes applications de workflow ? Dans WF, la solution a consisté à considérer le workflow d'un point de vue très général. Comme le montre la figure 2, un workflow WF est simplement un groupe d'activités exécutées par le moteur WF. Chaque activité est en réalité une classe, qui peut contenir tout travail que le créateur du workflow juge nécessaire. Les activités peuvent être réutilisées dans différents workflows, ce qui facilite la création de solutions automatisées pour répondre à de nouveaux problèmes.

Figure 2

La division classique entre les workflows de type humain et les workflows de type système constitue également une difficulté lorsqu'il s'agit de proposer une technologie commune de workflow. Les applications de workflow principalement utilisées par les personnes doivent être souples et permettre des opérations telles que la modification du processus à la volée. Celles qui sont principalement utilisées par les systèmes, c'est-à-dire par le logiciel, ont tendance à être plus statiques, mais doivent être aussi efficaces que possible. WF est destiné aux deux types d'utilisations, c'est pourquoi il intègre des caractéristiques axées sur les utilisateurs humains, comme la possibilité de modifier un workflow en cours d'exécution, ainsi que des comportements plutôt orientés système.

En proposant avec WF une technologie de workflow pour Windows, le .NET Framework 3.0 permet à tous les développeurs d'opter pour ce modèle pour créer leurs logiciels. La vision orientée processus du logiciel étant appelée à connaître un succès croissant, l'utilisation du workflow va sans doute également progresser.

Windows Communication Foundation : la prise en charge des applications orientées service

Qu'elles soient bâties selon le modèle du workflow ou selon un autre principe, la plupart des applications sont appelées à communiquer avec d'autres. La façon dont cette communication s'effectue a fortement progressé ces dernières années. Après des années de désaccord, la plupart des grands éditeurs se sont entendus pour prendre en charge les mêmes protocoles pour la communication entre applications. Fondé sur SOAP, cet accord général sur les services Web rend l'interopérabilité entre les applications bâties sur des plates-formes de technologies différentes, telles que J2EE et le .NET Framework, bien plus simple qu'auparavant. Il rend également le principe d'une architecture orientée service bien plus plausible pour la plupart des entreprises.

Il existe, bien sûr, de nombreuses approches en ce qui concerne la communication. Dans le .NET Framework 2.0, par exemple, les choix disponibles sont les suivants :

• Services Web ASP.NET, qui proposent une communication de type SOAP interopérable.

• .NET Remoting, axé sur la communication entre les applications .NET.

• Enterprise Services, qui assure la prise en charge d'applications transactionnelles évolutives.

• System.Messaging, qui prend en charge les files d'attentes de messagerie via Microsoft Message Queuing (MSMQ).

• Web Services Enhancements (WSE), une extension d'ASP.NET Web Services qui assure le support de spécifications plus récentes telles que WS-Security.

Toutes ces technologies présentent un intérêt et ont chacune eu un rôle à jouer à un moment donné. Cependant, on peut se demander pourquoi il existe tant de solutions différentes pour répondre à un seul et même problème. Pourquoi ne pas établir plutôt un socle unique pour la communication entre applications reposant sur des services interopérables ?

C'est là l'objectif de Windows Communication Foundation (WCF). Plutôt que d'imposer aux développeurs d'utiliser une technologie différente et une interface de programmation spécifique pour chaque type de communication, WCF (« Indigo » à l'origine) offre une approche commune, via la même API. Dans l'environnement .NET Framework 3.0, la plupart des applications qui auraient pu utiliser l'une des technologiques que nous venons d'énumérer feront appel à WCF pour la communication.

WCF offre, via SOAP, élément essentiel des systèmes informatiques actuels, une base solide pour la prise en charge des communications interopérables. Il prend notamment en charge plusieurs spécifications WS-*, y compris WS-Security, WS-ReliableMessaging et WS-AtomicTransaction. Cependant, WCF peut se passer de SOAP, de sorte qu'il est possible d'utiliser d'autres solutions, y compris le protocole binaire optimisé MSMQ pour la gestion de messagerie avec files d'attente et REST pour les communications simples. L'approche de WCF vis-à-vis des communications est explicitement orientée service. Plutôt que de tenter d'assurer des communications transparentes entre les objets, WCF suit un principe légèrement différent, consistant à interposer un service entre les parties communicantes. Cela implique un desserrement de certains liens étroits propres aux systèmes d'objets distribués : les interactions présentent ainsi moins de risques d'erreurs et sont plus faciles à modifier.

La communication entre applications, au sein de l'entreprise ou avec l'extérieur, est une composante fondamentale des logiciels actuels. Pour faire face à ce défi, le .NET Framework 3.0 utilise l'approche orientée service de WCF.

Windows CardSpace : un contrôle utilisateur cohérent des identités numériques

Pensez à la façon dont les gens se voient sur Internet. Dans la plupart des cas, l'identité numérique d'une personne est exprimée sous la forme d'un simple nom d'utilisateur. Associée à un mot de passe, cette identité sert à accéder aux comptes de messagerie, aux commerçants sur Internet, voire aux banques en ligne et autres institutions financières. Cependant, malgré leur simplicité (et leur omniprésence), les noms d'utilisateur et les mots de passe ont plusieurs inconvénients, notamment les deux suivants :

• Il est difficile de se rappeler tous les noms d'utilisateur et les mots de passe choisis pour différents sites. De nombreuses personnes utilisent les mêmes valeurs pour différents sites, ce qui résout le problème de mémorisation mais accroît les risques pour la sécurité.

• Les noms d'utilisateur, les mots de passe et autres informations personnelles peuvent être détournés par les usurpateurs d'identité (« phishers »). Ceux-ci envoient des courriers électroniques falsifiés, qui incitent leurs victimes à se connecter à un site Web ressemblant, par exemple, à celui de leur banque. Ce site est en réalité contrôlé par le fraudeur qui, une fois que sa victime a entré son nom d'utilisateur et son mot de passe, peut utiliser ces informations pour se faire passer pour elle sur le vrai site de la banque.

Pour limiter ces risques, il convient d'adopter une autre approche dans la gestion des identités numériques. Windows CardSpace (nom de code initial « InfoCard »), est un élément important de cette approche. Pour aider les gens à assurer un suivi de leurs identités numériques, CardSpace représente chaque identité sous la forme d'une carte d'information distincte. Si un site Web accepte les connexions via CardSpace, les utilisateurs qui tentent de se connecter verront un écran de sélection CardSpace tel que celui présenté à la figure 3. En choisissant une carte, les utilisateurs choisissent également l'identité numérique qui servira à accéder à ce site. Plutôt que de mémoriser une multitude de noms d'utilisateur et de mots de passe, il leur suffit de reconnaître la carte à utiliser. Les cartes contiennent également des informations différentes, ce qui permet aux utilisateurs de contrôler exactement ce que le site sait à leur sujet.

Figure 3

Les identités que ces cartes représentent sont créées par un ou plusieurs fournisseurs d'identité. Toute entreprise peut proposer un fournisseur d'identité utilisant un mécanisme de cryptographie fort pour permettre à l'utilisateur de prouver son identité, au lieu de s'appuyer sur un simple nom d'utilisateur et mot de passe. CardSpace inclut également un fournisseur d'identité auto-émis qui s'exécute sur les machines clientes. Avec ce fournisseur, les utilisateurs peuvent créer leurs propres identités et disposer d'une authentification non basée sur les mots de passe. Les sites Web peuvent accepter ces identités CardSpace auto-émises au lieu de s'appuyer sur le système habituel à base de mots de passe, évitant ainsi les problèmes associés à ces derniers.

Si aucun mot de passe n'est utilisé pour ouvrir une session sur un site, les usurpateurs d'identité ne peuvent pas les dérober. Cependant, s'ils parviennent à attirer l'utilisateur sur un pseudo-site, ils peuvent être en mesure d'obtenir d'autres informations sur l'utilisateur, telles que des informations médicales sensibles. Pour éviter cela, les utilisateurs doivent être en mesure de faire la distinction entre les vrais sites et les copies falsifiées créées par les fraudeurs. À cet effet, une entreprise possédant un site Web peut obtenir un certificat d'assurance de niveau élevé. L'acquisition de ce type de certificat implique un processus bien plus rigoureux que celui en vigueur pour les simples certificats SSL actuels, avec notamment l'obligation de prouver de manière plus stricte que l'organisation à l'origine de la demande est bien ce qu'elle prétend être. Un certificat d'assurance à niveau élevé peut également comporter le logo d'une entreprise et d'autres informations qui aident l'utilisateur à déterminer correctement si un site employant ce certificat est légitime. Lorsqu'un utilisateur accède à un nouveau site, CardSpace affiche toujours les informations du certificat de ce site sur un écran standard. Selon la force du certificat reçu, cet écran indique différents niveaux d'assurance relatifs à l'identité du site. L'objectif est de forcer les utilisateurs à prendre explicitement la décision de faire confiance à un site et de les aider à bien choisir les sites dignes de confiance.

Windows CardSpace fait partie d'un métasystème d'identité plus vaste. Entièrement fondé sur des protocoles publics ouverts, ce métasystème définit un mode d'utilisation cohérent des technologies d'identité numérique sur les différentes plates-formes (y compris des systèmes d'exploitation autres que Windows) et dans diverses applications (y compris des navigateurs Web autres qu'Internet Explorer). En offrant une méthode commune pour sélectionner des identités et les autres informations dans Windows, CardSpace remplit une fonction capitale dans le métasystème. De plus, comme il résout le problème fondamental de l'identité, CardSpace joue également un rôle important dans le .NET Framework 3.0.

Windows Presentation Foundation : une approche unifiée des différentes interfaces utilisateur

L'interface utilisateur est un élément important de quasiment toutes les applications. Pourtant, les attentes des utilisateurs en la matière ont notablement évolué. Les interfaces utilisateur pilotées par menu sont toujours nécessaires, mais les applications ont parfois besoin d'afficher de la vidéo, d'exécuter des animations, d'utiliser des graphiques en trois dimensions et d'exploiter différents types de documents. Tout cela doit être possible quel que soit l'accès à l'application : depuis un ordinateur de bureau client installé ou via un navigateur Web.

Tous ces aspects de l'interface utilisateur ont été pris en charge différemment sous Windows. Par exemple, un développeur peut utiliser Windows Forms, qui fait partie du .NET Framework, pour créer une interface utilisateur Windows. La création d'une interface de navigateur Web implique l'utilisation du HTML et éventuellement d'applets Java ou de code JavaScript. Pour afficher des vidéos, il est possible d'utiliser Windows Media Player ou un logiciel comme Flash Player d'Adobe. Quant aux formats de document, ils peuvent être définis, entre autres, par Microsoft Word ou les PDF d'Adobe. Les développeurs doivent relever le défi suivant : créer une interface utilisateur cohérente pour différents types de clients au moyen de technologies disparates, ce qui n'est pas simple.

L'un des principaux objectifs de Windows Presentation Foundation (WPF), dont le nom de code initial est « Avalon », est de résoudre ce problème. En offrant une base technique cohérente pour tous ces aspects de l'interface utilisateur, WPF simplifie la tâche des développeurs. Grâce à cette approche novatrice, notamment la prise en charge de la vidéo, de l'animation, des graphiques en deux et trois dimension et de différents types de documents, WPF permet aux utilisateurs d'exploiter les informations de façon inédite. De plus, en fournissant une base commune pour les ordinateurs de bureau et les navigateurs clients, WPF facilite la création d'applications destinées à ces deux types de systèmes.

L'exemple d'interface de la figure 4, qui contient des images, des graphiques en direct, des vues en trois dimensions, etc., illustre quelques-uns des avantages de WPF. Les interfaces utilisateur de ce type n'imposent plus d'avoir des développeurs compétents dans différentes technologies et leur création s'effectue de façon plus cohérente.

Figure 4

L'un des problèmes des créateurs d'interfaces utilisateur a longtemps été lié aux différents rôles requis pour que ces interfaces soient efficaces. Il faut des développeurs pour concevoir la logique sous-jacente de l'interface, mais ceux-ci sont rarement les personnes les plus compétentes pour en définir l'aspect. Les concepteurs, spécialistes de l'interaction homme/machine, conviennent généralement bien mieux à cette tâche. Pourtant, des technologies anciennes comme Windows Forms sont totalement centrées sur l'activité du développeur. Il n'existe pas de moyen réellement efficace pour que les développeurs et les concepteurs collaborent. Pour résoudre ce problème, WPF s'appuie sur XAML (eXtensible Application Markup Language). XAML est un langage de type XML qui permet de spécifier une interface utilisateur de façon déclarative plutôt que dans le code. Cela permet aux outils de générer et d'exploiter plus facilement une spécification d'interface utilisateur en fonction de la représentation visuelle créée par un concepteur. En fait, Microsoft propose un nouveau produit, Expression Interactive Designer, pour effectuer cette tâche. Les concepteurs peuvent utiliser cet outil (ainsi que d'autres fournis par des tiers) pour créer la présentation d'une interface, puis générer une définition XAML de cette interface. Le développeur importe cette définition dans Visual Studio, puis crée la logique requise.

Lorsque les développeurs créent une application WPF installée, qui s'exécute directement sous Windows, ils ont accès à tous les éléments fournis par WPF. Pour créer un client qui s'exécute dans un navigateur Web, cependant, les développeurs peuvent élaborer une application de navigateur XAML, appelée communément XBAP. Reposant sur le même principe qu'une application WPF installée, un XBAP permet de présenter le même type d'interface utilisateur dans une application de navigateur téléchargeable. Il est possible d'utiliser le même code pour les deux types d'applications. Autrement dit, les développeurs n'ont plus besoin de compétences différentes pour les ordinateurs de bureau clients et les navigateurs clients. Comme cela est courant avec ce type d'application Internet, un XBAP téléchargé depuis Internet s'exécute dans un sandbox sécurisé, ce qui limite les possibilités de l'application. Pourtant, il est possible d'utiliser dans un XBAP un vaste sous-ensemble des fonctionnalités de l'interface utilisateur accessibles à une application WPF installée.

Les applications WPF installées et les XBAP peuvent tirer parti de la prise en charge graphique de WPF, notamment la possibilité d'utiliser l'accélération matérielle, la prise en charge des graphiques vectoriels, etc. En permettant d'utiliser davantage de fonctions graphiques puissantes, WPF rend possibles des options de visualisation que ne permettent par Windows Forms ou d'autres technologies antérieures. WPF fournit également les bases de XPS (XML Paper Specification), qui définit un format standard pour la visualisation, la diffusion et l'impression de documents de format fixe.

Les interfaces utilisateur sont un élément important et complexe des applications évoluées. Via WPF, le .NET Framework 3.0 offre une solution plus complète et cohérente aux problèmes de ces interfaces. L'objectif est de permettre aux personnes qui créent des interfaces utilisateur (les développeurs et les concepteurs) de travailler plus efficacement.

Haut de page

Mise en œuvre du .NET Framework 3.0 : scénario

Pour comprendre comment un groupe de technologies fonctionnent ensemble, il convient d'étudier un exemple. Supposons qu'une application permette aux clients et agents de soumettre des demandes d'assurance. Si elle était implémentée au moyen du .NET Framework 3.0, cette application serait similaire à celle de la figure 5.

Figure 5

La logique métier de l'application, représentée dans la partie supérieure gauche du graphique, est implémentée au moyen d'un workflow WF. Gérer une application dans le domaine de l'assurance est un processus en plusieurs phases, qui comprend l'évaluation de l'application par rapport aux règles de souscription de l'entreprise, la vérification de la solvabilité du demandeur et parfois même l'obtention de l'approbation d'un responsable. Le workflow implémente chacune de ces étapes sous la forme d'une activité, pour laquelle il s'appuie sur un autre logiciel, si nécessaire. Pour accéder aux données stockées, par exemple, les activités de ce workflow utilisent ADO.NET.

Cette compagnie d'assurance fournit un centre d'appels qui permet à ses clients de demander un contrat d'assurance par téléphone. Le logiciel client utilisé par le personnel du centre d'appels, présenté dans l'angle supérieur droit du diagramme, est implémenté sous la forme d'une application WPF installée. Ce logiciel client communique avec la logique métier de l'application via WCF, à l'aide d'un protocole binaire optimisé pour la communication WCF-WCF. Comme le montre la figure, les employés du centre d'appels s'appuient sur Windows CardSpace pour sélectionner l'identité qu'ils utilisent pour se connecter à cette application.

Les clients, tout comme les courtiers en assurance, peuvent également transmettre leurs demandes d'assurance sur le Web. À cette fin, l'application utilise ASP.NET pour communiquer avec les navigateurs Web. Comme vous pouvez le voir dans l'angle supérieur gauche du diagramme, les clients qui utilisent Internet Explorer pour accéder à cette application via une interface HTML ordinaire peuvent faire appel à CardSpace pour sélectionner l'identité qu'ils souhaitent présenter. Pour permettre de déployer le métasystème d'identité sur des clients non-Windows et d'autres navigateurs, des éditeurs tiers peuvent aussi implémenter un mécanisme de sélection d'identité pour ces interfaces.

Les agents d'assurance qui accèdent à cette application sur Internet peuvent avoir besoin d'une interface plus fonctionnelle. Dans ce cas, ils pourront s'appuyer sur un XBAP au lieu d'une simple interface HTML. Comme le montre le diagramme (partie inférieure, au centre), ces clients disposent d'une grande partie des fonctionnalités de l'interface utilisateur fournie par l'application de bureau WPF utilisée dans le centre d'appels. Les deux clients sont bâtis sur la même base, de sorte que les développeurs de l'application peuvent réutiliser le même code pour l'un et l'autre. De plus, comme c'est le cas avec les autres types de clients, les agents peuvent utiliser CardSpace pour sélectionner l'identité qu'ils veulent présenter à l'application.

Enfin, il est probable que cette application aura besoin d'accéder à d'autres applications et devra être accessible à certaines d'entre elles. Si l'approbation d'un client nécessite un contrôle de solvabilité, par exemple, cela se fera très probablement via un appel à un service externe. Ou alors, l'application pourra accepter des requêtes provenant directement d'autres logiciels, et exposer des services susceptibles d'être appelés par ces logiciels. Pour les cas de ce type, présentés en bas et à droite de la figure, l'application s'appuie sur WCF pour communiquer à l'aide de services Web standard. Quelle que soit la technologie sur laquelle ces applications reposent, la prise en charge de SOAP par WCF simplifie les interactions avec elles.

Ce scénario montre comment il est possible d'utiliser dans une application type certains des composants les plus importants du .NET Framework 3.0. Bon nombre d'options ont été omises : ne considérez pas ce simple exemple comme une énumération complète des possibilités de cette famille de technologies. L'objectif est, au contraire, de vous montrer clairement comment utiliser conjointement les différentes parties du .NET Framework 3.0 pour répondre aux problèmes concrets des entreprises.

Haut de page

Comprendre le .NET Framework 3.0 : les technologies

Pour se rendre réellement compte des fonctionnalités du .NET Framework 3.0, il convient d'approfondir un peu chacune des technologies qui le composent. Cette section propose un court didacticiel sur chacune cinq parties du .NET Framework 3.0. Pour accéder à une description plus détaillée de chacune d'elles, consultez la liste Lectures complémentaires à la fin de cet article.

Le .NET Framework 2.0

Figure 6

Élément fondamental du développement sous Windows, le .NET Framework 2.0 constitue la base du .NET Framework 3.0. La figure 6 montre les deux parties du Framework : le CLR (Common Language Runtime) et la bibliothèque de classes .NET Framework. Certains composants du .NET Framework 3.0, y compris WF, WCF et WPF, sont implémentés en grande partie sous la forme d'extensions de la bibliothèque de classes .NET Framework. Toutefois, comme nous l'avons indiqué précédemment, si de nombreux éléments de la bibliothèque de classes gardent toute leur importance dans l'univers des développeurs, d'autres sont remplacés par les nouvelles technologies proposées par le .NET Framework 3.0. ASP.NET, par exemple, reste fondamental pour créer des applications accessibles aux navigateurs, et ADO.NET sert toujours à accéder aux données stockées. Les développeurs .NET Framework 3.0 peuvent faire appel à WPF au lieu de Windows Forms pour créer une interface graphique Windows native, et ils préféreront généralement opter pour WCF au lieu d'ASP.NET Web Services, .NET Remoting ou Enterprise Services. Malgré ces changements, il est important de comprendre que, même dans un univers .NET Framework 3.0, la version précédente du Framework reste au cœur des activités du développeur.

Windows Workflow Foundation

Une conception orientée processus, pilotée par un workflow, peut constituer la meilleure approche pour bon nombre de logiciels Windows. WF est destiné à permettre aux développeurs de créer et d'exécuter ces applications de type workflow. La figure 7 présente les composants fournis par WF à cet effet.

Figure 7

Comme nous l'avons vu précédemment, tout workflow repose sur un certain nombre d'activités. Les workflows et les activités sont simplement des classes, qui peuvent donc être créées directement dans le code. WF propose également Workflow Designer, un outil graphique hébergé par Visual Studio pour créer des workflows. Quelle que soit la méthode utilisée pour créer un workflow, ses activités peuvent être extraites de la bibliothèque BAL (Base Activity Library) de WF ou de toute autre source.

Une fois qu'un workflow a été défini, il est ensuite exécuté par le moteur runtime de WF. Celui-ci s'appuie sur un ensemble de services de runtime permettant de faire persister l'état du workflow, de suivre son exécution, etc. Un processus hôte contient tous ces éléments : les services runtime, le moteur runtime et le workflow lui-même. Il peut s'agir de n'importe quel processus Windows, de la simple console ou application WPF s'exécutant sur un poste de travail au processus serveur évolutif.

Pour comprendre WF, une connaissance minimale de ses composants est nécessaire. C'est pourquoi nous examinons chacun d'eux dans les sections suivantes.

Workflows

Ramené à l'essentiel, un workflow est tout simplement un groupe d'activités. WF offre une prise en charge intégrée pour deux types de workflows :

• Les workflows séquentiels, qui exécutent les activités dans un ordre défini. Semblable à un organigramme classique, un workflow séquentiel peut comporter des branchements, des boucles et d'autres structures de contrôle. Par défaut, cependant, les activités s'exécutent en séquence, l'une après l'autre.

• Les workflows à machine à états, qui implémentent une machine à états finis classique. Comme dans toute machine à états, l'activité qui s'exécute à un moment donné est déterminée en combinant l'état actuel et l'événement reçu, quel qu'il soit.

L'option séquentielle est utile pour les workflows bien définis, tels que ceux utilisés dans les processus uniquement à base de logiciel. Ils sont relativement simples à créer et à comprendre, et semblent initialement plus naturels à la plupart des développeurs. Les workflows à machine à état constituent un meilleur choix lorsque le chemin d'exécution est moins prévisible. Un workflow impliquant des interactions avec des personnes, susceptibles d'annuler le processus à tout moment, constitue un bon exemple d'utilisation de ce cas de figure. Il serait possible de traiter une telle situation avec un workflow séquentiel, mais alors, chaque étape pourrait constituer un branchement : exécuter telle action si le workflow n'est pas annulé, telle autre s'il est annulé. La modélisation de ce type de comportement avec une machine à état est beaucoup plus simple, puisqu'une demande d'annulation du workflow constitue un simple événement supplémentaire, qui peut être reçu et traité à un stade quelconque.

La gestion des workflows avec machines bien que WF tente de prendre en charge aussi bien les workflows humains que les workflows système. Le fait qu'il puisse prendre en charge un changement dans un workflow va dans le même sens. Les gens sont parfois capricieux, et il n'est pas rare de voir une personne impliquée dans un workflow vouloir ajouter ou supprimer étape, ou bien modifier le processus en cours d'exécution. Pour permettre au développeur de répondre à ce type de besoin de manière contrôlée, WF lui donne la possibilité, lors de la création du workflow, de préciser si celui-ci peut être modifié en cours exécution, et de quelle manière il peut l'être.

La bibliothèque d'activités de base

Les développeurs ont toute liberté pour créer des activités personnalisées. En fait, Microsoft chercher à favoriser le développement d'un écosystème WF réunissant une multitude d'activités réutilisables. Cependant, il est plus simple pour tout le monde de pouvoir démarrer avec un jeu commun d'activités de base. C'est là le rôle de la bibliothèque BAL (Base Activity Library).

Rien n'impose d'utiliser un élément quelconque de la BAL dans un workflow, mais nombre de développeurs constateront qu'elle leur simplifie la tâche, surtout dans un premier temps. Voici quelques-unes des activités contenues dans la BAL :

• IfElse : exécute les activités de deux chemins ou plus, selon qu'une condition est satisfaite ou non.

• While : répète l'exécution d'une ou plusieurs activités, aussi longtemps qu'une condition est vraie.

• Sequence : exécute un groupe d'activités l'une après l'autre dans un ordre défini.

• Parallel : exécute deux ou plusieurs groupes d'activités en parallèle.

• Code : exécute un bloc de code défini.

• Listen : attend un événement donné, puis exécute une ou plusieurs activités à la réception de cet événement.

• InvokeWebService : appelle un service Web.

• State : représente un état dans la machine à état d'un workflow.

• EventDriven : définit une transition contenant une ou plusieurs activités qui doivent être exécutées lorsque, dans un état particulier, un événement donné est reçu.

• Policy : permet la définition et l'exécution de règles métier à l'aide d'un moteur de règles fourni par WF.

Dans WF, plutôt que de définir un langage particulier pour définir des workflows, une approche plus générale consistant à utiliser des activités a été adoptée. La bibliothèque BAL fournit un « langage », mais tout utilisateur de WF peut aussi librement définir le sien.

Outils pour Windows Workflow Foundation : Workflow Designer

La création d'applications à l'aide de workflows présente, entre autres, l'avantage de permettre de définir graphiquement les workflows. C'est là l'objet de l'outil Workflow Designer, présenté en figure 8. Par défaut, les activités de la bibliothèque BAL apparaissent dans la boîte à outils ; le développeur peut les faire glisser vers la surface de conception pour créer un workflow.

Figure 8

Certains développeurs n'aiment pas les concepteurs graphiques et préfèrent écrire du code. WF permet également d'adopter cette approche (et l'impose parfois : les activités sont généralement créées directement en code). Les deux méthodes peuvent aussi être combinées pour créer un workflow avec Workflow Designer et par codage direct. L'objectif est de permettre aux développeurs d'utiliser la solution qui leur semble la plus productive. Par ailleurs, pour permettre une plus grande ouverture en termes d'outils pris en charge, les workflows peuvent aussi être exprimés en XAML, le langage qu'utilise WFP. De fait, les workflows créés à l'aide de Workflow Designer sont définis en XAML par défaut.

Moteur et services runtime

Comme indiqué précédemment, le rôle d'exécution des activités d'un workflow revient au moteur runtime de WF. Pour ce faire, celui-ci s'appuie notamment sur un groupe de services runtime. WF intègre en standard des implémentations de ces services, mais les développeurs ambitieux peuvent les remplacer s'ils le souhaitent. Ces services prennent en charge différentes opérations, dont deux présentent un intérêt tout particulier :

• Persistance : un workflow bloqué dans l'attente d'un événement peut utiliser ce service pour demander que son état en mémoire soit automatiquement enregistré sur disque. Lorsque l'événement survient, le service recharge automatiquement l'état du workflow et reprend son exécution. Cette solution est particulièrement utile pour les workflows impliquant des personnes, puisque dans ce cas, l'attente d'une réponse peut durer quelques heures ou quelques jours, voire plus.

• Suivi : les activités d'un workflow ponctuent clairement l'exécution du processus qu'elles implémentent. Grâce au service de suivi de WF, un développeur peut imposer l'enregistrement automatique des informations relatives au workflow dans une base de données. Il peut ainsi consigner le début et la fin d'un workflow et de chacune de ses activités, ainsi que d'autres informations.

Windows Workflow Foundation et les autres technologies Microsoft

La mise en œuvre de nouvelles approches a un impact inévitable sur l'existant. Les nouvelles technologies du .NET Framework 3.0 ne font pas exception à la règle : chacune d'entre elles a des conséquences sur les autres technologies Microsoft. Avec WF, l'impact initial se ressent le plus dans Windows SharePoint Services, Microsoft Office 2007 System et BizTalk Server

Pour permettre aux développeurs de créer plus facilement des applications de workflow pour la collaboration par documents et les autres modes de partage de l'information, Windows SharePoint Services version 3 héberge le runtime WF. Office SharePoint Server 2007, qui fait partie de Microsoft Office 2007 System, s'appuie sur la prise en charge de WF dans Windows SharePoint Services. L'ajout de ce serveur permet, entre autres, d'afficher directement les formulaires InfoPath dans les clients Office 2007 et d'utiliser un jeu de workflows prédéfinis pour les scénarios courants tels que l'approbation d'un document.

Toute personne familiarisée avec BizTalk Server aura à présent certainement remarqué la similitude entre les capacités d'orchestration de ce produit et les fonctionnalités fournies par WF. En fait, dans la version qui suivra BizTalk Server 2006, la fonction d'orchestration actuelle du produit sera remplacée par WF et des outils seront proposés pour faire migrer les orchestrations actuelles vers des workflows WF. Il est cependant capital de comprendre que WF et BizTalk Server 2006 répondent à des problèmes bien distincts :

• WF offre un cadre général pour la création d'applications Windows s'appuyant sur les workflows. Il peut être hébergé dans n'importe quel processus, utiliser tout type d'activité et répondre à un problème professionnel quelconque, y compris ceux impliquant des workflows humains ou système.

• BizTalk Server est un produit sous licence axé sur l'intégration d'applications d'entreprise, l'intégration inter-entreprises et la gestion de processus d'entreprise. Il propose tout un éventail d'adaptateurs pour la connexion à différents systèmes et logiciels, des accélérateurs pour la mise en œuvre de normes telles que RosettaNet et SWIFT, ainsi que la prise en charge d'une surveillance de l'activité de l'entreprise. BizTalk Server intègre également une infrastructure et des outils de gestion, ainsi que les capacités requises pour une évolutivité accrue.

Sachant que WF constitue la technologie de workflow standard de Windows, il pourrait bien à l'avenir apparaître dans d'autres produits et technologies Microsoft. Quel que soit le choix de Microsoft en la matière, WF sera certainement adopté dans un certain nombre d'applications créées par ses clients.

Windows Communication Foundation

Le changement opéré vers la communication orientée service marque une évolution importante du mode d'interaction des applications. Explicitement conçu pour les applications orientées service, WCF reflète ce changement. Cette section décrit les aspects importants de WCF, y compris les services et clients, les options de communication et la prise en charge de la sécurité, de communications fiables et des transactions.

Services et clients

Figure 9

Comme le montre la figure 9, le principe de WCF est simple : un service expose une interface accessible à un client. Il est possible de définir cette interface au moyen de WSDL (Web Services Description Language), puis de la convertir en code, ou de la définir directement dans un langage comme C# ou Visual Basic. Pour une interface simple exposant le service d'une application d'assurance, la dernière approche est similaire à ce qui suit :

[ServiceContract]
interface IInsuranceApplication
{
 [OperationContract]
 int Submit(int policyType, string ApplicantName);

 [OperationContract]
 bool CheckStatus(int applicationNumber);

 [OperationContract]
 bool Cancel(int applicationNumber);
}

La définition de l'interface C# est identifiée par l'attribut

ServiceContract

OperationContract

OperationContract

OperationContract

La figure 10 fournit une vue plus détaillée du mode d'exposition d'un service à ses clients. Au lieu d'accéder directement à une interface, un client se connecte à un point d'extrémité spécifique. Un service peut exposer plusieurs points d'extrémité, ce qui permet éventuellement à différents clients d'y accéder de manière spécifique.

Figure 10

Comme le montre la figure, chaque point d'extrémité précise trois éléments :

• Un contrat décrivant les opérations appelables au moyen de ce point d'extrémité. Il est possible d'identifier ce contrat au moyen du nom de l'interface qui définit ces opérations, en l'occurrence IInsuranceApplication.

• Une liaison qui indique comment appeler les opérations du point d'extrémité. Chaque liaison définit plusieurs éléments, notamment le protocole à utiliser pour appeler les opérations, le type de sécurité requis, etc. WCF inclut un ensemble de liaisons prédéfinies, telles que BasicHttpBinding représenté ici, pour les cas les plus courants. De plus, il est possible de définir des liaisons personnalisées. Comme un service peut exposer plusieurs points d'extrémité, il lui est possible d'accéder simultanément à différents types de clients sur différents protocoles au moyen de plusieurs options de sécurité.

• Une adresse indiquant l'emplacement de ce point d'extrémité. Comme le montre la figure, l'adresse est représentée par une URL.

Le principe de WCF est simple. Comme dans le cas de la plupart des technologies de communication, les détails peuvent être complexes (le nombre d'options est important), mais la création d'applications WCF standard ne présente pas de difficultés.

Options de communication

Les applications créées par les développeurs requièrent des modes de communication différents. L'approche la plus simple pour la plupart des développeurs est RPC (Remote Procedure Call), qui permet à un client d'appeler des opérations distantes comme s'il s'agissait de procédures locales. Compte tenu de l'interface représentée plus haut, un client peut, par exemple, appeler une opération de façon asynchrone (méthode habituelle) et attendre patiemment une réponse. Simple pour les développeurs, cette option représente le choix approprié dans certains cas.

WCF propose cependant plusieurs autres options. Il s'agit notamment des suivantes :

• Les appels sans réponse. Identifié par l'attribut

  OneWay

  , ce type de communication peut être utile pour envoyer des événements ou des interactions unidirectionnelles.

• Communication asynchrone fondée sur des messages, par envoi et réception directe de messages XML.

• Manipulation explicite de messages SOAP, y compris la possibilité d'insérer des éléments dans l'en-tête SOAP.

WCF permet également aux développeurs de contrôler divers aspects du comportement d'un service. Au moyen de l'attribut

ServiceBehavior

Sécurité, fiabilité et transactions

La communication de base (la possibilité de transférer des données entre des systèmes) est utile, mais elle est rarement suffisante. La plupart des applications requièrent davantage de fonctionnalités. Par exemple, la majorité des applications distribuées exigent une fonction de sécurité. Assurer la sécurité est un processus complexe, étant donné le nombre d'approches différentes et de technologies actuellement utilisées. Pour permettre aux développeurs de créer des applications distribuées sécurisées sans être tenus d'en connaître tous les détails, WCF s'appuie principalement sur les liaisons en matière de sécurité. Par exemple, il est possible de configurer BasicHttpBinding, mentionné précédemment, pour qu'il utilise HTTPS plutôt que HTTP standard. De plus, d'autres liaisons offrent davantage d'options de sécurité. Ainsi, WsHttpBinding prend en charge WS-Security, ce qui permet l'authentification interopérable fondée sur SOAP, l'intégrité et la confidentialité des données. Les développeurs peuvent également créer une liaison personnalisée qui fournit les services de sécurité correspondant exactement aux besoins leur application.

Pour de nombreuses applications, il est également essentiel de s'assurer de la fiabilité des communications. L'approche traditionnelle des services Web, à savoir l'envoi de SOAP sur HTTP, suffit dans certains cas. C'est le cas lorsque BasicHttpBinding est utilisé. Il existe cependant de nombreux cas dans lesquels cette solution répandue s'avère insuffisante. Pour les messages passant par un ou plusieurs intermédiaires SOAP, par exemple, cette approche simple ne peut pas garantir une fiabilité totale. Dans ce cas, WCF implémente WS-ReliableMessaging. En choisissant une méthode qui prend en charge cette option, par exemple WsHttpBinding, un développeur peut automatiquement obtenir un transfert de messages interopérable fiable.

Les transactions distribuées peuvent également être importantes dans certaines applications. WCF tire parti de System.Transactions, qui fait partie du .NET Framework 2.0, pour permettre la création de logiciels transactionnels. Une méthode peut utiliser l'attribut

OperationBehavior

Windows Communication Foundation et autres technologies Microsoft

Comme indiqué plus haut, WCF remplace plusieurs technologies Microsoft antérieures pour la création d'applications distribuées. La plupart des applications qui auraient été conçues à l'aide d'ASP.NET Web Services, .NET Remoting, Enterprise Services, System.Messaging ou WSE reposeront sur WCF. Les applications WCF peuvent interopérer avec les applications ASP.NET Web Services, les deux types prennent en charge SOAP, et les applications fondées sur Enterprise Services, MSMQ et la version 3.0 de WSE. WCF peut aussi être utilisé par BizTalk Server 2006 et une future version de BizTalk Server exploitera plus directement les possibilités de WCF.

Il est important de comprendre que même si les nouvelles applications .NET Framework 3.0 n'utiliseront pas couramment les technologies que WCF remplace, celles-ci font toujours partie du Framework et, à ce titre, seront prises en charge. Les applications conçues au moyen de versions antérieures de ces technologies continueront également à s'exécuter normalement ; l'installation du .NET Framework 3.0 ne remettra pas en cause le code existant.

Windows CardSpace

Qu'ils accèdent à des applications via un navigateur Web ou un autre type de client, les utilisateurs passent quotidiennement par un réseau pour cela. Comme ces applications exigent normalement qu'ils s'identifient d'une façon ou d'une autre, les utilisateurs doivent inévitablement acquérir et présenter des informations d'identification aux logiciels distants. L'accès à des applications Internet via un navigateur fournit un exemple courant de cette situation, à laquelle doivent également faire face les utilisateurs des intranets.

Comme indiqué plus haut, les utilisateurs s'appuient actuellement le plus souvent sur des noms d'utilisateur et des mots de passe pour les identités numériques, ce qui n'est pas sans entraîner des problèmes. Windows CardSpace, qui fait partie d'un métasystème d'identité plus vaste, offre une autre approche pour résoudre ces problèmes. Pour mieux comprendre cette approche, commençons par aborder les concepts de base du métasystème d'identité.

Windows CardSpace et le métasystème d'identité

Lorsque les utilisateurs accèdent à une application, notamment à partir d'un navigateur Web ou d'un client propre à une application, ils présentent généralement une identité numérique. Il existe différents types d'identités numériques mais, dans la majorité des cas, elles sont représentées sur le réseau par un jeton de sécurité. Un jeton de sécurité simple peut être un nom d'utilisateur alors qu'un jeton plus complexe peut comprendre un certificat X.509 ou un document XML. Quelle soit que leur forme, les jetons de sécurité sont un mécanisme type pour représenter les identités numériques sur le réseau.

Penser que nous adopterons tous un jour un format commun de jeton de sécurité peut sembler naturel. En réalité, nous continuerons d'utiliser différentes méthodes. Tout comme nous avons plusieurs documents d'identité dans notre portefeuille (permis de conduire, carte de crédit, carte de voyageur fréquent, etc.), nous disposerons toujours de plusieurs identités numériques représentées par différents types de jetons de sécurité. Aucun système d'identité ne peut fournir une réponse universelle. Nous aurons donc toujours besoin de plusieurs jetons de sécurité.

Les utilisateurs doivent toutefois exploiter de façon cohérente leurs différentes identités numériques. Bien qu'un seul système d'identité soit insuffisant, il est possible de créer un système de systèmes d'identité, un métasystème d'identité, qui permette d'utiliser de nombreuses identités numériques de manière homogène. En collaboration avec d'autres sociétés, Microsoft a dirigé le processus de définition de ce métasystème. Reposant sur les technologies de services Web ouvertes comme WS-Security et WS-Trust, ce métasystème définit le mode d'acquisition et d'utilisation des identités numériques, quel que soit le type de jeton de sécurité dont elles dépendent.

Le processus d'émission, d'acquisition et d'utilisation des identités numériques requiert trois rôles distincts, à savoir :

• Utilisateur : parfois appelé sujet, l'utilisateur est l'entité qui possède une identité numérique.

• Fournisseur d'identité : il fournit une identité numérique à un utilisateur. Pour l'identité numérique qui vous est affectée par votre employeur, par exemple, le fournisseur d'identité est généralement un système comme Active Directory. Pour l'identité numérique que vous utilisez avec Amazon, vous êtes le fournisseur d'identité puisque vous définissez vos propres nom d'utilisateur et mots de passe. Les identités numériques créées par différents fournisseurs d'identité peuvent comporter des informations variables et garantir de manière spécifique que l'utilisateur est bien la personne qu'il prétend être.

• Partie utilisatrice : il s'agit d'une application qui se fie d'une façon ou d'une autre à une identité numérique. Une partie utilisatrice emploiera fréquemment une identité (à savoir les informations contenues dans le jeton de sécurité de celle-ci) pour authentifier un utilisateur, puis pour prendre une décision en matière d'autorisation, par exemple permettre à cet utilisateur d'accéder à certaines informations. Une partie utilisatrice peut aussi employer l'identité pour obtenir un numéro de carte de crédit, vérifier que l'utilisateur y accède à différentes heures ou à d'autres fins. Des exemples types de parties utilisatrices comprennent les sites Web comme les banques, les marchands en ligne, les sites d'enchères et toutes les applications qui acceptent des demandes via des services Web.

Ces trois types d'identités interagissent avec le métasystème d'identité. La figure 11 illustre ces interactions et indique où CardSpace intervient.

Figure 11

Le processus commence lorsqu'un utilisateur accède à une partie utilisatrice via une application compatible CardSpace. Pour savoir quel type de jeton de sécurité cette partie utilisatrice va demander, l'application doit se fier à la stratégie de cette dernière (étape 1). Pour un navigateur accédant à un site Web, ce qui est le cas le plus courant, la stratégie du site est exprimée en HTML et renvoyée dans une page Web. Les applications accessibles via des services Web, quant à elles, doivent utiliser le protocole standard défini par WS-MetadataExchange pour demander à la partie utilisatrice sa stratégie. Dans ce cas, la stratégie est exprimée au moyen de WS-SecurityPolicy, une autre norme de l'industrie. Quelle que soit la manière dont les informations de stratégie sont acquises, elles indiquent toujours le type de jeton de sécurité que cette partie utilisatrice acceptera et quelles informations ce jeton doit contenir.

Une fois que CardSpace sait quel type de jeton de sécurité est nécessaire à la partie utilisatrice, il affiche l'écran d'identité représenté plus haut. Chaque identité numérique disponible pour cet utilisateur est représentée sous forme de carte d'information sur cet écran. Les cartes émises par une partie utilisatrice externe sont appelées cartes gérées alors que celles émises par le fournisseur auto-émis de CardSpace sont des cartes auto-émises. Les deux types de cartes peuvent être affichés sur cet écran et l'utilisateur a la possibilité de sélectionner l'un ou l'autre. Pour faciliter cette décision, l'écran indique quelles identités répondent aux exigences de la partie utilisatrice en affichant en grisé les cartes non conformes. L'utilisateur sélectionne ensuite l'une d'entre elles comme identité numérique à employer (étape 2).

Une carte ne contient toutefois aucun jeton de sécurité réel. Elle renferme les informations nécessaires pour localiser un fournisseur d'identité particulier et demander un jeton de sécurité pour cet utilisateur. (En fait, chaque carte est initialement créée par un fournisseur d'identité.) CardSpace utilise le contenu de la carte sélectionnée par l'utilisateur pour demander un jeton de sécurité au fournisseur d'identité qui a émis la carte (étape 3). Cette demande s'appuie sur WS-Trust, un autre protocole standard, et les utilisateurs s'authentifient auprès du fournisseur d'identité au moyen de Kerberos, d'un certificat X.509 et d'une signature numérique, ou via un autre mécanisme. Le jeton est renvoyé sous une forme cryptée qui contient également un horodatage pour empêcher qu'il ne soit détourné sur le réseau et réutilisé ultérieurement.

Une fois le jeton de sécurité demandé renvoyé, il est transmis à la partie utilisatrice (étape 4). Le mode d'utilisation des informations contenues dans ce jeton est variable. Si le jeton contient un certificat X.509, par exemple, et qu'il est accompagné d'une signature numérique, la partie utilisatrice s'en servira probablement pour authentifier l'utilisateur. Il n'est cependant pas exigé que les jetons soient utilisés pour l'authentification ou à d'autres fins de sécurité. (En fait, l'expression « jeton de sécurité » est impropre.) Un jeton peut contenir des informations comme la preuve de l'âge d'un utilisateur, de son droit à une remise sur un site d'achat Internet, etc. L'authentification est l'un des principaux emplois des jetons de sécurité, mais pas le seul.

Il est important de noter que ni CardSpace ni le métasystème d'identité dans son ensemble ne connaît la technologie ou le format employé pour le jeton. L'objectif n'est pas de créer une nouvelle source unique pour les identités numériques ou un format standard pour les jetons de sécurité. Il s'agit plutôt de fournir une méthode cohérente pour utiliser toutes les identités numériques reposant sur un type quelconque de jeton de sécurité. En proposant une implémentation Windows des éléments clés de ce métasystème, CardSpace contribue notablement à faire de cette approche générale de l'identité numérique une réalité.

Mesures anti-phishing

Les fournisseurs d'identité sont souvent distincts de l'utilisateur, comme c'est le cas par exemple lorsqu'une identité est affectée par un employeur. Il existe pourtant de nombreuses situations dans lesquelles le fournisseur d'identité est en fait l'utilisateur. Si CardSpace n'est pas utilisé, par exemple, l'accès à de nombreux sites Web requiert un nom d'utilisateur et un mot de passe, lesquels sont définis par les utilisateurs. Une fois que ceux-ci ont créé cette identité, ils peuvent fournir ultérieurement leur nom d'utilisateur et leur mot de passe, puis vérifier leur solde bancaire, acheter un livre ou effectuer toute autre opération autorisée sur le site en question.

Comme ils dépendent des mots de passe, ces types d'identités émis automatiquement sont des cibles pour les attaquants, comme indiqué précédemment. Pour réduire les attaques, CardSpace offre un autre moyen de créer une identité auto-émise. Le fournisseur de l'identité auto-émise s'exécute localement sur le système Windows de l'utilisateur. Plutôt que de reposer sur un nom d'utilisateur et un mot de passe, les jetons de sécurité créés par le fournisseur d'identité auto-émise sont définis au moyen de SAML (Security Assertion Markup Language), une norme élaborée par OASIS. Ces jetons s'appuient sur une technologie de clé publique et non sur des mots de passe pour prouver l'identité de l'utilisateur et, si une partie utilisatrice les accepte, ils peuvent jouer le même rôle que le nom d'utilisateur et le mot de passe traditionnels. L'avantage est qu'il n'existe plus de mot de passe susceptible d'être détourné par les usurpateurs. La limitation de l'utilisation des mots de passe ainsi que la preuve renforcée de l'identité d'un site fournie par les certificats haute assurance peuvent réduire la gravité du problème de l'usurpation d'identité.

Windows CardSpace et autres technologies Microsoft

CardSpace est lié à plusieurs autres technologies Microsoft, notamment les suivantes :

• WCF : comme il s'appuie sur des normes de services Web comme WS-Security et WS-Trust, CardSpace utilise WCF pour la communication. En fait, le créateur d'une application WCF peut faire en sorte que celle-ci utilise CardSpace en spécifiant simplement une liaison particulière.

• Active Directory : bien que cela ne soit pas possible actuellement, Active Directory sera ultérieurement en mesure d'agir en tant que fournisseur d'identité dans le métasystème.

• Windows Live ID (anciennement Passport) : comme pour Active Directory, Microsoft a annoncé que son système d'authentification Live ID sera également modifié pour faire office de fournisseur d'identité. Notez que CardSpace ne remplace pas Live ID, car les deux systèmes traitent des problèmes très différents. Ainsi, Live ID fera partie intégrante du métasystème d'identité comme n'importe quel autre fournisseur d'identité.

Microsoft fournit également des technologies liées à l'identité qui résolvent des problèmes assez différents de ceux de CardSpace. Active Directory Federation Services (ADFS), par exemple, a pour objet de fédérer les identités entre les entreprises. Il s'agit d'un problème important, auquel sont confrontées de nombreuses entreprises appelées à collaborer avec d'autres entités. Il est très différent des questions plus vastes auxquelles répondent CardSpace et le métasystème d'identité.

Windows Presentation Foundation

La logique fondée sur le workflow, la communication orientée service et l'identité sont des aspects importants des applications évoluées. Pourtant les utilisateurs prêtent plus d'attention à ce qui leur est visible, à savoir l'interface utilisateur. L'objectif de WPF est de relever les défis liés à la création d'interfaces utilisateur pour les applications actuelles. Comme nous allons le voir, WPF fournit des fonctionnalités conçues dans cette optique.

Les fonctionnalités de Windows Presentation Foundation

Un développeur est libre de créer une interface d'application WPF entièrement en C#, Visual Basic ou un autre langage fondé sur CLR. Comme indiqué plus haut, WPF permet toutefois de spécifier une interface au moyen du langage XAML, basé sur XML. Les éléments et attributs en XAML sont directement mappés sur les classes et propriétés fournies par WPF. Voici un exemple de bouton simple défini en XAML :

<Button Background="Red">
 No
</Button>

Cet exemple crée un bouton rouge contenant le texte « No ». Il serait possible d'obtenir le même résultat à l'aide du code suivant :

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

Quel que soit leur mode de définition, la quasi-totalité des applications WPF suivent le même modèle de base. L'application hérite de l'objet Application standard de WPF, qui fournit les méthodes, événements et propriétés de base. Une application WPF peut avoir une interface traditionnelle reposant sur des boîtes de dialogue ou une interface de navigation qui lui permet de fonctionner de façon très similaire à une application de navigateur. Celle-ci est généralement implémentée comme un groupe de pages dont chacune se compose d'une interface utilisateur définie en XAML et d'une logique définie en code. Pour lier ces pages, XAML fournit un élément de lien hypertexte, similaire à ceux du HTML. L'application affiche une page à la fois, permet à l'utilisateur de se déplacer dans les pages, tient à jour un historique, etc. Bien qu'une application de navigation puisse s'exécuter sous forme de XBAP dans un navigateur Web, cela n'est pas obligatoire : un développeur peut également utiliser ce type d'interface dans des applications WPF installées. L'objectif est de créer un logiciel qui réunit les meilleurs aspects d'une interface de navigateur et d'une interface Windows native.

Quel que soit le type d'interface qu'elle utilise, une application WPF peut reposer sur des panneaux pour la présentation de base. Chaque panneau contient généralement des contrôles. Ceux fournis par WPF comprennent Button, TextBox, ComboBox, Menu et bien d'autres encore. Le positionnement de ces contrôles dépend du type de panneau choisi. Par exemple, il est possible de les placer sur une grille spécifique. Le développeur peut également les disposer dans les limites d'une zone de dessin. Comme cela est généralement le cas dans une interface graphique, les événements générés par l'utilisateur sont détectés et gérés par les différents contrôles et autres classes de l'application. Il est également possible d'appliquer des styles et des modèles à des groupes de contrôles, ce qui permet de doter l'application d'une présentation homogène.

WPF prend en charge bien plus que ces fonctions d'interface utilisateur de base, notamment :

• Documents : une application WPF peut afficher des documents XPS au moyen de la balise XAML FixedDocument. Elle peut également afficher des documents en flux à l'aide de la balise FlowDocument. Un document en flux peut se comporter comme un document d'écran classique, dont l'utilisateur peut faire défiler le contenu. En définissant différents attributs de cette balise, un développeur a la possibilité de mieux adapter le document à son environnement. Un document peut, par exemple, afficher une page à la fois, ce qui évite à l'utilisateur de le faire défiler vers l'avant et l'arrière. WPF peut aussi déterminer automatiquement sur combien de colonnes répartir un document en fonction de la taille de la fenêtre dans laquelle il s'affiche. L'objectif est de permettre une lisibilité optimale des documents à l'écran.

• Graphiques : WPF permet de créer des graphiques vectoriels en deux et trois dimensions. Pour les graphiques 2D, WPF fournit des abstractions standard telles que des formes, des pinceaux et des stylos, tandis que les graphiques 3D permettent de définir un modèle auquel il est possible d'affecter des informations sur l'éclairage et la position de la caméra. Contrairement aux technologies antérieures comme Windows Forms, qui repose sur GDI+ pour les graphiques, les graphiques WPF ne sont pas structurés d'après un ensemble distinct de concepts que les développeurs doivent comprendre. Les éléments XAML utilisés pour les graphiques peuvent être combinés tout à fait naturellement avec ceux employés pour les autres éléments de l'interface utilisateur. Les boutons peuvent avoir un contenu graphique, les textes et les graphiques peuvent être combinés, etc.

• Images : à l'aide de la balise Image de XAML, une application WPF peut afficher des images dans différents formats, notamment JPEG, GIF, etc. WPF s'appuie sur Windows Imaging Component (WIC) pour fournir une structure standard pour les codecs (logiciels qui affichent et stockent des images). Comme c'est généralement le cas dans WPF, un élément Image peut être associé à d'autres et permettre, par exemple, de créer un bouton qui affiche une image plutôt qu'une simple étiquette de texte.

• Multimédia : une application WPF peut utiliser la balise MediaElement pour afficher de la vidéo et de l'audio dans différents formats, par exemple WMV, AVI et MPEG. Dans ce cas également, il est possible de combiner cet élément à d'autres éléments XAML pour obtenir notamment un cube 3D qui affiche de la vidéo sur ses côtés.

• Animation : WPF intègre la prise en charge de l'animation pour la plupart des éléments d'une interface utilisateur. Ainsi, un cercle peut s'agrandir ou diminuer ou un bouton peut changer progressivement de taille. Les applications peuvent également définir des tables de montage séquentiel avec chronométrage, ce qui permet de coordonner des séquences d'animation.

• Liaison de données : comme de nombreuses applications WPF affichent des données, il est utile de disposer d'une prise en charge automatique du mappage des données sur les éléments de l'interface utilisateur. WPF fournit ce type de liaison pour les informations contenues dans les objets et d'autres sources. La liaison de données de WPF permet également de trier et de filtrer les informations avant leur affichage.

Application de Windows Presentation Foundation

WPF fournit un vaste ensemble de fonctionnalités d'interface utilisateur qui permettent aux développeurs et concepteurs de créer des interfaces réellement attrayantes. Pourtant, malgré l'aspect séduisant de l'application cliente, certaines entreprises sont réticentes à utiliser WPF en raison des problèmes de déploiement. Si le déploiement d'une nouvelle version de l'application cliente implique d'intervenir physiquement sur chaque ordinateur client sur lequel cette application est installée, le coût de la mise à niveau peut être conséquent. Un moyen courant d'éviter ce problème actuellement consiste à créer des clients sur navigateur plutôt que des clients Windows natifs. Les clients Windows natifs ont généralement de meilleures interfaces que les navigateurs, qui sont en outre plus réactives. Pour résoudre le problème de déploiement des clients, il est possible de mettre en place les applications WPF installées au moyen de ClickOnce. Technologie proposée initialement dans le .NET Framework 2.0, ClickOnce permet aux utilisateurs d'Internet Explorer de sélectionner une application sur le Web, puis de l'installer automatiquement sur leur ordinateur local. Une fois installée, l'application peut être mise à jour automatiquement dès qu'une nouvelle version est disponible. L'objectif est le déploiement simple et économique d'un client Web avec la puissance et la fonctionnalité d'une application WPF installée.

Lorsqu'elles sont déployées au moyen de ClickOnce, les applications WPF installées sont un choix de client tout indiqué dans de nombreux cas. Il peut cependant arriver que ce type d'application ne convienne pas, même lorsque les utilisateurs peuvent tirer parti de l'interface qu'autorise WPF. Pensez, par exemple, aux agents d'assurance du scénario décrit précédemment ou au site marchand Internet qui souhaite proposer des graphiques 3D, de la vidéo et les fonctionnalités avancées prises en charge par WPF. Il ne faut généralement pas s'attendre à ce que les utilisateurs de cette application installent une application WPF native pour accéder au site. Une meilleure solution consisterait à proposer aux utilisateurs une interface de type WPF dans leur navigateur Web.

Les applications de navigateur XAML, les XBAP, sont conçues à cet effet. Plutôt que déployer une application WPF installée, l'utilisateur d'Internet Explorer peut télécharger un XBAP directement dans son navigateur. L'application s'exécute dans Internet Explorer et peut donc présenter à l'utilisateur l'interface WPF. Toutefois, le téléchargement et l'exécution de code provenant de sites Web peuvent être dangereux. Pour protéger les utilisateurs contre les développeurs malveillants, tous les XBAP téléchargés depuis Internet s'exécutent dans un sandbox partiellement fiable. Reposant sur la sécurité d'accès du code fournie par le .NET Framework, ce sandbox limite les possibilités des XBAP. Ainsi, un XBAP téléchargé depuis Internet ne peut pas créer de fenêtres autonomes ni lancer de nouvelles fenêtres, afficher une boîte de dialogue Enregistrer lancée par le XBAP ou accéder au système de fichiers, sauf dans une zone de stockage isolée. Malgré les restrictions imposées par le sandbox, un XBAP peut tout de même utiliser une grande partie des fonctionnalités de WPF, notamment les graphiques 2D et 3D, les animations, les documents à l'écran, les images et la vidéo.

Comme indiqué plus haut, WPF permet aux applications d'afficher des documents adaptatifs au moyen de l'élément FlowDocument de XAML. Les documents dont l'aspect change en fonction de leur mode d'affichage ne sont toutefois pas toujours la meilleure solution. Les documents à format fixe, dont l'aspect reste inchangé à l'écran et à l'impression, conviennent parfois mieux. Dans ce cas, il existe les documents XPS de WPF. Définis à l'aide d'un sous-ensemble de XAML, les documents XPS peuvent être lus sur tout système qui propose un lecteur XPS. Ils fournissent également un nouveau format d'impression pour Windows, ce qui permet d'imprimer plus fidèlement des graphiques complexes. De plus, pour rendre plus cohérente l'utilisation de différents types de documents, les documents XPS et Office 2007 s'appuient sur les conventions Open Packaging de Microsoft qui définissent des moyens courants de stocker le contenu de documents, de signer numériquement des documents, etc.

Outils pour Windows Presentation Foundation

Il est possible de créer une interface utilisateur WPF directement dans le code et/ou au moyen d'un éditeur de texte standard. Comme il est généralement préférable de travailler avec de bons outils, Microsoft fournit des extensions pour Visual Studio 2005 qui permettent aux développeurs de créer des applications WPF. La prochaine version de Visual Studio (nom de code « Orcas ») fournira davantage de fonctionnalités avec Visual Designer pour Windows Presentation Foundation. Cet outil permettra aux développeurs de créer sous forme graphique l'interface utilisateur à visualiser. L'outil générera ensuite le code de cette interface.

Les développeurs ne sont pourtant pas toujours les mieux placés pour définir des interfaces utilisateur. Les concepteurs conviennent mieux généralement car la communication avec les utilisateurs fait partie de leurs attributions. Toutefois, comme la plupart des concepteurs n'écrivent pas de code, Visual Designer pour Windows Presentation Foundation, hébergé dans Visual Studio, ne leur est pas adapté. Pour permettre aux concepteurs d'utiliser efficacement WPF, Microsoft a créé Expression Interactive Designer. Un concepteur peut tirer parti de cet outil pour définir l'aspect d'une interface, spécifier des animations, etc. L'outil génère ensuite une version XAML du projet créé. Un développeur peut importer ce XAML dans Visual Studio et ajouter du code pour gérer les événements, par exemple. Comme Visual Studio et Expression Interactive Designer utilisent le même système de build, il est possible aux développeurs et aux concepteurs de travailler de manière interactive sur un projet, chacun utilisant les outils qu'il considère comme les plus conviviaux. L'objectif est d'aider des personnes œuvrant dans des disciplines différentes de la conception et de l'ingénierie logicielle à collaborer efficacement.

Windows Presentation Foundation et autres technologies Microsoft

Comme d'autres composants du .NET Framework 3.0, WPF a un impact sur les technologies Microsoft existantes. Les plus importantes de ces technologies sont les suivantes :

• Windows Forms : approche initiale du .NET Framework visant à créer des interfaces graphiques d'applications, Windows Forms est largement répandu actuellement. Compte tenu de cela, WPF permet l'hébergement des contrôles Windows Forms dans les applications WPF. De même, les applications Windows Forms peuvent héberger des contrôles WPF. Par exemple, une application Windows Forms peut héberger un contrôle WPF qui permet la visualisation des données en trois dimensions. Bien qu'il existe des limitations, il est parfaitement possible de créer des applications qui utilisent les deux technologies. Notez que les applications Windows Forms existantes vont continuer de fonctionner sans modification dans un environnement .NET Framework 3.0.

• Win32 et Microsoft Foundation Classes (MFC) : comme avec Windows Forms, il est possible d'héberger des contrôles WPF dans des applications existantes créées à l'aide de ces deux technologies, et vice-versa. L'interopérabilité est cependant plus complexe qu'avec Windows Forms car, contrairement à Windows Forms, les applications Win32 et MFC ne sont pas fondées sur le CLR. L'interopérabilité avec WPF requiert donc un mappage entre le code CLR et le code Win32 natif.

• Direct3D : élément de la famille des API de DirectX, Direct3D permet aux applications de créer et d'afficher des graphiques 3D. Avec le .NET Framework 3.0, les applications Windows standard peuvent tirer parti des fonctionnalités 3D de WPF plutôt que de l'approche plus spécialisée de Direct3D. Certaines applications qui requièrent cependant des performances accrues, notamment les jeux en 3D, vont continuer d'utiliser Direct3D. En fait, en sous-main, WPF s'appuie sur Direct3D pour tout ce qui concerne le rendu.

• Windows Communication Foundation : comme indiqué dans le scénario présenté précédemment, les applications WPF peuvent utiliser WCF. Toutefois, les XBAP ne peuvent pas généralement exploiter WCF car celui-ci requiert une confiance totale. Chaque XBAP téléchargé depuis Internet s'exécute dans un sandbox partiellement de confiance, ce qui lui interdit l'accès à WCF. Les XBAP peuvent utiliser les services Web ASP.NET. Ils peuvent donc effectuer des appels interopérables avec WCF et d'autres implémentations de services Web.

• « WPF/E » : il convient de mentionner ici un autre aspect de WPF, bien qu'il ne fasse pas partie du .NET Framework 3.0. Son nom de code est « WPF/E » et son objectif est la prise en charge d'interfaces de type WPF sur les systèmes qui ne gèrent pas WPF. Comme le « E » (everywhere, c'est-à-dire partout) le suggère, cette technologie est conçue pour être disponible partout, y compris dans les Macintosh, les petits périphériques et autres systèmes. Prévu pour être disponible après WPF, WPF/E fournira un sous-ensemble de fonctionnalités WPF complètes, y compris les graphiques 2D, l'animation et la vidéo.

Haut de page

Accéder au .NET Framework 3.0 : options de distribution

Pour permettre à une application d'utiliser le .NET Framework 3.0, cette version du Framework doit être installée sur les machines prévues pour l'exécuter. Pour Windows Vista, cela est très simple : le .NET Framework 3.0 est installé par défaut. Autrement dit, les nouveaux ordinateurs dotés de Windows Vista ou les ordinateurs existants mis à niveau vers Vista pourront automatiquement exécuter les applications.NET Framework 3.0. Le .NET Framework 3.0 peut aussi s'exécuter sous Windows XP et Windows Server 2003. Pour que les nouveaux composants du .NET Framework 3.0 soient disponibles pour les utilisateurs existants de ces systèmes, Microsoft rendra ce logiciel téléchargeable gratuitement.

Haut de page

Conclusion

Le .NET Framework 3.0 est une avancée du modèle de programmation Windows. Il accroît les possibilités du .NET Framework 2.0 et son objectif est de permettre la création d'applications avancées. Pour cela, la version 3.0 du Microsoft .NET Framework fournit différentes technologies qui résolvent chacune un problème dans le cadre du développement d'applications. En offrant cette diversité, bâtie sur une base commune, Microsoft s'efforce de proposer un tout plus efficace que la somme de ses parties et cherche à permettre aux développeurs d'exploiter de façon cohérente les différents éléments du .NET Framework 3.0 pour créer leurs applications.

Quels que soient les aspects de cette nouvelle version qu'une entreprise choisit d'adopter, la technologie aura un impact important sur les logiciels Windows. Toutes les personnes impliquées dans ce domaine, qu'il s'agisse des développeurs, des architectes ou des décideurs, se doivent de comprendre maintenant les avantages du .NET Framework 3.0.

Haut de page

Lectures complémentaires

Understanding .NET, Second Edition. David Chappell, Addison-Wesley, 2006

Introducing Windows Workflow Foundation

Introducing Windows Communication Foundation

Introducing InfoCard (Windows CardSpace)

Introducing Windows Presentation Foundation : (en cours)

À propos de l'auteur

David Chappell est directeur de Chappell & Associates (www.davidchappell.com) à San Francisco, Californie. Par ses conférences, ses écrits et ses conseils, il aide les informaticiens du monde entier à comprendre, utiliser les logiciels d'entreprise et prendre de meilleures décisions à ce sujet.

Haut de page