Que se passe-t-il lorsque le temps de traitement sur un serveur dépasse le rythme d'envoi par les clients ? Si le rythme moyen dépasse la capacité de traitement, il faut un plus gros serveur, mais 9 fois sur 10 c'est le rythme en pic qui pose problème. Microsoft fournit une solution depuis NT4 : Message Queue Server (ou MSMQ), un serveur de messagerie applicative.

Si MSMQ est installé sur votre serveur, et que la communication entre les clients et le serveur est faite en WCF, vous pouvez très simplement vous appuyer sur MSMQ pour absorber les pics de charge.

Pour fixer les idées, imaginez le problème suivant : Votre serveur permet d'envoyer des SMS, mais il est limité à un message/seconde. Vos clients envoient le matin des vagues de SMS. Qu'un SMS mette 15 minutes à parvenir à destination n'est pas dramatique, mais il est impératif que chaque SMS soit transmis à son destinataire.

En termes techniques, le serveur expose le contrat de service suivant :

[ServiceContract]
interface ICommunicationsDiverses
{
    [OperationContract (IsOneWay=true) ]
    void EnvoieSMS(string numero, string sms);
}

Puisque nous allons stocker les demandes d'exécution en file d'attente, l'opération d'envoi de SMS ne peut pas renvoyer directement de message, il faut donc une signature void dans l'implémentation et un attribut IsOneWay dans le contrat.

La communication met maintenant en jeu trois acteurs : les clients, le serveur, et la file d'attente qui s'intercale entre les deux. Cette dernière doit être déclarée sur le poste serveur.

La suite est un simple travail de configuration, consistant à préciser aux clients et au serveur qu'ils doivent passer par la file d'attente pour se passer les messages :

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
      <bindings>
          <netMsmqBinding>
              <binding name="monBindingMSMQ">
                      <security mode="None">
                          <transport msmqAuthenticationMode="None" msmqProtectionLevel="None" />
                          <message clientCredentialType="None" />
                      </security>
              </binding>
          </netMsmqBinding>
      </bindings>

      <client>
      <endpoint
          name="nomDuEndPoint"
          address="net.msmq://localhost/Private/MaFile"
          binding="netMsmqBinding"
          contract="ICommunicationsDiverses"
          bindingConfiguration="monBindingMSMQ" >
      </endpoint>
    </client>    
  </system.serviceModel>
</configuration>

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <bindings>
      <netMsmqBinding>
        <binding name="monBindingMSMQ">
          <security mode="None">
            <transport msmqAuthenticationMode="None" msmqProtectionLevel="None" />
            <message clientCredentialType="None" />
          </security>
        </binding>
      </netMsmqBinding>
    </bindings>
    <services>
      <service name="MonAppliSuperCompliquee.ClasseImplementantLInterface">
        <endpoint address="net.msmq://localhost/Private/MaFile" binding="netMsmqBinding"
          bindingConfiguration="monBindingMSMQ" name="nomEndPointServeur" contract="ICommunicationsDiverses" />
      </service>
    </services>
    
  </system.serviceModel>
</configuration>

C'est tout. A partir de maintenant, les appels fonctionneront même si le serveur est arrêté, puisqu'ils sont stockés dans la file d'attente, et le serveur les traitera un à un quel que soit le nombre d'appels en attente.

J'ai récupéré ce matin le code source de SharpSTS (un toolkit pour cardspace), et il m'a fallu quelques recherches pour réussir à récupérer le code source depuis CodePlex, voilà le résultat de mes pérégrinations.

1/ Installez un client SubVersion

Récupérez un client subversion. TortoiseSVN est simple d'emploi, maintenu, et en plus il a des icônes rigolotes.

http://tortoisesvn.net/

2/ Installez et lancez SvnBridge

CodePlex fonctionne en réalité sous Team Foundation Server, vous allez donc installer sur votre machine un petit proxy SVN <=> TFS

http://www.codeplex.com/SvnBridge/

Le port est ce que vous voulez de disponible sur votre machine, l'adresse du serveur TFS est indiquée sur la page du projet CodePlex qui vous intéresse :

3/ Récupérez le code source

Faites-vous un répertoire là où vous voulez une copie des sources, un clic droit, et c'est tout :

4/ Et pour les commits ?

Il vous faudra un compte avec les droits de mise à jour sur le projet. Attention, le compte n'est pas directement votre login CodePlex : c'est snd\votreusername_cp

Avec la sortie de .Net 3.5, le sélecteur d'identité CardSpace est utilisable sur des sites ne disposant pas de SSL.

Cette modification se traduit techniquement par une modification du format des jetons transmis au site Web de destination. Au lieu d'être chiffré avec la clé publique du serveur Web, il transite en clair.

On ne perd pas pour autant toute forme de sécurité : le jeton est toujours signé avec une clé privée connue uniquement du sélecteur d'identité, clé qui change pour chaque site Web.

Le travail du site Web est par contre considérablement simplifié : il ne reste plus qu'à vérifier la signature du jeton avant de pouvoir le manipuler.

Vous pouvez tester dès aujourd'hui sur http://bridge2.grognon.com/, et je posterai prochainement le code du sample.

Si vous avez regardé une démonstration ou deux sur Cardspace vous avez probablement été conquis par la technologie et vous voudriez l’expérimenter un peu. Ce tutorial vous explique comment configurer tous les éléments nécessaires au développement Cardspace sous Windows Vista FR.

Pour Windows 2003 ou Windows XP la démarche est identique, j’explique les différences les plus importantes au fur et à mesure de l’article.

Je ne rentrerai pas dans le détail de l’installation de Visual Studio ou Visual Web developer dans ce pas à pas. Sachez simplement que pour bien fonctionner sous Vista vous devrez installer le SP1 puis un patch (l’adresse est donnée lors du lancement de Visual Studio SP1, ainsi que les conseils d’utilisation). Il vous faudra également sous XP ou 2003 installer .Net 3.0 et IE7.

Installation d’IIS sous Vista

Allez dans le panneau de configuration, dans la zone Programmes, et sélectionnez « Activer ou désactiver des fonctionnalités Windows ».

N’oubliez pas d’activer les options de compatibilité IIS6, Visual Web Express en aura besoin pour se connecter au site web local.

Lancer ensuite un command prompt en mode administrateur, et enregistrez ASP.Net :

Génération et installation du certificat SSL.

A moins de déjà disposer d’un certificat SSL, vous voudrez certainement générer un certificat de test. La solution la plus simple consiste à télécharger le Kit de ressources d’IIS 6 (fonctionne pour Vista, 2003, et longhorn server), que vous trouverez en faisant une recherche sur « IIS Resource Kit ». Lors de l’installation du kit, demandez uniquement l’installation de SelfSSL.

Relancez un command prompt en mode administrateur et générez votre certificat :

La commande à exécuter est en surbrillance, pour les amateurs de copier/coller il s’agit de
SelfSSL /N:CN=www.test.com /V:3650

Nota bene pour les utilisateurs de XP :

Cette étape de génération de certificat est plus délicate sous Windows XP, SelfSSL n’étant pas disponible. Sans entrer dans les détails, voici les principaux écueils à franchir :

1/ Récupérez l’exécutable MakeCert dans les SDKs

2/ Générez un certificat avec la commande barbare suivante :

makecert.exe -a SHA1 -ss my -sr LocalMachine -n "CN=www.test.com" -b 01/01/2000 -e 01/01/2050  -eku 1.3.6.1.5.5.7.3.1 -sky exchange  -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

3/ Allez dans les propriétés de votre serveur Web, dans l’onglet sécurité, et attribuez le certificat à votre site. Vous êtes maintenant arrivés au même point que les utilisateurs de 2003 ou Vista.

Post scriptum de nota bene

Je tiens à présenter toutes mes excuses aux légitimes détenteurs du domaine test.com pour distraire d'honnêtes développeurs d'un site probablement plein d'intérêt.

Modification du fichier Hosts

Pour que votre certificat soit reconnu, vous devrez faire pointer le site http://www.test.com/ sur votre machine de développement. Pour ce faire, il vous faudra modifier le fichier HOSTS situé dans

C:\windows\system32\drivers\etc

ATTENTION : il s’agit d’un fichier protégé, il est donc impératif de lancer Notepad en tant qu’administrateur si vous voulez le modifier.

Lancez un navigateur et allez sur https://www.test.com/

Comme le certificat n’a pas été délivré par une autorité de confiance, IE nous bloque. Nous allons remédier à cela.

1/ Lancez une console d’administration (en tapant mmc)

2/ Dans le menu Fichier, demandez l’ajout d’un composant enfichable. Dans la liste qui apparaît, double-cliquez sur Certificats et choisissez Compte de l’ordinateur dans la boite de dialogue qui apparaît.

3/ Vous devriez maintenant pouvoir accéder au certificat que vous venez de générer :

Copiez maintenant ce certificat dans les certificats des Autorités de certification racine. De cette façon ce certificat sera considéré comme valide par Internet Explorer. Rafraichissez maintenant IE, vous devriez parvenir au résultat escompté :

Paramétrage du certificat pour CardSpace.

Il nous reste une dernière manipulation à effectuer : notre application Web aura tôt ou tard besoin de lire la clé privée du certificat que nous venons de générer. Par défaut, cette clé est protégée et aucune application Web ne peut s’en servir directement. Il existe des méthodes plus élégantes que celle que je vais vous donner maintenant, mais elles demandent des outils supplémentaires.

Relancer un command prompt en mode administrateur et rendez-vous dans le répertoire \ProgramData\Microsoft\Crypto\RSA\MachineKeys

Puis tapez Explorer . (n’oubliez pas le point)

Si aucun fichier n’apparaît modifiez vos options d’affichage pour voir les fichiers système.

(nota : le chemin pour XP/2003 est C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys)

Sélectionnez maintenant le fichier le plus récent (il représente le certificat que vous venez d’ajouter), et modifiez sa sécurité pour donner au compte SERVICE RÉSEAU les droits de lecture sur le fichier.

Attention, le compte est bien SERVICE RÉSEAU avec un é en majuscules (faites un copier/coller depuis cet article si vous ne savez pas faire un É avec votre clavier). Il s’agit du compte qui fait tourner votre site web, vous pouvez bien sûr le modifier en allant dans la console d’administration d’IIS.

(nota : sous XP le compte est probablement ASPNET)

Tester l’installation

Placez le fichier test.aspx dans c:\inetpub\wwwroot et naviguez sur https://www.test.com/test.aspx

Le bouton Déclencher le sélecteur devrait faire apparaître le sélecteur d’identité où vous pourrez sélectionner une carte personnelle.

Elle servira à générer un jeton chiffré consultable dans la textbox (enfin, vous n’apprendrez pas grand-chose puisqu’il est chiffré) ? Le bouton Envoyer au serveur déclenchera le décodage du jeton et l’affichage de son contenu.

Comment proposer une alternative à FTP sous Windows 2003 ? Aujourd'hui, j'ai trouvé trois grandes directions de recherche

SSH + sFTP

BITS

WebDAV + SSL

SSH sous Windows : je n'ai pas épuisé le sujet, mais je n'ai pas trouvé d'implémentation standard, simple de mise en oeuvre, et stable sous Windows 2003. La piste la plus prometteuse pour le moment est un portage Win32 de OpenSSH (http://sourceforge.net/projects/sshwindows), mais le forum et la liste des bugs sont dissuasifs : pas d'activité depuis longtemps, et des problèmes récurrents de stabilité.

BITS : l'implémentation est robuste et l'intégration serveur est bonne, il manque encore un client disponible pour mes utilisateurs. Pour le moment on trouve un utilitaire en ligne de commande pour XP, et quelques wrappers .Net pour la manipulation des jobs, mais il reste quelques ennuyeux problèmes de sécurité (notamment comment protéger un login et un password dans l'application cliente). Exit donc pour quelque temps.

WebDAV + SSL : plus intéressant, puisque la couche de sécurité est robuste et qu'un client WebDav est intégré à l'explorateur Windows. C'est cette solution que je retiens pour le moment. Il reste encore quelques écueils à surmonter, principalement côté serveur. En deux mots, je me refuse à utiliser WebDAV sans SSL.

Ma roadmap :

1/ Installation de  WebDAV

Simple, WebDAV est planqué dans l'install de Windows

2/ Création d'un AppPool avec un compte spécifique. Ce compte est destiné à limiter les privilèges des sites manipulant WebDAV

3/ Création d'une zone disque et d'un site web destiné aux transferts

4/ Pose de SSL sur le site.

cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings ":443:<host header>"

cscript.exe adsutil.vbs set /w3svc/<site identifier>/AccessSSL TRUE

Voilà, SSL est posé et seul SSL est utilisable.

Vista est sur le point de sortir, alors esayons d'y voir clair en matière de développement. Malgré tout ce que vous avez pu entendre ou lire ces derniers mois, Vista est beaucoup plus qu'un relookage de Windows XP. Pour vous en convaincre, allez donc lire http://en.wikipedia.org/wiki/Windows_Vista, qui déroule en une seule page concise la liste des nouveautés.

Dans l'ensemble, les applications Windows conçues pour XP tournent directement sur Vista. Dans l'ensemble seulement, puisque les nombreuses modifications liées à la sécurité bloquent certaines fonctionnalités des programmes. Les applications .Net sont bien évidemment peu concernées par ces modifications, puisqu'elles reposent sur un framework conçu et adapté par Microsoft. Pour les applications Win32 classiques tout dépend de ce que fait votre programme, et plus vous tentiez de prendre la main sur le fonctionnement normal de l'OS plus vous risquez de mauvaises surprises en exécution dans un environnement normal sous Vista (vous pouvez bien sûr détacher les ceintures de sécurité et désactiver un certain nombre de protections, mais c'est à vos risques et périls).

Visual Studio est l'une des applications les plus intrusives sur le système d'exploitation : intégration d'un débogueur capable de prendre la main dans tous les environnements, de JavaScript à VB6 en passant pas SQL Server et .Net, accès aux services, déboguage à distance, développement de drivers, etc. En pratique, Visual Studio (2002, 2003, et 2005) ne fonctionne pas complètement sous Vista : en tant qu'éditeur de code et environnement de compilation il donne satisfaction, mais certaines fonctionnalités avancées seront vraisemblablement bloquées par le système d'exploitation.

Quelles sont les possibilités offertes au développeur pour se prémunir contre les mauvaises surprises ? Pour Visual Studio 2005, le SP1 devrait combler la plupart des lacunes, et les éventuels bugs résiduels seront corrigés au fur et à mesure de leur découverte. Pour Visual Studio 2003 le problème est plus délicat, et pour le moment Microsoft ne supporte pas Visual Studio 2003 sous Vista, même si la plupart des scénarios d'utilisation fonctionnent. Il reste alors deux possibilités. Soit faire tourner Visual Studio 2003 sous Windows XP (éventuellement dans une VPC) ou Windows 2003, soit utiliser MSBuild pour éditer et compiler des projets .Net 1.1.

Cette possibilité n'est pas offerte nativement par MSBuild, mais vous trouverez sur CodePlex la solution (http://www.codeplex.com/Wiki/View.aspx?ProjectName). MSBee, puisque c'est son nom, est un add-on à MSBuild permettant de faire de la compilation .Net 1.1 depuis MSBuild, et donc d'utiliser le même outil pour .Net 1, 2 et 3 dans vos développements.