Vooruitlopend op de overstap naar Windows Communication Foundation: Toekomstige migratie versoepelen

Artikel
03/05/2024

Volg de voorgaande aanbevelingen en de volgende aanbevelingen om een eenvoudigere toekomstige migratie van nieuwe ASP.NET toepassingen naar WCF te garanderen.

Protocollen

Schakel de ondersteuning van ASP.NET 2.0 voor SOAP 1.2 uit:

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

Dit is raadzaam omdat WCF berichten vereist die voldoen aan verschillende protocollen, zoals SOAP 1.1 en SOAP 1.2, om verschillende eindpunten te gebruiken. Als een ASP.NET 2.0-webservice is geconfigureerd ter ondersteuning van zowel SOAP 1.1 als SOAP 1.2, wat de standaardconfiguratie is, kan deze niet worden gemigreerd naar één WCF-eindpunt op het oorspronkelijke adres dat zeker compatibel is met alle bestaande clients van de ASP.NET-webservice. Als u SOAP 1.2 kiest in plaats van 1.1, wordt de clientele van de service ernstiger beperkt.

Serviceontwikkeling

Met WCF kunt u servicecontracten definiëren door de ServiceContractAttribute interfaces of klassen toe te passen. Het wordt aanbevolen om het kenmerk toe te passen op een interface in plaats van op een klasse, omdat hiermee een definitie wordt gemaakt van een contract dat door een willekeurig aantal klassen kan worden geïmplementeerd. ASP.NET 2.0 ondersteunt de optie om het WebService kenmerk toe te passen op interfaces en klassen. Zoals al vermeld, is er echter een defect in ASP.NET 2.0, waardoor de parameter Naamruimte van het WebService kenmerk geen effect heeft wanneer dat kenmerk wordt toegepast op een interface in plaats van een klasse. Aangezien het over het algemeen raadzaam is om de naamruimte van een service te wijzigen op basis van de standaardwaarde, http://tempuri.orgmoet u met behulp van de parameter Namespace van het WebService kenmerk doorgaan met het definiëren van ASP.NET Web Services door het ServiceContractAttribute kenmerk toe te passen op interfaces of op klassen.

Zorg voor zo weinig mogelijk code in de methoden waarmee deze interfaces worden gedefinieerd. Laat ze hun werk delegeren aan andere klassen. Nieuwe WCF-servicetypen kunnen vervolgens ook hun inhoudelijke werk aan deze klassen delegeren.
Geef expliciete namen op voor de bewerkingen van een service met behulp van de MessageName parameter van de WebMethodAttribute.
```
[WebMethod(MessageName="ExplicitName")]  
string Echo(string input);  
```
Dit is belangrijk, omdat de standaardnamen voor bewerkingen in ASP.NET afwijken van de standaardnamen die door WCF worden opgegeven. Door expliciete namen op te geven, vermijdt u dat u vertrouwt op de standaardnamen.
Implementeer geen ASP.NET webservicebewerkingen met polymorfe methoden, omdat WCF geen ondersteuning biedt voor het implementeren van bewerkingen met polymorfe methoden.
Gebruik de SoapDocumentMethodAttribute opdracht om expliciete waarden op te geven voor de SOAPAction HTTP-headers waarmee HTTP-aanvragen worden gerouteerd naar methoden.
```
[WebMethod]  
[SoapDocumentMethod(RequestElementName="ExplicitAction")]  
string Echo(string input);  
```
Als u deze aanpak volgt, hoeft u niet te vertrouwen op de standaard SOAPAction-waarden die worden gebruikt door ASP.NET en WCF hetzelfde zijn.
Vermijd het gebruik van SOAP-extensies. Als SOAP-extensies vereist zijn, moet u bepalen of het doel waarvoor ze worden beschouwd, een functie is die al door WCF wordt geleverd. Als dat inderdaad het geval is, moet u de keuze herzien om WCF niet meteen aan te nemen.

Statusbeheer

Vermijd dat u de status in services moet onderhouden. Niet alleen onderhoudt de status de schaalbaarheid van een toepassing, maar de mechanismen voor statusbeheer van ASP.NET en WCF zijn erg verschillend, hoewel WCF wel ondersteuning biedt voor de ASP.NET mechanismen in ASP.NET compatibiliteitsmodus.

Afhandeling van uitzonderingen

Bij het ontwerpen van de structuren van de gegevenstypen die moeten worden verzonden en ontvangen door een service, ontwerpt u ook structuren om de verschillende soorten uitzonderingen weer te geven die kunnen optreden binnen een service die u aan een klant wilt overbrengen.

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

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

Geef dergelijke klassen de mogelijkheid om zichzelf te serialiseren naar 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;  
}

De klassen kunnen vervolgens worden gebruikt om de details op te geven voor expliciet gegenereerde SoapException exemplaren:

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

Deze uitzonderingsklassen kunnen gemakkelijk opnieuw worden gebruikt met de WCF-klasse FaultException<TDetail> om een nieuwe klasse te genereren FaultException<AnticipatedException>(anticipatedException);

Beveiliging

Hier volgen enkele beveiligingsaanaanvelingen.

Vermijd het gebruik van ASP.NET 2.0-profielen, omdat ze het gebruik van ASP.NET integratiemodus zouden beperken als de service is gemigreerd naar WCF.
Vermijd het gebruik van ACL's om de toegang tot services te beheren, omdat ASP.NET webservices ACL's ondersteunt met IIS (Internet Information Services), WCF niet, omdat ASP.NET webservices afhankelijk zijn van IIS voor hosting en WCF niet noodzakelijkerwijs hoeft te worden gehost in IIS.
Overweeg het gebruik van ASP.NET 2.0-rolproviders voor het autoriseren van toegang tot de resources van een service.

Zie ook

Vooruitlopend op de overstap naar Windows Communication Foundation: Toekomstige integratie easing

Delen via