Prepararsi all'adozione di Windows Communication Foundation: Facilitare la migrazione futura

2025-06-17

Per garantire una migrazione futura più semplice delle nuove applicazioni ASP.NET a WCF, seguire le raccomandazioni precedenti e le raccomandazioni seguenti.

Protocolli

Disabilitare il supporto di ASP.NET 2.0 per SOAP 1.2:

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

Questa operazione è consigliabile perché WCF richiede che i messaggi siano conformi a protocolli diversi, ad esempio SOAP 1.1 e SOAP 1.2, per passare tramite endpoint diversi. Se un servizio Web ASP.NET 2.0 è configurato per supportare sia SOAP 1.1 che SOAP 1.2, ovvero la configurazione predefinita, non può essere migrato a un singolo endpoint WCF all'indirizzo originale che sarebbe certamente compatibile con tutti i client esistenti del servizio Web ASP.NET. Anche la scelta di SOAP 1.2 invece di 1.1 limiterà più gravemente la clientela del servizio.

Sviluppo di servizi

WCF consente di definire i contratti di servizio applicando l'oggetto ServiceContractAttribute alle interfacce o alle classi. È consigliabile applicare l'attributo a un'interfaccia anziché a una classe, perché in questo modo viene creata una definizione di un contratto che può essere implementato in modo diverso da qualsiasi numero di classi. ASP.NET 2.0 supporta l'opzione di applicare l'attributo WebService alle interfacce e alle classi. Tuttavia, come già accennato, esiste un difetto in ASP.NET 2.0, in base al quale il parametro Namespace dell'attributo non ha alcun effetto quando tale attributo viene applicato a un'interfaccia WebService anziché a una classe. Poiché in genere è consigliabile modificare lo spazio dei nomi di un servizio dal valore predefinito, , http://tempuri.orgusando il parametro Namespace dell'attributo WebService , è consigliabile continuare a definire ASP.NET Servizi Web applicando l'attributo ServiceContractAttribute alle interfacce o alle classi.

Avere il minor codice possibile nei metodi in base ai quali sono definite tali interfacce. Chiedere loro di delegare il lavoro ad altre classi. I nuovi tipi di servizio WCF potrebbero quindi delegare anche il lavoro sostanziale a tali classi.
Specificare nomi espliciti per le operazioni di un servizio usando il MessageName parametro di WebMethodAttribute.
```
[WebMethod(MessageName="ExplicitName")]  
string Echo(string input);  
```
Questa operazione è importante perché i nomi predefiniti per le operazioni in ASP.NET sono diversi dai nomi predefiniti forniti da WCF. Fornendo nomi espliciti, è possibile evitare di basarsi su quelli predefiniti.
Non implementare ASP.NET operazioni del servizio Web con metodi polimorfici, perché WCF non supporta l'implementazione di operazioni con metodi polimorfici.
Usa il SoapDocumentMethodAttribute per fornire valori espliciti per le intestazioni HTTP SOAPAction in base alle quali le richieste HTTP verranno instradate ai metodi.
```
[WebMethod]  
[SoapDocumentMethod(RequestElementName="ExplicitAction")]  
string Echo(string input);  
```
Adottare questo approccio permette di evitare di dover fare affidamento sul fatto che i valori SOAPAction predefiniti usati da ASP.NET e WCF siano identici.
Evitare di usare le estensioni SOAP. Se sono necessarie estensioni SOAP, determinare se lo scopo per cui vengono considerate è una funzionalità già fornita da WCF. Se questo è effettivamente il caso, riconsiderare subito la scelta di non adottare WCF.

Gestione dello stato

Evitare di dover mantenere lo stato nei servizi. Non solo il mantenimento dello stato tende a compromettere la scalabilità di un'applicazione, ma i meccanismi di gestione dello stato di ASP.NET e WCF sono molto diversi, anche se WCF supporta i meccanismi di ASP.NET in modalità di compatibilità ASP.NET.

Gestione delle eccezioni

Nella progettazione delle strutture dei tipi di dati da inviare e ricevere da un servizio, progettare anche strutture per rappresentare i vari tipi di eccezioni che possono verificarsi all'interno di un servizio che si potrebbe voler trasmettere a 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;  
        }  
    }  
}

Offrire a tali classi la possibilità di serializzare se stessi in 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;  
}

Le classi possono quindi essere usate per fornire i dettagli per le istanze SoapException esplicitamente lanciate.

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

Queste classi di eccezione saranno facilmente riutilizzabili con la classe WCF FaultException<TDetail> per generare un nuovo FaultException<AnticipatedException>(anticipatedException);

Sicurezza

Di seguito sono riportate alcune raccomandazioni sulla sicurezza.

Evitare di usare i profili ASP.NET 2.0, perché l'uso di tali profili limita l'uso di ASP.NET modalità di integrazione se il servizio è stato migrato a WCF.
Evitare di utilizzare gli elenchi di controllo di accesso (ACL) per controllare l'accesso ai servizi, poiché i servizi Web ASP.NET supportano gli ACL tramite Internet Information Services (IIS), mentre WCF non lo fa. Questo perché i servizi Web ASP.NET dipendono da IIS per l'hosting, mentre WCF non deve necessariamente essere ospitato in IIS.
È consigliabile considerare l'uso dei provider di ruoli di ASP.NET 2.0 per autorizzare l'accesso alle risorse di un servizio.

Vedere anche

Prevedere l'adozione del Windows Communication Foundation: semplificare l'integrazione futura

Condividi tramite