A découvrir d'urgence : Ekioo, le blog de ma société

samedi 24 janvier 2009

WCF et IIS avec les sites web qui ont des identités multiples

Je profite du dernier post de Cyril Durand pour finaliser un petit article que j'avais entamé sans jamais vraiment le finir. Il concerne le problème du binding des services WFC sur un IIS qui gère plusieurs identités pour le même site web :

This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.
Parameter name: item


où pour les francophones :

Cette collection contient déjà une adresse avec le schéma http. Une adresse tout au plus par schéma est possible dans cette collection.
Nom du paramètre : item

Voici ce qui se passe lorsque vous avez un site web configuré avec plusieurs identités ( ex: www.siteweb.com et siteweb.com ) lorsque vous tentez d'accéder au fichier Service.svc de votre service WCF.

Pourquoi ? WCF ne supporte pas les identités multiples sur le même site. Comment faire dès lors pour résoudre cette épineuse situation ?

De nombreux blogs proposent des solutions, qui si elles ne résolvent pas réellement le problème, ont le mérite d'aider à comprendre comment tout cela fonctionne :

Sur developpez.net, un premier échanges m'a permit d'identifier que le problème venait effectivement des identités multiples. Les serveurs mutualisés qui n'y font pas attention sont les premiers touchés.

Une première solution est donnée par Rob Reynolds : Il faut dériver la classe ServiceHostFactory comme suit :

using System.ServiceModel;
using System.ServiceModel.Activation;

public class CustomServiceFactory : ServiceHostFactory
{

private int baseAddressIndex = 0;

protected override ServiceHost CreateServiceHost(System.Type serviceType, System.Uri[] baseAddresses)
{
return new ServiceHost(serviceType, baseAddresses[baseAddressIndex]);
}
}
Puis, dans le fichier *.svc :

<%@ ServiceHost Language="VB" Debug="true"
Service="Organization.Services.TempService"
Factory="Organization.Services.CustomServiceFactory" %>
Premier problème, comment connaitre l'indice de l'adresse qu'on souhaite utiliser ?
Deuxième problème, que se passe t'il si notre service WPF est instancié pour le nom de domaine www.siteweb.com une première fois (là ça marche) et qu'on tente d'y accéder ensuite via siteweb.com (là, ça marche plus).

L'idée n'était pourtant pas si mal et venait d'ici à l'origine.

Deux autres échanges ici et m'ont finalement menés à une solution qui semblait prometteuse. Mais voila, la solution du filtre permet en pratique de faire fonctionner WCF avec une seule identité. Or, je ne souhaite pas choisir en www.siteweb.com et siteweb.com, je veux que la solution marche dans tout les cas !

Je n'ai pas testé la solution de Cyril qui semble avoir réussit à gérer les différentes identités en se passant du fichier de configuration WFC. Pour des raisons de performances, j'avais déjà décidé de laisser de coté les services WCF pour faire communiquer Silverlight avec mes services webs.

Actuellement, j'utilise une solution à base de javascript, de serialisation json en ayant implémenté quelques fonctions génériques qui simplifient bien la vie. Si j'ai un temps de temps, je décrirais cette méthode en détails dans un prochain article.

samedi 3 janvier 2009

LuaNet ne connait que l'ANSI

J'aime bien les scripts LUA. C'est rapide à mettre en œuvre, la syntaxe est claire, souple et ils remplissent très bien leur rôle dès qu'on souhaite séparer le coeur de l'application et d'une partie du code métier qui varie en fonction des postes, des clients, des installations, des configurations. Les scripts de manière générale permettent d'avoir un peu de souplesse sans avoir à recompiler tout le projet et LUA est vraiment la réponse que je préfère pour répondre à cette problématique.

Mais, LuaNet, qui est l'implémentation que j'utilise pour C#, est incapable de traiter les fichiers encodés en Unicode, ou en UTF-8, ou en quoi que ce soit d'autre que l'ANSI. La fonction DoFile qui parait si pratique retourne systématiquement un joli "unexpected symbol near 'ï'" et nous voila dans l'obligation de convertir obligatoirement tout les nos fichiers lua au format ANSI. Tout de même, je ne sait pas comment est écrite cette fonction, mais il serait si facile de gérer l'UTF-8 que je me demande pourquoi cela n'a pas déjà été fait.