Antecipando a adoção do Windows Communication Foundation: facilitando a migração futura

Artigo
03/05/2024

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

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

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

Fazer isso é aconselhável 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 suportar 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. Além disso, escolher SOAP 1.2 em vez de 1.1 restringirá mais severamente a clientela do serviço.

Desenvolvimento de Serviços

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, porque isso cria uma definição de um contrato que pode ser implementada de forma variada por qualquer número de classes. ASP.NET 2.0 suporta a opção de aplicar o WebService atributo 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 não tem efeito quando esse atributo é aplicado a uma interface em vez de WebService uma classe. Como geralmente é aconselhável modificar o namespace de um serviço a partir do valor padrão, http://tempuri.orgusando o parâmetro Namespace do WebService atributo, deve-se continuar definindo ASP.NET Web Services aplicando o ServiceContractAttribute atributo a interfaces ou a classes.

Tenha o mínimo de código possível nos métodos pelos quais essas interfaces são definidas. Peça-lhes que deleguem o seu trabalho a outras turmas. 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 MessageName parâmetro WebMethodAttributedo .
```
[WebMethod(MessageName="ExplicitName")]  
string Echo(string input);  
```
Fazer isso é importante, porque os nomes padrão para operações no ASP.NET são diferentes dos nomes padrão fornecidos pelo WCF. Ao fornecer nomes explícitos, você evita confiar nos nomes padrão.
Não implemente operações de serviço Web ASP.NET com métodos polimórficos, porque o WCF não oferece 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);  
```
Adotar essa abordagem evitará ter que confiar nos valores padrão de SOAPAction 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, então reconsidere a escolha de não adotar o WCF imediatamente.

Gestão do Estado

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

Processamento de Exceções

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 se deseja 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 serializar-se para 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;  
}

As classes podem ser usadas para fornecer os detalhes para instâncias explicitamente lançadas SoapException :

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 WCF FaultException<TDetail> para lançar um novo FaultException<AnticipatedException>(anticipatedException);

Segurança

Seguem-se 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 ASP.NET serviços Web oferecem suporte a ACLs usando o IIS (Serviços de Informações da Internet), o WCF não — porque ASP.NET serviços Web dependem do IIS para hospedagem e o WCF não precisa necessariamente ser hospedado no IIS.
Considere usar ASP.NET Provedores de Função 2.0 para autorizar o acesso aos recursos de um serviço.

Consulte também

Antecipando a adoção do Windows Communication Foundation: facilitando a integração futura

Partilhar via