Antecipar a adoção do Windows Communication Foundation: facilitar a migração futura

Artigo
05/09/2023

Para garantir uma migração futura mais fácil de novos aplicativos ASP.NET para o WCF, siga as recomendações anteriores, bem como as recomendações a seguir.

Protocolos

Desabilite o suporte do ASP.NET 2.0 para SOAP 1.2:

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

Esse procedimento é recomendado porque o WCF requer mensagens em conformidade com diferentes protocolos, como SOAP 1.1 e SOAP 1.2, para usar pontos de extremidade diferentes. Se um serviço Web ASP.NET 2.0 estiver configurado para dar suporte a SOAP 1.1 e SOAP 1.2, que é a configuração padrão, ele não poderá ser migrado para um único ponto de extremidade WCF no endereço original que certamente seria compatível com todos os clientes existentes do serviço Web ASP.NET. Também escolher SOAP 1.2 em vez de 1.1 restringirá mais severamente a clientela do serviço.

Desenvolvimento do serviço

O WCF permite que você defina contratos de serviço aplicando o ServiceContractAttribute a interfaces ou a classes. Recomenda-se aplicar o atributo a uma interface em vez de a uma classe, pois isso cria uma definição de um contrato que pode ser implementada de maneiras diversas por qualquer número de classes. O ASP.NET 2.0 dá suporte à opção de aplicar o atributo WebService a interfaces e classes. No entanto, como já mencionado, há um defeito no ASP.NET 2.0, pelo qual o parâmetro Namespace do atributo WebService não tem efeito quando esse atributo é aplicado a uma interface em vez de a uma classe. Como geralmente recomenda-se modificar o namespace de um serviço a partir do valor padrão, http://tempuri.org, usando o parâmetro Namespace do atributo WebService, deve-se continuar definindo os serviços Web ASP.NET 2.0 aplicando o atributo ServiceContractAttribute a interfaces ou classes.

Tenha o mínimo de código possível nos métodos pelos quais essas interfaces são definidas. Faça-os delegarem seu trabalho a outras classes. Os novos tipos de serviço WCF também poderiam delegar seu trabalho substantivo a essas classes.
Forneça nomes explícitos para as operações de um serviço usando o parâmetro MessageName do WebMethodAttribute.
```
[WebMethod(MessageName="ExplicitName")]  
string Echo(string input);  
```
Fazer isso é importante, pois os nomes padrão para operações no ASP.NET diferem dos nomes padrão fornecidos pelo WCF. Ao fornecer nomes explícitos, você evita depender dos nomes padrão.
Não implemente operações de serviço Web ASP.NET com métodos polimórficos, pois o WCF não dá suporte à implementação de operações com métodos polimórficos.
Use o SoapDocumentMethodAttribute para fornecer valores explícitos para os cabeçalhos HTTP SOAPAction pelos quais as solicitações HTTP serão roteadas para métodos.
```
[WebMethod]  
[SoapDocumentMethod(RequestElementName="ExplicitAction")]  
string Echo(string input);  
```
Essa abordagem contornará a necessidade de depender dos valores SOAPAction padrão usados por ASP.NET e WCF sendo os mesmos.
Evite usar extensões SOAP. Se as extensões SOAP forem necessárias, determine se a finalidade para a qual elas estão sendo consideradas é um recurso que já é fornecido pelo WCF. Se esse for realmente o caso, reconsidere a escolha de não adotar o WCF imediatamente.

Gerenciamento do estado

Evite ter que manter o estado nos serviços. Não somente a manutenção do estado tende a comprometer a escalabilidade de um aplicativo, mas os mecanismos de gerenciamento de estado de ASP.NET e WCF são muito diferentes, embora o WCF dê suporte aos mecanismos ASP.NET no modo de compatibilidade ASP.NET.

Tratamento de exceção

Ao projetar as estruturas dos tipos de dados a serem enviados e recebidos por um serviço, também projete estruturas para representar os vários tipos de exceções que podem ocorrer dentro de um serviço que talvez se queira transmitir a um 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;  
        }  
    }  
}

Dê a essas classes a capacidade de se serializar em 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;  
}

Em seguida, as classes podem ser usadas para fornecer os detalhes das instâncias SoapException lançadas explicitamente:

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

Essas classes de exceção serão prontamente reutilizáveis com a classe FaultException<TDetail> WCF para lançar uma nova FaultException<AnticipatedException>(anticipatedException);

Segurança

Veja a seguir algumas recomendações de segurança.

Evite usar perfis ASP.NET 2.0, pois usá-los restringiria o uso do modo de integração ASP.NET, se o serviço fosse migrado para o WCF.
Evite usar ACLs para controlar o acesso a serviços, pois os serviços Web ASP.NET dão suporte a ACLs usando o IIS (Serviços de Informações da Internet), já o WCF não, porque os serviços Web ASP.NET dependem do IIS para hospedagem e o WCF não precisa necessariamente ser hospedado no IIS.
Considere usar provedores de função do ASP.NET 2.0 para autorizar o acesso aos recursos de um serviço.

Confira também

Antecipar a adoção do Windows Communication Foundation: facilitar a integração futura

Compartilhar via