Preparazione all'adozione di Windows Communication Foundation: facilitazione dell'integrazione futura

Articolo
09/12/2008

Per garantire una più facile migrazione futura di nuove applicazioni ASP.NET a WCF, seguire i consigli forniti sopra nonché quelli forniti di seguito.

Protocolli

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

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

È consigliabile eseguire questa operazione in quanto in WCF i messaggi conformi a protocolli diversi, ad esempio SOAP 1.1 e SOAP 1.2, devono essere passati utilizzando endpoint diversi. Se un servizio Web di ASP.NET 2.0 è configurato per il supporto di entrambi i protocolli SOAP 1.1 e SOAP 1.2 (configurazione predefinita), non è possibile eseguirne la migrazione in avanti a un singolo endpoint WCF nell'indirizzo originale che sarebbe certamente compatibile con tutti i client esistenti del servizio Web ASP.NET. La scelta di SOAP 1.2 anziché la versione 1.1 restringerà inoltre sensibilmente il numero di clienti del servizio.

Sviluppo del servizio

WCF consente di definire contratti di servizio applicando la classe ServiceContractAttribute a interfacce o classi. È consigliabile applicare l'attributo a un'interfaccia piuttosto che a una classe perché in questo modo viene creata una definizione di contratto che può essere implementata in vari modi da un numero qualsiasi di classi. ASP.NET supporta l'opzione relativa all'applicazione dell'attributo WebService a interfacce e classi. Tuttavia, come già menzionato, ASP.NET 2.0 presenta un difetto a causa del quale il parametro Namespace dell'attributo WebService non produce alcun effetto quando l'attributo viene applicato a un'interfaccia anziché a una classe. Poiché è generalmente consigliabile modificare lo spazio dei nomi di un servizio sostituendo il valore predefinito, http://tempuri.org, utilizzando il parametro Namespace dell'attributo WebService, è necessario continuare a definire servizi Web ASP.NET applicando l'attributo ServiceContractAttribute o a interfacce o a classi.

Utilizzare meno codice possibile nei metodi mediante i quali vengono definite queste interfacce. Fare in modo che deleghino il lavoro ad altre classi. Anche nuovi tipi di servizio WCF potrebbero quindi delegare la maggior parte del lavoro a queste classi.
Fornire nomi espliciti per le operazioni di un servizio utilizzando il parametro MessageName di WebMethodAttribute.
```
[WebMethod(MessageName="ExplicitName")]
string Echo(string input);
```
È importante eseguire questa operazione perché i nomi predefiniti assegnati alle operazioni in ASP.NET sono diversi dai nomi predefiniti forniti da WCF. Fornendo nomi espliciti non è necessario basarsi su quelli predefiniti.
Non implementare operazioni di servizi Web ASP.NET con metodi polimorfici in quanto WCF non supporta questo tipo di implementazione.
Utilizzare SoapDocumentMethodAttribute per fornire valori espliciti per le intestazioni HTTP SOAPAction mediante le quali le richieste HTTP verranno indirizzate ai metodi.
```
[WebMethod]
[SoapDocumentMethod(RequestElementName="ExplicitAction")]
string Echo(string input);
```
In questo modo i valori SOAPAction predefiniti utilizzati da ASP.NET e quelli utilizzati da WCF non dovranno essere necessariamente gli stessi.
Evitare l'utilizzo di estensioni SOAP. Se le estensioni SOAP sono obbligatorie, determinare se lo scopo per il quale vengono considerate è una funzionalità già fornita da WCF. In tal caso, riconsiderare la scelta di non adottare WCF.

Gestione dello stato

Evitare di dover gestire lo stato nei servizi. Non solo la gestione dello stato tende a compromettere la scalabilità di un'applicazione, ma i meccanismi di gestione dello stato di ASP.NET e di WCF sono molto diversi, sebbene WCF supporti i meccanismi ASP.NET nella modalità compatibilità ASP.NET.

Gestione delle eccezioni

Nella progettazione delle strutture dei tipi di dati da inviare e ricevere da un servizio, progettare anche strutture che rappresentino i vari tipi di eccezioni che potrebbero verificarsi all'interno di un servizio che si desidera 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;
          }
     }
}

Impostare queste classi in modo che siano in grado di serializzarsi 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 potranno quindi essere utilizzate per fornire i dettagli per le istanze SoapException generate in modo esplicito:

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

Queste classi di eccezione potranno essere riutilizzate immediatamente con la classe FaultException di WCF per generare una nuova eccezione FaultException<AnticipatedException>(anticipatedException);.

Protezione

Di seguito sono riportati alcuni consigli sulla protezione.

Evitare di utilizzare profili di ASP.NET 2.0 poiché determinerebbe una limitazione dell'utilizzo della modalità di integrazione ASP.NET qualora venisse effettuata la migrazione del servizio a WCF.
Evitare di utilizzare elenchi di controllo di accesso (ACL) per controllare l'accesso ai servizi. I servizi Web ASP.NET supportano infatti gli ACL utilizzando Internet Information Services (IIS), mentre WCF no. I servizi Web ASP.NET dipendono da IIS per l'hosting, mentre WCF non deve essere necessariamente ospitato in IIS.
Prendere in considerazione l'utilizzo dei provider di ruoli di ASP.NET 2.0 per l'autorizzazione dell'accesso alle risorse di un servizio.

Vedere anche

Concetti

Preparazione all'adozione di Windows Communication Foundation: facilitare l'integrazione futura

Condividi tramite