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

Artículo
10/07/2008

Para garantizar una migración futura más fácil de 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 exige que los mensajes sean conformes a protocolos diferentes, como SOAP 1.1 y SOAP 1.2, para poder utilizar distintos puntos finales. Si un servicio web de 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 final 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 servicios aplicando 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 en general resulta aconsejable modificar el valor predeterminado del espacio de nombres de un servicio, http://tempuri.org, utilizando el parámetro de espacio de nombres del atributo WebService, los servicios web ASP.NET deberían 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. Así, los nuevos tipos de servicio WCF también podrán delegar su trabajo principal 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 porque los nombres predeterminados de las operaciones en ASP.NET son diferentes de los nombres predeterminados proporcionados por 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 utilización de estos métodos para la implementación de operaciones.
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);
```
Al adoptar este enfoque, evitará tener que confiar en los valores SOAPAction predeterminados utilizados por ASP.NET y que WCF sea igual.
Evite la utilización de las extensiones SOAP. En caso de que se requieran extensiones SOAP, determine si el propósito para el que se están considerando es una característica que ya le proporciona WCF. Si así es, reconsidere la opción de no adoptar WCF inmediatamente.

Administración de estados

Evite tener que mantener el estado de los servicios. El mantenimiento del estado no sólo tiende a poner en peligro la escalabilidad de una aplicación, además los mecanismos de administración de estados de ASP.NET e WCF son muy diferentes, a pesar de que WCF admite los mecanismos de ASP.NET en el modo de compatibilidad de 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:

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

Estas clases de excepción pronto podrán reutilizarse con la clase WCF FaultException para iniciar una nueva FaultException<AnticipatedException>(anticipatedException);

Seguridad

A continuación se indican algunas recomendaciones de seguridad.

Evite utilizar perfiles de ASP.NET 2.0, ya que su uso restringiría la utilización del modo de integración de ASP.NET si el servicio migró a WCF.
Evite utilizar las ACL para controlar el acceso a los servicios, si bien es cierto que los servicios web ASP.NET son compatibles con las ACL que utilizan Internet Information Services (IIS), no es el caso de WCF, los servicios web ASP.NET dependen de IIS para su hospedaje, 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

Conceptos

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

Compartir a través de