Anticipación de la adopción de Windows Communication Foundation: cómo facilitar la futura migración

Artículo
05/09/2023

Para garantizar una migración futura más sencilla de las nuevas aplicaciones ASP.NET a WCF, siga las recomendaciones anteriores y las siguientes.

Protocolos

Deshabilite la compatibilidad de ASP.NET 2.0 para SOAP 1.2:

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

Esto es aconsejable, ya que WCF necesita que los mensajes se ajusten a protocolos diferentes, como SOAP 1.1 y SOAP 1.2, para poder usar distintos puntos de conexión. Si un servicio web ASP.NET 2.0 se configura para admitir SOAP 1.1 y SOAP 1.2, que es la configuración predeterminada, no se puede migrar hacia un único punto de conexión WCF en la dirección original que, por supuesto, sería compatible con todos los clientes existentes del servicio web ASP.NET. Además, la elección de SOAP 1.2 en lugar de 1.1, restringirá aún más severamente la clientela del servicio.

Desarrollo del servicio

WCF permite definir los contratos de servicio mediante la aplicación ServiceContractAttribute a las interfaces o a las clases. Se recomienda aplicar el atributo a una interfaz en lugar de a una clase ya que, de este modo, se crea una definición de un contrato que puede ser implementado de manera muy diversa por cualquier número de clases. ASP.NET 2.0 admite la opción de aplicar el atributo WebService a interfaces y a clases. Sin embargo, como ya se ha mencionado, existe un defecto en ASP.NET 2.0, por el que el parámetro de espacio de nombres del atributo WebService no se activa si se aplica ese atributo a una interfaz en lugar de a una clase. Dado que, por lo general, se aconseja modificar el valor predeterminado del espacio de nombres de un servicio, http://tempuri.org, mediante el parámetro de espacio de nombres del atributo WebService, los servicios web ASP.NET deben seguir definiéndose mediante la aplicación del atributo ServiceContractAttribute a las interfaces o a las clases.

Reduzca el código al mínimo posible en los métodos que definen esas interfaces. Consiga que deleguen su trabajo en otras clases. Los nuevos tipos de servicio WCF también pueden delegar su trabajo esencial a esas clases.
Proporcione los nombres explícitos de las operaciones de un servicio mediante el parámetro MessageName de WebMethodAttribute.
```
[WebMethod(MessageName="ExplicitName")]  
string Echo(string input);  
```
Esto es importante, ya que los nombres predeterminados de las operaciones en ASP.NET son diferentes de los nombres predeterminados que proporciona WCF. Al proporcionar nombres explícitos, evita confiar en los predeterminados.
No implemente las operaciones del servicio web ASP.NET con métodos polimórficos, ya que WCF no es compatible con la implementación de operaciones con métodos polimórficos.
Utilice SoapDocumentMethodAttribute para proporcionar los valores explícitos de los encabezados HTTP de SOAPAction por los que las solicitudes HTTP se enrutarán a los métodos.
```
[WebMethod]  
[SoapDocumentMethod(RequestElementName="ExplicitAction")]  
string Echo(string input);  
```
Si adopta este enfoque, evitará depender de que los valores SOAPAction predeterminados que usan ASP.NET y WCF sean iguales.
Evite la utilización de las extensiones SOAP. En caso de que se necesiten extensiones SOAP, determine si el propósito para el que se están considerando es una característica que ya le proporciona WCF. Si es el caso, reconsidere la opción de no adoptar WCF de inmediato.

Administración de estado

Evite tener que mantener el estado de los servicios. El mantenimiento del estado no solo tiende a poner en peligro la escalabilidad de una aplicación, sino que además los mecanismos de administración de estados ASP.NET y WCF son muy diferentes, a pesar de que WCF admite los mecanismos ASP.NET en el modo de compatibilidad ASP.NET.

Control de excepciones.

El diseño de las estructuras de los tipos de datos enviados y recibidos por un servicio, también diseña las estructuras que representan los diferentes tipos de excepciones que pueden producirse en el servicio que se desea hacer llegar a un cliente.

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

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

Otorgue a estas clases la capacidad de serializarse a 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 este modo, pueden utilizarse para proporcionar detalles de las instancias SoapException explícitamente iniciadas:

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

Estas clases de excepción se podrán reutilizar con facilidad con la clase WCF FaultException<TDetail> para iniciar un nuevo FaultException<AnticipatedException>(anticipatedException);

Seguridad

A continuación se indican algunas recomendaciones de seguridad.

Evite usar perfiles ASP.NET 2.0, ya que su uso restringiría el uso del modo de integración ASP.NET si el servicio migró a WCF.
Evite usar las ACL para controlar el acceso a los servicios, ya que los servicios web ASP.NET son compatibles con las ACL que usan Internet Information Services (IIS), pero no es el caso de WCF, porque los servicios web ASP.NET dependen de IIS para hospedarse y WCF no tiene que estar necesariamente hospedado en IIS.
Considere la utilización de los proveedores de funciones de ASP.NET 2.0 para autorizar el acceso a los recursos de un servicio.

Consulte también

Anticipación de la adopción de Windows Communication Foundation: cómo facilitar la futura integración

Compartir a través de