Föregripa införandet av Windows Communication Foundation: Underlätta framtida migrering

Artikel
03/05/2024

För att säkerställa en enklare framtida migrering av nya ASP.NET-program till WCF följer du de föregående rekommendationerna samt följande rekommendationer.

Protokoll

Inaktivera ASP.NET 2.0-stöd för SOAP 1.2:

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

Det är lämpligt eftersom WCF kräver att meddelanden som överensstämmer med olika protokoll, till exempel SOAP 1.1 och SOAP 1.2, används med hjälp av olika slutpunkter. Om en ASP.NET 2.0-webbtjänst har konfigurerats för att stödja både SOAP 1.1 och SOAP 1.2, vilket är standardkonfigurationen, kan den inte migreras vidare till en enda WCF-slutpunkt på den ursprungliga adressen som säkert skulle vara kompatibel med alla ASP.NET webbtjänstens befintliga klienter. Om du också väljer SOAP 1.2 i stället för 1.1 begränsas tjänstens klientel avsevärt.

Tjänstutveckling

Med WCF kan du definiera tjänstkontrakt genom att tillämpa antingen på ServiceContractAttribute gränssnitt eller på klasser. Vi rekommenderar att du tillämpar attributet på ett gränssnitt i stället för på en klass, eftersom det skapar en definition av ett kontrakt som kan implementeras på olika sätt av valfritt antal klasser. ASP.NET 2.0 stöder alternativet att tillämpa WebService attributet på både gränssnitt och klasser. Men som redan nämnts finns det en defekt i ASP.NET 2.0, med vilken parametern WebService Namespace för attributet inte har någon effekt när attributet tillämpas på ett gränssnitt i stället för en klass. Eftersom det vanligtvis är lämpligt att ändra namnområdet för en tjänst från standardvärdet, http://tempuri.org, med hjälp av parametern Namespace för WebService attributet, bör man fortsätta att definiera ASP.NET Web Services genom att tillämpa ServiceContractAttribute attributet antingen på gränssnitt eller på klasser.

Ha så lite kod som möjligt i de metoder som dessa gränssnitt definieras med. Låt dem delegera sitt arbete till andra klasser. Nya WCF-tjänsttyper kan sedan också delegera sitt materiella arbete till dessa klasser.
Ange explicita namn för driften av en tjänst med parametern MessageNameWebMethodAttributeför .
```
[WebMethod(MessageName="ExplicitName")]  
string Echo(string input);  
```
Det är viktigt eftersom standardnamnen för åtgärder i ASP.NET skiljer sig från standardnamnen som tillhandahålls av WCF. Genom att ange explicita namn undviker du att förlita dig på standardnamnen.
Implementera inte ASP.NET webbtjänståtgärder med polymorfa metoder, eftersom WCF inte stöder implementering av åtgärder med polymorfa metoder.
SoapDocumentMethodAttribute Använd för att ange explicita värden för SOAPAction HTTP-huvuden med vilka HTTP-begäranden dirigeras till metoder.
```
[WebMethod]  
[SoapDocumentMethod(RequestElementName="ExplicitAction")]  
string Echo(string input);  
```
Med den här metoden kringgår du att du måste förlita dig på att standardvärdena soapaction som används av ASP.NET och WCF är desamma.
Undvik att använda SOAP-tillägg. Om SOAP-tillägg krävs avgör du om syftet med vilka de övervägs är en funktion som redan tillhandahålls av WCF. Om så verkligen är fallet bör du ompröva valet att inte anta WCF direkt.

Tillståndshantering

Undvik att behöva underhålla tillstånd i tjänster. Att underhålla tillstånd tenderar inte bara att äventyra ett programs skalbarhet, utan tillståndshanteringsmekanismerna för ASP.NET och WCF är mycket olika, även om WCF stöder ASP.NET mekanismer i ASP.NET kompatibilitetsläge.

Undantagshantering

När du utformar strukturerna för de datatyper som ska skickas och tas emot av en tjänst utformar du även strukturer som representerar de olika typer av undantag som kan uppstå inom en tjänst som man kanske vill förmedla till en klient.

[Serializable]  
[XmlRoot(Namespace="ExplicitNamespace", IsNullable=true)]  
public partial class AnticipatedException
{
    private string anticipatedExceptionInformationField;  

    public string AnticipatedExceptionInformation
    {  
        get {
            return this.anticipatedExceptionInformationField;  
        }  
        set {  
            this.anticipatedExceptionInformationField = value;  
        }  
    }  
}

Ge sådana klasser möjlighet att serialisera sig till 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;  
}

Klasserna kan sedan användas för att ange information för explicit utslängda SoapException instanser:

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

Dessa undantagsklasser kan enkelt återanvändas med WCF-klassen FaultException<TDetail> för att generera en ny FaultException<AnticipatedException>(anticipatedException);

Säkerhet

Följande är några säkerhetsrekommendationer.

Undvik att använda ASP.NET 2.0-profiler, eftersom användningen av dem skulle begränsa användningen av ASP.NET integrationsläge om tjänsten migrerades till WCF.
Undvik att använda ACL:er för att styra åtkomsten till tjänster, eftersom ASP.NET webbtjänster stöder ACL:er med hjälp av Internet Information Services (IIS), eftersom WCF inte gör det eftersom ASP.NET webbtjänster är beroende av IIS för värdtjänster och WCF inte nödvändigtvis måste finnas i IIS.
Överväg att använda ASP.NET 2.0-rollprovidrar för att auktorisera åtkomst till resurser i en tjänst.

Se även

Föregripa införandet av Windows Communication Foundation: Underlätta framtida integrering

Dela via