Anticipation de l'adoption de Windows Communication Foundation : faciliter la future migration

Article
09/12/2008

Pour faciliter une future migration des nouvelles applications ASP.NET vers WCF, suivez les recommandations précédentes ainsi que les recommandations suivantes.

Protocoles

Désactivez la prise en charge d'ASP.NET 2.0 pour SOAP 1.2 :

<configuration>
     <system.web>
      <webServices >
          <protocols>
           <remove name="HttpSoap12"/>
          </protocols>  
      </webServices>
     </system.web> 
</configuration>

Cette procédure est recommandée parce que WCF requiert des messages qui se conforment à différents protocoles, tels que SOAP 1.1 et SOAP 1.2, et utilisent différents points de terminaison. Si un service Web ASP.NET 2.0 est configuré pour prendre en charge SOAP 1.1 et SOAP 1.2 (configuration par défaut), celui-ci ne peut pas effectuer une migration en avant vers un point de terminaison WCF unique à l'adresse originale qui serait certainement compatible avec tous les clients existants du service Web ASP.NET. De plus, le choix de SOAP 1.2 au lieu de 1.1 restreint davantage la clientèle du service.

Développement des services

WCF vous permet de définir des contrats de service en appliquant ServiceContractAttribute aux interfaces ou aux classes. Il est recommandé d'appliquer l'attribut à une interface plutôt qu'à une classe, afin de créer une définition d'un contrat qui peut être implémenté de différentes façons par un nombre illimité de classes. ASP.NET 2.0 prend en charge la possibilité d'appliquer l'attribut WebService aux interfaces aussi bien qu'aux classes. Toutefois, comme indiqué précédemment, ASP.NET 2.0 présente un défaut qui fait que le paramètre Namespace de l'attribut WebService n'a aucun effet lorsque cet attribut est appliqué à une interface plutôt qu'à une classe. Comme il est généralement recommandé de remplacer la valeur par défaut de l'espace de noms d'un service, http://tempuri.org, par le paramètre Namespace de l'attribut WebService, il faut continuer à définir des services Web ASP.NET en appliquant l'attribut ServiceContractAttribute aux interfaces ou aux classes.

Les méthodes chargées de définir ces interfaces doivent contenir un minimum de code. Faites-les déléguer leur tâche à d'autres classes. Les nouveaux types de services WCF peuvent aussi déléguer par la suite les tâches importantes à ces classes.
Fournissez des noms explicites pour les opérations d'un service à l'aide du paramètre MessageName de WebMethodAttribute.
```
[WebMethod(MessageName="ExplicitName")]
string Echo(string input);
```
Ce procédé est important parce que les noms par défaut pour les opérations dans ASP.NET sont différents des noms par défaut fournis par WCF. En fournissant des noms explicites, vous n'avez pas à vous reposer sur les noms par défaut.
N'implémentez pas d'opérations de service Web ASP.NET avec des méthodes polymorphes, car WCF ne prend pas en charge l'implémentation des opérations ayant des méthodes polymorphes.
Utilisez le SoapDocumentMethodAttribute afin de fournir des valeurs explicites pour les en-têtes HTTP SOAPAction chargés d'acheminer les demandes HTTP aux méthodes.
```
[WebMethod]
[SoapDocumentMethod(RequestElementName="ExplicitAction")]
string Echo(string input);
```
Cette approche évite de dépendre des valeurs SOAPAction par défaut utilisées par ASP.NET et WCF qui sont identiques.
Évitez l'utilisation des extensions SOAP. Si les extensions SOAP sont requises, déterminez si leur choix correspond à une fonctionnalité déjà fournie par WCF. Si tel est le cas, reconsidérez le choix de ne pas adopter WCF immédiatement.

Gestion des états

Évitez de devoir maintenir l'état dans les services. La maintenance de l'état tend non seulement à compromettre l'évolutivité d'une application, mais les mécanismes de gestion d'état d'ASP.NET et WCF sont très différents, bien que WCF prenne en charge les mécanismes ASP.NET en mode de compatibilité ASP.NET.

Gestion des exceptions

Lors de la conception des structures des types de données à envoyer et à recevoir par un service, concevez aussi des structures pour représenter les divers types d'exceptions qui peuvent se produire dans un service et qu'il faut décrire éventuellement à un client.

[Serializable]
[XmlRoot(
     Namespace="ExplicitNamespace", IsNullable=true)]
    public partial class AnticipatedException {
     
     private string anticipatedExceptionInformationField;
 
     public string AnticipatedExceptionInformation {
      get {
          return this.anticipatedExceptionInformationField;
          }
      set {
          this.anticipatedExceptionInformationField = value;
          }
     }
}

Donnez à ces classes la possibilité de se sérialiser en code XML :

public XmlNode ToXML()
{
     XmlSerializer serializer = new XmlSerializer(
      typeof(AnticipatedException));
     MemoryStream memoryStream = new MemoryStream();
     XmlTextWriter writer = new XmlTextWriter(
     memoryStream, UnicodeEncoding.UTF8);
     serializer.Serialize(writer, this);
     XmlDocument document = new XmlDocument();
     document.LoadXml(new string(
     UnicodeEncoding.UTF8.GetChars(
     memoryStream.GetBuffer())).Trim());
    return document.DocumentElement;
}

Ces classes peuvent ensuite servir à fournir les détails pour les instances SoapException levées explicitement :

AnctipatedException exception = new AnticipatedException();
exception.AnticipatedExceptionInformation = "…";
throw new SoapException(
     "Fault occurred",
     SoapException.ClientFaultCode,
     Context.Request.Url.AbsoluteUri,
     exception.ToXML());

Ces classes d'exception sont réutilisables avec la classe WCF FaultException pour lever une nouvelle FaultException<AnticipatedException>(anticipatedException);

Sécurité

Les éléments suivants sont des recommandations de sécurité.

Évitez d'utiliser des profils ASP.NET 2.0, car leur utilisation peut restreindre l'utilisation du mode intégration ASP.NET si le service a été migré vers WCF.
Évitez d'utiliser les listes de contrôle d'accès pour contrôler l'accès aux services, car les services Web ASP.NET prennent en charge ces listes à l'aide des services Internet (IIS), ce qui n'est pas le cas de WCF. En effet, les services Web ASP.NET dépendent d'IIS pour l'hébergement et il n'est pas forcément nécessaire d'héberger WCF dans IIS.
Vous pouvez faire appel à des fournisseurs de rôles ASP.NET 2.0 pour autoriser l'accès aux ressources d'un service.

Voir aussi

Concepts

Anticipation de l'adoption de Windows Communication Foundation : faciliter l'intégration future

Partager via