A importância dos Namespaces em serviços

Para gerar um serviço WCF da forma politicamente correta, é necessário criarmos uma classe que representará o serviço, e implementar nela a Interface que é considerada como contrato do serviço. Você não está restrito em uma relação um para um, ou seja, você pode implementar quantas Interfaces quiser na classe que representa o serviço. Os membros expostos por essas Interfaces, somente serão propagados para o cliente se você mencioná-los durante a criação de um endpoint.

A partir do momento que você pode receber Interfaces criadas por outros membros do time, ou até mesmo por outras empresas, há a possibilidade de haver nomes de Interfaces e de membros iguais. Quando isso acontece, podemos utilizar um recurso fornecido pela própria linguagem, que é a implementação explícita da Interface, e os conflitos de nomenclatura não ocorrem.

Como essa classe trata-se de um serviço WCF, se utilizarmos esse recurso tudo compilará sem problemas, mas ao rodar o serviço, teremos uma exceção do tipo InvalidOperationException sendo disparada. Mas porque isso ocorre? Quando você invoca um serviço WCF a partir de um cliente qualquer, dentro do envelope SOAP temos a SoapAction. Essa informação determina o “alvo” da requisição, ou melhor, qual a operação que será disparada no serviço. Essa informação é uma junção entre as propriedades Namespace do atributo ServiceContractAttribute com a propriedade Name, exposta pelo atributo OperationContractAttribute. Quando essas configurações não são informadas, por padrão, ele define a propriedade Namespace para “http://tempuri.org/”, e com isso, a SoapAction final será: “http://tempuri.org/TeuContrato/TuaOperacao”.

Sendo assim, como temos Interfaces com o mesmo nome, e talvez até a mesma estrutura, elas terão em tempo de execução a mesma SoapAction. Com isso, o WCF não conseguirá entender para qual delas encaminhar a requisição, e neste caso antes de efetivamente abrir o host, irá disparar a exceção que falamos acima. Assim como os namespaces que utilizamos no VB.NET/C#, os namespaces do XML também servem para evitar conflitos de nomenclatura, como é o caso aqui. Configurando os contratos com os seus respectivos namespaces, evitaremos o problema. O código abaixo ilustra isso:

namespace Core
{
    [ServiceContract(Namespace = “http://www.israelaece.com/Core”)]
    public interface IContrato
    {
        [OperationContract]
        string Ping(string value);
    }
}

namespace Tools
{
    [ServiceContract(Namespace = “http://www.israelaece.com/Tools”)]
    public interface IContrato
    {
        [OperationContract]
        string Ping(string value);
    }
}

É importante não confundir o endereço do serviço com a SoapAction. O endereço do serviço é aquele que definimos durante a criação do endpoint, enquanto a SoapAction é o “alvo” da requisição. Convencionou-se utilizar uma URL na SoapAction, mas isso não é uma obrigação, ou seja, você poderia utilizar algo como “AppCore” e “AppTools” ao invés. Geralmente utiliza-se a URL quando o serviço está público, e o nome da aplicação se ele está acessível apenas internamente.

WCF Vídeos

Em uma série de 10 vídeos, eu abordei os principais tópicos para começar a dar os primeiros passos com o WCF, que é a tecnologia Microsoft para o desenvolvimento de aplicações distribuídas. A idéia foi mostrar como podemos criar, gerenciar e consumir um serviço, abordando de uma forma simples e objetiva, sem entrar em menores detalhes, justamente porque cada vídeo está relacionado a um artigo mais completo, com uma abordagem mais profunda. Abaixo temos a listagem destes vídeos, que totalizam 5 horas:

  1. 00:40:49 – Tipos de Mensagens
  2. 00:30:31 – Sincronização
  3. 00:33:30 – Tratamento de Erros
  4. 00:38:05 – Deployment

Os projetos que utilizei para demonstrar todas essas funcionalidades, podem ser baixados clicando aqui. Com isso, finalizo aqui esta primeira série de vídeos sobre WCF. Em um futuro próximo, talvez eu crie uma nova série, mas com tópicos um pouco mais avançados.

WCF Vídeo – Deployment

Este vídeo exibe como podemos proceder para efetuar a distribuição de um serviço WCF, de uma forma superficial. Como exemplo, migraremos o hosting de uma aplicação Console para um Windows Service. Além disso, ele ainda aborda algumas práticas para a reutilização do proxy entre aplicações.