Acessando servi�os WCF via TCP

A tecnologia WCF (sigla de Windows Communication Foundation) � parte integrante do .NET Framework, representando a soluç�o da Microsoft para a construç�o de aplicaç�es seguindo uma Arquitetura Orientada a Serviços (paradigma este tamb�m conhecido como SOA, sigla do ingl�s �Service-Oriented Architecture�). Em termos conceituais, um serviço deve ser compreendido como um componente de software que disponibiliza uma ou mais funcionalidades; cada uma destas pode vir a ser consumida posteriormente outras aplicaç�es.

Grande parte das aplicaç�es criadas em WCF nada mais s�o do que Web Services. Tratam-se de implementaç�es de serviços que fazem uso de um padr�o conhecido como SOAP (Simple Object Access Protocol), as quais podem ser acessadas a partir da Internet, ou at� mesmo, em uma rede privada corporativa. J� o protocolo SOAP corresponde, por sua vez, a um formato baseado na linguaguem XML. � mais do que not�ria a ampla aceitaç�o de XML por parte das principais plataformas de desenvolvimento atuais, com este padr�o sendo utilizado em larga escala para o interc�mbio de informaç�es entre softwares com as mais variadas finalidades.

Web Services s�o empregados geralmente na integraç�o entre sistemas de caracter�sticas bastante heterog�neas, chegando inclusive ao ponto de tornar poss�vel a comunicaç�o entre aplicaç�es constru�das em .NET, Java e/ou at� mainframe. A esta capacidade de interligar soluç�es t�o diversas, usando para isto um padr�o comum para transfer�ncia de informaç�es, d�-se o nome de interoperabilidade.

A comunicaç�o com qualquer serviço constru�do em WCF acontece, obrigatoriamente, por meio de estruturas conhecidas como endpoints. J� um endpoint � formado pelos seguintes elementos:

Address: endereço a partir do qual um serviço � acessado por outra aplicaç�o que consumir� o mesmo;
Binding: representa o protocolo de comunicaç�o utilizado na transfer�ncia de informaç�es. O mais comum � o uso de HTTP/SOAP, por�m a tecnologia WCF suporta outros padr�es como TCP (que � justamente o objeto de estudo deste artigo);
Contract: contratos que definem quais operaç�es (m�todos) s�o disponibilizadas para utilizaç�o do cliente/consumidor do serviço, bem como o formato dos prov�veis par�metros de cada uma destas e seus respectivos valores de retorno;
Behaviors: configuraç�es usadas na customizaç�o de diversos tipos de comportamentos em um serviço WCF.

Conforme j� mencionado, a escolha por um binding espec�fico determinar� qual o protocolo a ser utilizado na comunicaç�o entre um serviço e prov�veis consumidores do mesmo. Pelo fato de grande parte das aplicaç�es WCF representarem Web Services voltados � integraç�o de sistemas, BasicHttpBinding e WSHttpBinding costumam ser as alternativas naturais para suportar a transfer�ncia de informaç�es via HTTP/SOAP.

BasicHttpBinding � um binding que foi criado por quest�es de compatibilidade, servindo basicamente para possibilitar a construç�o de serviços em conformidade com a especificaç�o mais antiga de Web Services (WS-BasicProfile 1.1) suportada pela plataforma .NET. J� o binding WSHttpBinding � baseado em mecanismos de comunicaç�o mais recentes, permitindo a utilizaç�o de um conjunto de padr�es conhecidos como WS-*.

As especificaç�es WS-* s�o o resultado de uma iniciativa conjunta entre gigantes da �rea de Tecnologia de Informaç�o como Microsoft, Oracle e IBM, tendo por objetivo principal estabelecer uma s�rie de convenç�es que assegurem a interoperabilidade entre sistemas elaborados nas mais diferentes plataformas. Um exemplo de especificaç�o WS-* empregada em larga escala dentro de aplicaç�es orientadas a serviços � o padr�o WS-Security, o qual contempla em suas definiç�es protocolos de segurança voltados � transmiss�o de dados confidenciais.

Haver� situaç�es, no entanto, em que outros formatos al�m do padr�o SOAP/HTTP podem se revelar como mais apropriados para a transmiss�o de informaç�es. Cen�rios que envolvam a comunicaç�o de aplicaç�es .NET dentro de uma intranet podem se valer do uso do protocolo TCP, com esta opç�o oferecendo uma maior velocidade no tr�fego de dados: a implementaç�o de um serviço WCF em tais casos poder� empregar ent�o o binding netTcpBinding.

Contudo, algumas ressalvas precisam ser feitas no que diz respeito � utilizaç�o do netTcpBinding. Por mais que esta alternativa possa significar um incremento na performance, a interoperabilidade acaba por ser comprometida: isto acontece porque os objetos transmitidos de um ponto a outro foram serializados em um padr�o bin�rio pr�prio da tecnologia WCF, impedindo assim que aplicaç�es constru�das em outras plataformas consigam consumir funcionalidades atrav�s do padr�o TCP. Logo, o uso de WCF via TCP precisa ser analisado com cuidado, j� que estar� restrito a soluç�es concebidas a partir do .NET Framework.

Na pr�xima seç�o � apresentado um exemplo de soluç�o baseada na utilizaç�o da tecnologia WCF, empregando-se para isto o padr�o TCP como protocolo de comunicaç�o (por meio do uso de netTcpBinding).

Criando o serviço WCF de exemplo

A soluç�o que est� sendo apresentada neste artigo foi criada no .NET framework 4.5, atrav�s da utilizaç�o do Microsoft Visual Studio 2012 Release Candidate. Basicamente, ser� constru�do um serviço para a gravaç�o de informaç�es de log, com este componente sendo consumido por outros sistemas elaborados em .NET que necessitem registrar informaç�es como alertas, avisos de cunho geral ou, at� mesmo, erros. Far�o parte da Solution j� citada os seguintes projetos:

TesteWCF_TCP.DataContracts: conter� a classe que representa um registro de log a ser gravado numa base de dados criada especificamente para este fim;
TesteWCF_TCP.Repository: projeto no qual ser� implementada a classe de acesso a dados, a qual ser� respons�vel por persistir em uma base de dados registros de log gerados por aplicaç�es-cliente;
TesteWCF_TCP.Services: conter� a interface que define as operaç�es do serviço a ser criado, bem como a classe de implementaç�o correspondente (esta �ltima ser� respons�vel ainda por invocar a camada de acesso a dados, al�m de contar com regras de neg�cios);
TesteWCF_TCP.Hosting: aplicaç�o console por meio da qual o serviço ser� ativado para testes.

A Solution apresentada neste artigo pode ser considerada um exemplo de aplicaç�o multicamadas. Do ponto de vista pr�tico, o desenvolvimento em camadas consiste, primariamente, na criaç�o de uma soluç�o organizada em diversas partes l�gicas (camadas). Este tipo de arquitetura busca, por meio deste tipo de divis�o, a construç�o de aplicaç�es de software melhor estruturadas e com um comportamento mais flex�vel diante da necessidade de mudanças, focando ainda na possibilidade de reutilizaç�o de alguns dos componentes que foram elaborados durante a implementaç�o do projeto.

O tipo Log (Listagem 1) corresponde a um registro que representar� um erro, aviso ou ainda alerta, com tal conjunto de dados sendo gravado em uma tabela de log acess�vel ao serviço WCF que se est� construindo.

Listagem 1: Classe Log



using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Runtime.Serialization;

namespace TesteWCF_TCP.DataContracts
{
    [DataContract(Namespace = "http://TesteWCF_TCP/data/log")]
    public class Log
    {
        [DataMember(Order = 0)]
        public string Aplicacao { get; set; }

        [DataMember(Order = 1)]
        public string Mensagem { get; set; }

        public DateTime DataOcorrencia { get; set; }

        public string TipoOcorrencia { get; set; }
    }
}

Esta classe (Log) � um bom exemplo de um tipo de elemento conhecido dentro de WCF como Data Contract. Em termos gerais, um Data Contract nada mais � do que um tipo complexo, ou seja, uma estrutura composta pela combinaç�o de tipos primitivos ou mesmo outras construç�es mais elaboradas (refer�ncias que apontem para outras classes). Data Contracts podem ser empregados tanto como par�metros de entrada em operaç�es de um serviço, quanto como valor a ser devolvido ap�s a execuç�o de tais m�todos.

Para ser considerada um Data Contract, uma classe precisa ter associada � sua definiç�o um atributo DataContractAttribute (namespace System.Runtime.Serialization). Este �ltimo � utilizado para fornecer instruç�es em modo runtime sobre como a serializaç�o de um objeto ocorrer�.

� importante fazer ainda uma observaç�o quanto ao uso do tipo DataContractAttribute: por convenç�o dentro da plataforma .NET, nomes de classes que representam atributos terminam com o sufixo Attribute. Instruç�es que envolvam um atributo vinculado a uma estrutura de c�digo dispensam o uso de tal sufixo ao final do nome. Logo, ao se utilizar o atributo DataContractAttribute, emprega-se apenas �DataContract� na construç�o a ser marcada com este elemento.

Com a propriedade Namespace de DataContractAttribute � poss�vel definir uma identificaç�o �nica para um Data Contract: o valor configurado neste item pode ser uma URI (sigla do ingl�s "Uniform Resource Identification", padr�o para definiç�o de endereços na Internet) e, caso o mesmo n�o seja informado, assume-se http://tempuri.org como default. Trata-se de uma boa pr�tica definir um valor para a propriedade Namespace, j� que um identificador �nico para esta configuraç�o torna poss�vel distinguir um Data Contract de outros utilizados por uma aplicaç�o.

Al�m da pr�pria definiç�o da classe, as propriedades de um Data Contract que ser�o expostas via serviço tamb�m dever�o ter um atributo ligado �s mesmas, fazendo-se uso neste caso do tipo DataMemberAttribute (pertencente ao namespace System.Runtime.Serialization). Atrav�s deste �ltimo � poss�vel definir uma s�rie de caracter�sticas, tais como se � obrigat�ria a exist�ncia de um valor para uma propriedade de um objeto que foi serializado dentro de uma mensagem, se estar� sendo assumido o valor default da propriedade em quest�o quando nenhum valor tiver sido atribu�do a esta, dentre outros aspectos.

Analisando a estrutura da classe DataContract deve-se destacar que, por padr�o, membros de uma classe marcados com DataMember e que n�o tenham a propriedade Order definida s�o ordenados alfabeticamente e serializados, tomando como base para isto seus nomes correspondentes. Na sequ�ncia, elementos marcados com DataMember e com a propriedade Order configurada s�o serializados, respeitando-se a ordem num�rica de tais itens.

As propriedades Aplicacao (nome da aplicaç�o que originou o registro em log) e Mensagem (descriç�o do evento que o registro de log representa) foram marcadas com o atributo DataMemberAttribute. Isto aconteceu, justamente, devido ao fato de que tais propriedades dever�o ser preenchidas (nos prov�veis sistemas que consumiriam o serviço WCF que se est� implementando aqui).

J� as propriedades DataOcorrencia (data/hora em que se cadastrou o registro de log) e TipoOcorrencia (indicaç�o do tipo de informaç�o representada por um registro: erro, alerta ou ainda, um evento qualquer dentro de uma aplicaç�o-cliente) n�o foram marcadas com DataMemberAttribute. Tais propriedades s�o utilizadas apenas para efeitos de acesso � base de dados via ADO.NET, n�o precisando ser preenchidas por poss�veis consumidores do serviço que est� sendo implementado. Logo, n�o constar�o em objetos serializados que ir�o constituir as mensagens enviadas ao serviço WCF de exemplo.

Por fim, um �ltimo ponto merece ser ressaltado a respeito do Data Contract definido dentro do projeto TesteWCF_TCP.DataContracts: o tipo Log foi implementado de maneira a permitir que fosse exposto tanto via serviço WCF, quanto utilizado para a manipulaç�o de dados atrav�s das classes do ADO.NET. Com este artif�cio foi poss�vel obter uma maior reusabilidade no que se refere ao uso da classe Log.

Na Listagem 2 est� a definiç�o da classe LogRepository. Esta �ltima faz parte da Class Library TesteWCF_TCP.Repository, sendo respons�vel pela gravaç�o de registros de log em uma tabela de nome TB_LOG (a estrutura correspondente � apresentada na Listagem 3). A fim de cumprir tal objetivo, o tipo LogRepository emprega dentro do m�todo IncluirRegistroLog recursos disponibilizados pelo ADO.NET:

A partir da vari�vel �conex�o� (inst�ncia do tipo SqlConnection) � estabelecida uma conex�o com a base de dados em que ocorre a persist�ncia das informaç�es (empregando para isto uma string de conex�o chamada �TesteWCF_TCP�);
A refer�ncia de nome �comando� (objeto do tipo SqlCommand) representa a instruç�o SQL que far� a inclus�o de um registro no banco de dados;
Os dados para a execuç�o do comando INSERT s�o obtidos a partir da refer�ncia �log�, a qual foi informada como par�metro ao se invocar a operaç�o IncluirRegistroLog;
As chamadas ao m�todo Add da propriedade Parameters de �comando� permitem associar os valores do objeto �log� aos par�metros equivalentes do comando de inclus�o.

Listagem 2: Classe LogRepository


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Data;
using System.Data.SqlClient;
using System.Configuration;
using TesteWCF_TCP.DataContracts;

namespace TesteWCF_TCP.Repository
{
    public class LogRepository
    {
        public void IncluirRegistroLog(Log log)
        {
            using (SqlConnection conexao = new SqlConnection(
                ConfigurationManager.ConnectionStrings["TesteWCF_TCP"]
                .ConnectionString))
            {
                SqlCommand cmd = conexao.CreateCommand();
                cmd.CommandText =
                    @"INSERT INTO dbo.TB_LOG
                               (Aplicacao
                               ,Mensagem
                               ,DataOcorrencia
                               ,TipoOcorrencia)
                         VALUES
                               (@APLICACAO
                               ,@MENSAGEM
                               ,@DATAOCORRENCIA
                               ,@TIPOOCORRENCIA)";
                cmd.Parameters.Add("@APLICACAO",
                    SqlDbType.VarChar).Value = log.Aplicacao.Trim();
                cmd.Parameters.Add("@MENSAGEM",
                    SqlDbType.VarChar).Value = log.Mensagem.Trim();
                cmd.Parameters.Add("@DATAOCORRENCIA",
                    SqlDbType.DateTime).Value = log.DataOcorrencia;
                cmd.Parameters.Add("@TIPOOCORRENCIA",
                    SqlDbType.Char).Value = log.TipoOcorrencia;
                    
                conexao.Open();
                cmd.ExecuteNonQuery();
                conexao.Close();
            }
        }
    }
}

Listagem 3: Estrutura da tabela TB_LOG


CREATE TABLE [dbo].[TB_LOG](
	[Id] [int] IDENTITY(1,1) NOT NULL,
	[Aplicacao] [varchar](50) NOT NULL,
	[Mensagem] [varchar](2000) NOT NULL,
	[DataOcorrencia] [datetime] NOT NULL,
	[TipoOcorrencia] [char](3) NOT NULL,
	CONSTRAINT [PK_TB_LOG] PRIMARY KEY ([Id]),
	CONSTRAINT [CK_TB_LOG_TIPO_OCORRENCIA]
		CHECK ([TipoOcorrencia] IN ('ERR', 'ALT', 'EVT'))
)

TesteWCF_TCP.Services � um projeto do tipo Class Library no qual est�o definidos:

A interface ILogUtilityService, a qual corresponde ao contrato que define o serviço de exemplo;
A classe LogUtilityService que implementa as funcionalidades oferecidas pelo serviço de exemplo.

Na interface ILogUtilityService (Listagem 4) est�o declaradas as operaç�es que ser�o expostas atrav�s do serviço WCF abordado neste artigo. ILogUtilityService foi marcada com o atributo ServiceContractAttribute: este � um pr�-requisito para se expor uma interface (ou mesmo uma classe) como um serviço quando se emprega a tecnologia WCF. Al�m disso, toda operaç�o pass�vel de ser invocada por um prov�vel consumidor do serviço dever� ser marcada com o atributo OperationContractAttribute.

Ainda sobre o atributo a utilizaç�o do atributo ServiceContractAttribute, a propriedade Namespace foi preenchida com o intuito de se atribuir uma identificaç�o �nica ao serviço. Trata-se do mesmo procedimento usado anteriormente na definiç�o do Data Contract que representa um registro de log.

Por mais que a tecnologia WCF n�o exija que se utilize uma interface para definir um serviço, o uso de tais estruturas representa uma boa pr�tica, trazendo ainda consigo uma s�rie de benef�cios.

Uma simples classe pode se basear em diversas interfaces, as quais se referem a diferentes contratos de serviços. Al�m disso, a implementaç�o de um serviço pode ser alterada normalmente, sem causar efeitos colaterais aos consumidores do mesmo. Isso � poss�vel em virtude do desenvolvimento ter sido orientado a interfaces. � poss�vel ainda definir mecanismos para versionamento de um serviço, empregando para isto uma interface para cada vers�o que estar� dispon�vel.

Listagem 4: Interface ILogUtilityService


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.ServiceModel;
using TesteWCF_TCP.DataContracts;

namespace TesteWCF_TCP.Services
{
    [ServiceContract(Namespace = "http://TesteWCF_TCP/services/log/")]
    public interface ILogUtilityService
    {
        [OperationContract]
        void RegistrarErro(Log log);
        
        [OperationContract]
        void RegistrarAlerta(Log log);
	
        [OperationContract]
        void RegistrarEvento(Log log);
    }
}

A classe LogUtilityService (Listagem 5) corresponde � implementaç�o do serviço WCF de exemplo. Todos os m�todos definidos na interface IConsultaPendenciasService s�o implementados por este tipo, sendo que os mesmos estar�o dispon�veis para utilizaç�o t�o logo o serviço se encontrar em execuç�o.

Ao se considerar a forma como o tipo LogUtilityService foi estruturado, merece destaque ainda o fato de que este serviço representa um caso de aplicaç�o pr�tica de um pattern SOA conhecido como Utility Service (http://www.soaglossary.com/utility_service.php).

O padr�o Utility Service � utilizado na construç�o de serviços respons�veis pela disponibilizaç�o de funç�es gen�ricas, n�o relacionadas diretamente a regras de neg�cio de um sistema. Bons exemplos disto s�o componentes que encapsulam mecanismos de log, envio de notificaç�es por e-mail, dentre outras funcionalidades que podem vir a ser consumidas por mais de uma aplicaç�o-cliente.

Listagem 5: Classe LogUtilityService


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.ServiceModel;
using TesteWCF_TCP.DataContracts;
using TesteWCF_TCP.Repository;

namespace TesteWCF_TCP.Services
{
    [ServiceBehavior(Namespace = "http://TesteWCF_TCP/services/log/")]
    public class LogUtilityService : ILogUtilityService
    {
        private void ProcessarRegistro(Log log, string tipoOcorrencia)
        {
            if (String.IsNullOrWhiteSpace(log.Aplicacao))
            {
                throw new FaultException(
                    "� obrigat�rio informar o nome da aplicaç�o.");
            }

            if (String.IsNullOrWhiteSpace(log.Mensagem))
            {
                throw new FaultException(
                    "� obrigat�rio informar a mensagem de log.");
            }

            log.DataOcorrencia = DateTime.Now;
            log.TipoOcorrencia = tipoOcorrencia;
            new LogRepository().IncluirRegistroLog(log);
        }

        public void RegistrarErro(Log log)
        {
            ProcessarRegistro(log, "ERR");
        }

        public void RegistrarAlerta(Log log)
        {
            ProcessarRegistro(log, "ALT");
        }

        public void RegistrarEvento(Log log)
        {
            ProcessarRegistro(log, "EVT");
        }
    }
}

No c�digo-fonte em que est� a implementaç�o do tipo LogUtilityService � poss�vel notar:

O uso do atributo ServiceBehaviorAttribute. Esta construç�o permite especificar comportamentos para um serviço, sendo que neste �ltimo caso foi configurado o namespace que identifica o mesmo (atrav�s da propriedade tamb�m chamada Namespace);
As operaç�es RegistrarErro, RegistrarAlerta e RegistrarEvento recebem como par�metro uma inst�ncia da classe Log, acionando quando invocadas o m�todo privado ProcessarRegistro. A este �ltimo s�o repassados como par�metros o objeto do tipo Log, bem como o tipo de ocorr�ncia que pode ser um erro (�ERR�), um alerta (�ALT�) ou ainda, um evento gen�rico (�EVT�);
Quanto � codificaç�o do m�todo ProcessarRegistro, o mesmo verifica se o nome da aplicaç�o que originou a mensagem e o conte�do desta est�o preenchidos; em caso negativo, uma exceç�o � lançada atrav�s de uma inst�ncia da classe FaultException (tipo de exceç�o comumente empregado em aplicaç�es WCF). Al�m disso, a operaç�o ProcessarRegistro acessa a camada de dados a fim de incluir um novo registro, sendo que este procedimento acontece atrav�s da invocaç�o do m�todo IncluirRegistroLog a partir de uma inst�ncia do tipo LogRepository.

Uma �ltima observaç�o precisa ser feita a respeito de ProcessarRegistro: por mais que esta m�todo fosse p�blico, o mesmo n�o seria exposto aos consumidores do serviço, uma vez que n�o foi marcado com o atributo OperationContractAttribute.

O serviço a partir do qual ser�o testados os conceitos aqui abordados ser� acionado atrav�s da Console Application TesteWCF_TCP.Hosting.

A Listagem 6 apresenta o arquivo app.config, o qual cont�m as configuraç�es que permitem que o serviço WCF seja acessado via padr�o TCP.

Listagem 6: Arquivo app.config da aplicaç�o TesteWCF_TCP.Hosting


<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <connectionStrings>
    <add name="TesteWCF_TCP"
         providerName="System.Data.SqlClient"
         connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=TesteWCF_TCP;Integrated Security=True;MultipleActiveResultSets=True;"/>
  </connectionStrings>
  <system.serviceModel>
    <services>
      <service behaviorConfiguration="TesteWCF_TCP.LogUtilityServiceBehavior"
        name="TesteWCF_TCP.Services.LogUtilityService">
        <endpoint address="" binding="netTcpBinding" 
          bindingConfiguration=""
          contract="TesteWCF_TCP.Services.ILogUtilityService">
        </endpoint>
        <endpoint address="mex" binding="mexTcpBinding" 
          bindingConfiguration=""
          contract="IMetadataExchange" />
        <host>
          <baseAddresses>
            <add baseAddress="net.tcp://localhost:7123/LogUtilityService" />
          </baseAddresses>
        </host>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="TesteWCF_TCP.LogUtilityServiceBehavior">
          <serviceMetadata httpGetEnabled="false" />
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>
</configuration>

A ConnectionString TesteWCF_TCP definida no arquivo de configuraç�o aponta para o banco de dados utilizado pela soluç�o aqui demonstrada, servindo de base para a gravaç�o de informaç�es de log a partir da camada de acesso a dados.

A configuraç�o de um serviço acontece dentro de um elemento chamado "service", o qual pertence ao agrupamento "services" da seç�o "system.serviceModel".

Dentro do elemento baseAddresses foi definido um endereço-base para o acesso ao serviço, j� considerando inclusive que o processo de comunicaç�o acontecer� atrav�s do protocolo TCP/IP (o endereço em quest�o � iniciado com �net.tcp�).

Em seguida, especificou-se o computador que atua como servidor (por ser um teste, foi utilizado o computador local, ou seja, �localhost�): tanto o nome quanto um endereço de IP s�o v�lidos nestas situaç�es. Al�m disso, � obrigat�rio indicar ainda a porta em que se estabelecer� a comunicaç�o (�7123� era uma porta dispon�vel no momento em que constru� esta aplicaç�o, sendo que isto pode variar de um computador para outro).

O primeiro endpoint definido neste exemplo n�o teve seu atributo address preenchido. Por convenç�o, assume-se que este ser� o endpoint default para acesso ao serviço WCF. Al�m disso, foi definido o uso do binding netTcpBinding, garantindo com isso que a comunicaç�o entre a soluç�o WCF e aplicaç�es-cliente aconteça via protocolo TCP.

H� ainda um segundo endpoint que foi criado para esta aplicaç�o de exemplo, com tal item utilizando a interface IMetadataExchange (namespace System.ServiceModel.Description) como contrato. Essa refer�ncia emprega o binding mexTcpBinding, retornando informaç�es de metadata relativas ao serviço em quest�o: trata-se de uma pr�tica em conformidade com a especificaç�o WS-MetadataExchange (WS-MEX), a qual estabelece regras para que aplicaç�es consumidoras consigam determinar a estrutura de um serviço remoto. O endereço deste endpoint ser� obtido concatenando-se a string indicada em �baseAddresses�, juntamente com o valor �mex� (valor este que foi especificado no atributo address do elemento endpoint).

J� o agrupamento �behaviors� representa o ponto em que s�o especificados, basicamente, os diferentes comportamentos poss�veis para os serviços de uma aplicaç�o: cada um destes componentes contar�, normalmente, com um elemento de nome �behavior�.

O item �behavior� (cuja identificaç�o consta no atributo �name�) corresponde ao comportamento indicado no atributo "behaviorConfiguration" do elemento �servisse�. Sobre �behavior�, � importante frisar os seguintes aspectos:

O atributo httpGetEnabled de serviceMetadata marcado como true indica que consumidores poder�o obter o WSDL do Web Service via requisiç�es HTTP do tipo GET. N�o � este o caso, uma vez que o serviço implementado se baseia no protocolo TCP. O padr�o WSDL (Web Services Description Language) � utilizado para expor os diferentes contratos de um Web Service em um formato padronizado, utilizando para isto um endereço espec�fico;
O atributo �includeExceptionDetailInFaults� do elemento �serviceDebug� define se detalhes de exceç�es ser�o retornados para consumidores do serviço. Para efeitos de depuraç�o, este item pode ser configurado como �true� durante o desenvolvimento; no entanto, recomenda-se que n�o se adote tal comportamento para serviços WCF em ambiente de produç�o.

Apesar de grande parte da configuraç�o do serviço de log ter sido feita em um arquivo XML, a tecnologia WCF tamb�m oferece suporte para se efetuar estes mesmos procedimentos no c�digo-fonte. Como sempre, a escolha da melhor alternativa depender� do contexto e de requisitos que s�o espec�ficos de cada projeto.

A definiç�o de configuraç�es em um arquivo XML apresenta, em muitos casos, uma s�rie de vantagens. Isto � mais do que percept�vel ao se considerar a flexibilidade em se alterar apenas um arquivo, descartando com isto a necessidade de recompilar toda uma aplicaç�o.

Na Listagem 7 est� definida a classe Program, por meio da qual o serviço para gravaç�o de informaç�es em log ser� iniciado. Atrav�s da criaç�o de uma inst�ncia da classe ServiceHost e da invocaç�o do m�todo Open sobre a mesma, o Web Service ser� ativado. Este processo buscou simplificar o procedimento de inicializaç�o do serviço para testes, dispensando-se assim a necessidade de publicaç�o do mesmo num servidor IIS (Internet Information Services) ou, ainda, sua implantaç�o a partir de um Windows Service.

Listagem 7: Classe Program


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.ServiceModel;
using TesteWCF_TCP.Services;

namespace TesteWCF_TCP.Hosting
{
    class Program
    {
        static void Main(string[] args)
        {
            using (ServiceHost host =
                new ServiceHost(typeof(LogUtilityService)))
            {
                host.Open();

                Console.WriteLine(
                    "Serviço iniciado com sucesso!");
                Console.WriteLine(
                    "Pressione qualquer tecla para encerrar a aplicaç�o...");
                Console.ReadKey();

                host.Close();
            }
        }
    }
}

Ao t�rmino da implementaç�o das diferentes estruturas aqui apresentadas, a aplicaç�o de exemplo possuir� uma estrutura bastante similar � da soluç�o da Figura 1.

Figura 1: Solution ao t�rmino da implementaç�o dos diferentes projetos

Executando a aplicaç�o TesteWCF_TCP.Hosting por meio do Visual Studio, o Firewall do Windows poder� exibir um alerta semelhante ao que consta na Figura 2. Se tal mensagem realmente aparecer em tela, faz-se necess�rio ent�o selecionar a opç�o �Permitir Acesso�.

Figura 2: Liberando o acesso � aplicaç�o WCF via Firewall do Windows

Na sequ�ncia a isto, ser� exibida uma tela id�ntica � que consta na Figura 3. Enquanto esta janela permanecer aberta, o serviço em quest�o estar� dispon�vel para utilizaç�o.

Figura 3: Aplicaç�o WCF em execuç�o

Consumindo o serviço de exemplo

Para se testar a aplicaç�o WCF implementada na seç�o anterior, ser� necess�rio primeiramente criar uma refer�ncia para o serviço de testes chamada TesteWCF_TCP. Dentro do Visual Studio, isto pode ser feito a partir da janela Solution Explorer, devendo-se clicar com o bot�o direito do mouse sobre o item "Service References" de um projeto e selecionando a opç�o "Add Service Reference..." (conforme indicado na Figura 4).

Figura 4: Adicionando uma refer�ncia a um serviço num projeto de testes

Neste momento aparecer� uma tela como a que consta na Figura 5. Informar no campo �Address� o seguinte endereço (considerando neste caso o endpoint baseado no binding mexTcpBinding): net.tcp://localhost:7123/LogUtilityService/mex

J� no campo �Namespace� deve ser especificado o namespace a que pertencer�o os diferentes tipos que constituem a refer�ncia que est� adicionando ao projeto (preencher neste caso com o valor �TesteWCF_TCP�).

Figura 5: Criando o arquivo para implementaç�o da classe IMCException

Com a refer�ncia ao serviço criada, j� � poss�vel acessar o mecanismo de log via TCP. A Listagem 8 apresenta um exemplo disto, em que dentro do m�dulo Main que inicializa uma aplicaç�o .NET foi invocada a operaç�o RegistrarEvento da soluç�o WCF aqui demonstrada.

Listagem 8: Consumindo o service WCF


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using TesteConsumoWCF_TCP.TesteWCF_TCP;

namespace TesteConsumoWCF_TCP
{
    class Program
    {
        static void Main(string[] args)
        {
            using (LogUtilityServiceClient client =
                new LogUtilityServiceClient())
            {
                Log log = new Log();
                log.Aplicacao = "TesteConsumoWCF_TCP.exe";
                log.Mensagem = "Carregando a aplicaç�o";
                client.RegistrarErro(log);
            }

            // Outras operaç�es inicializando a aplicaç�o...
            ...

        }
    }
}

Conclus�o

Muitos profissionais cometem um equ�voco ao pressupor que a implementaç�o de serviços WCF est� restrita ao uso do padr�o SOAP. Por mais que muitos projetos utilizando esta tecnologia resultem na construç�o de Web Services baseados em XML, outros protocolos de comunicaç�o podem perfeitamente ser empregados em situaç�es, viabilizando assim a integraç�o entre diferentes sistemas.

Este � justamente o caso do padr�o TCP, opç�o ideal para cen�rios em que ocorrer� o interc�mbio de informaç�es apenas entre aplicaç�es .NET. Quando isto acontecer, o binding netTcpBinding e a serializaç�o bin�ria de objetos podem se revelar como alternativas de melhor performance em uma rede interna, sobretudo se comparados com uma construç�o equivalente que dependa da combinaç�o SOAP/HTTP.

Procurei com este artigo demonstrar novas possibilidades para a tecnologia WCF. Espero que o conte�do aqui abordado possa auxili�-lo em algum momento. At� uma pr�xima oportunidade!

Acessando servi�os WCF via TCP

Criando o serviço WCF de exemplo

Consumindo o serviço de exemplo

Conclus�o

Artigos relacionados