Há algum tempo eu mostrei neste artigo como podemos fazer o uso do Message Queue com WCF, e lá foi discutido todos os benefícios de se envolver uma fila na comunicação entre as duas partes. A exigência daquele modelo de utilização é que ambos os lados precisam utilizar a API do WCF para se comunicar com o Message Queue.
O problema é que as vezes já temos uma solução implementada e operante. Antes do WCF, a única forma que tínhamos para interagir com o Message Queue na plataforma .NET era através das classes contidas no assembly System.Messaging.dll. Além disso há outras soluções que recebem ou enviam mensagens para uma fila, escritas em outras tecnologias.
Para trabalhar com Message Queue no WCF, temos dois bindings: NetMsmqBinding e MsmqIntegrationBinding, onde o primeiro deles já foi esgotado naquele outro artigo. O segundo trata-se de um binding criado exclusivamente para interagir com filas em que as mensagens sejam postadas ou recebidas por outras tecnologias que não o WCF. A finalidade deste artigo é mostrar como proceder para utilizar este binding e interoperar com soluções que já estão em funcionamento.
Para exemplificar vamos interoperar com aplicativos que recebem e postam mensagens utilizando a API System.Messaging.dll, que existe desde a primeira versão do .NET Framework. Abaixo temos dois cenários distintos, separados em duas pastas: WCFNoCliente e WCFNoServidor. No primeiro cenário utilizaremos o WCF para enviar uma mensagem para a fila e o serviço irá extrair a mensagem de lá utilizando as classes contidas no assembly System.Messaging.dll. No segundo cenário, será o inverso, ou seja, utilizaremos as classes contidas no assembly System.Messaging.dll para enviar a mensagem, e utilizaremos o WCF no serviço para extrair a mensagem da fila e processá-la. A imagem abaixo ilustra a estrutura dos projetos de teste:
O primeiro passo é desenhar o contrato do serviço, que irá formalizar a comunicação. A ideia será ter um serviço que processa pedidos de algum comércio eletrônico. Sendo assim teremos duas classes: Pedido e Cliente, que são autoexplicativas. Cada uma delas tem propriedades que as descrevem, que também não precisam ser exibidas aqui. Uma característica de serviços que são expostos através do Message Queue, é que as operações eles devem ser sempre one-way, assim como já foi discutido anteriormente. Abaixo temos a definição do contrato que será utilizado como exemplo:
[ServiceContract]
[ServiceKnownType(typeof(Pedido))]
[ServiceKnownType(typeof(Cliente))]
public interface IComercioEletronico
{
[OperationContract(IsOneWay = true, Action = “*”)]
void AdicionarPedido(MsmqMessage<Pedido> mensagem);
}
Infelizmente por se tratar de um cenário específico, a nossa operação deverá ter apenas um único parâmetro, e ele deve ser do tipo MsmqMessage<T>, que está debaixo do namespace System.ServiceModel.MsmqIntegration, e representará o body da mensagem. Caso você precise de mais parâmetros, então o correto é que você inclua isso em uma mesma classe e a defina como o parâmetro genérico T da classe MsmqMessage<T>. É importante dizer que o contrato irá definir a estrutura da mensagem a ser enviada para a fila (WCFNoCliente) ou a mensagem a ser extraída da fila (WCFNoServidor).
um detalhe importante na criação do contrato é o uso do atributo ServiceKnownTypeAttribute, que é exigido para todos os elementos mencionados direta ou indiretamente no contrato. Isso é necessário para que o serializador conheça todos os tipos envolvidos, caso contrário, a mensagem não será recebida pelo WCF, e ao ligar o tracing, vamos nos deparar com a seguinte mensagem de erro:
System.ServiceModel.ProtocolException: An error was encountered while deserializing the message. The message cannot be received. —> System.Runtime.Serialization.SerializationException: An error occurred while deserializing an MSMQ message’s XML body. The message cannot be received. Ensure that the service contract is decorated with appropriate [ServiceKnownType] attributes or the TargetSerializationTypes property is set on the MsmqIntegrationBindingElement.
Utilizando o WCF no Servidor
Como será um serviço WCF que irá extrair as mensagens da fila, o primeiro passo aqui é a implementação do contrato na classe que representará o serviço. Aqui tudo é muito parecido com um serviço WCF tradicional, mas com uma pequena diferença que está na operação. Como a classe MsmqMessage<T> representa a mensagem que está dentro da fila, ela é muito mais do que a instância da classe Pedido, ou seja, temos outras propriedades que estão relacionadas ao protocolo.
Entre as várias propriedades expostas pela classe MsmqMessage<T> temos a propriedade Body, que retorna um object que representa a instância da classe que foi serializada no corpo da mensagem pelo cliente, que no nosso caso é a classe Pedido. Abaixo temos a implementação do serviço com o processamento da mensagem:
public class ServicoDeComercioEletronico : IComercioEletronico
{
[OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)]
public void AdicionarPedido(MsmqMessage<Pedido> mensagem)
{
Pedido pedido = mensagem.Body as Pedido;
if (pedido != null)
{
Console.WriteLine(“—- Processando o Pedido: {0}”, pedido.Codigo);
Console.WriteLine(“—- Cliente: {0}”, pedido.Cliente);
Console.WriteLine(“—- Valor: {0:N2}”, pedido.ValorTotal);
Console.WriteLine(“—- Data: {0:dd/MM/yyyy HH:mm}”, pedido.Data);
Console.WriteLine();
}
}
}
Note que decoramos a operação com o atributo OperationBehaviorAttribute definindo as propriedades TransactionScopeRequired e TransactionAutoComplete para True, pois utilizando o binding MsmqIntegrationBinding não temos o controle explícito das transações, que para isso exige que o binding suporte sessões, e não é o caso do MsmqIntegrationBinding.
Depois da implementação definida, agora chega o momento de configurar o serviço. Como já sabemos, vamos recorrer ao binding MsmqIntegrationBinding. Para uma fácil interoperabilidade, o endereço em que o serviço é exposto deve utilizar o scheme msmq.formatname ao invés do net.msmq, que permite entre vários modelos, o acesso direto a fila (através de format-name), sem a necessidade de contatar o Active Directory (AD). Abaixo temos a configuração declarativa do serviço:
<system.serviceModel>
<services>
<service name=”Servico.ServicoDeComercioEletronico”>
<endpoint address=”msmq.formatname:DIRECT=OS:.private$MinhaFila”
binding=”msmqIntegrationBinding”
bindingConfiguration=”bindingConfig”
contract=”Biblioteca.IComercioEletronico” />
</service>
</services>
<bindings>
<msmqIntegrationBinding>
<binding name=”bindingConfig”>
<security mode=”None” />
</binding>
</msmqIntegrationBinding>
</bindings>
</system.serviceModel>
Com o serviço criado, podemos agora inicializarmos a criação do cliente. Obviamente que não iremos referenciar o serviço, mesmo porque nem criamos o endpoint que expõe o documento WSDL. A ideia aqui será utilizar os tipos que estão dentro do assembly System.Messaging.dll para enviar a instância da classe Pedido para a fila, e utilizar o WCF do outro lado para processar.
Depois do assembly referenciado na aplicação, instanciamos a classe MessageQueue e informamos o caminho para a fila (via path-name). Depois instanciamos a classe Pedido e a configuramos com os dados do Pedido que foi realizado e, finalmente, enviamos a instância para a fila através do método Send. Neste momento, a instância da classe Pedido será serializada como o body da mensagem.
using (MessageQueue queue = new MessageQueue(@”.private$MinhaFila”))
{
Pedido pedido = new Pedido();
pedido.Codigo = 123;
pedido.Data = DateTime.Now;
pedido.ValorTotal = 1983.81M;
pedido.Cliente = new Cliente() { Codigo = 39, Nome = “Israel Aece” };
queue.Send(pedido, MessageQueueTransactionType.Single);
Console.WriteLine(“Mensagem Enviada com Sucesso.”);
}
Observação: Como a fila é transacionada, precisamos definir o tipo da transação a ser utilizada pelo Message Queue no momento do envio da mensagem. Se o controle da transação está sendo controlada por um elemento externo, como é o caso do TransactionScope, então é necessário definir o MessageQueueTransactionType para Automatic, para que o envio da mensagem possa participar da mesma transação, criada previamente.
Utilizando o WCF no Cliente
Neste cenário inverteremos as tecnologias que utilizamos. Agora no serviço utilizaremos os tipos do assembly System.Messaging.dll e no cliente o WCF. Aqui criaremos a instância da classe MessageQueue com a finalidade de extrair a mensagem que lá foi postada, enviada por um cliente que utiliza o WCF. E para isso utilizaremos o método Receive, que da mesma forma que o método Send, também precisa estar protegido por uma transação.
O método Receive retorna uma instância da classe Message (namespace System.Messaging), que entre várias propriedades, temos a Body, que retorna um object representando a classe que foi serializada, e que no nosso caso é a classe Pedido. O código abaixo ilustra como fazemos para extrair a mensagem:
using (MessageQueue queue = new MessageQueue(@”.private$MinhaFila”))
{
queue.Formatter =
new XmlMessageFormatter(new Type[] { typeof(Pedido), typeof(Cliente) });
Pedido pedido = queue.Receive(MessageQueueTransactionType.Single).Body as Pedido;
if (pedido != null)
{
Console.WriteLine(“—- Processando o Pedido: {0}”, pedido.Codigo);
Console.WriteLine(“—- Cliente: {0}”, pedido.Cliente);
Console.WriteLine(“—- Valor: {0:N2}”, pedido.ValorTotal);
Console.WriteLine(“—- Data: {0:dd/MM/yyyy HH:mm}”, pedido.Data);
Console.WriteLine();
}
}
Da mesma forma que fizemos acima com o contrato do WCF, decorando-o com o atributo ServiceKnownTypeAttribute, temos também que mencionar quais sãos os tipos que compõem o body da mensagem que está na fila, e para isso podemos recorrer a instância da classe XmlMessageFormatter, e em seu contrutor informar um array contendo os tipos envolvidos.
Como não há referência do serviço no cliente, precisamos fazer com que o cliente conheça qual é o contrato do serviço, e justamente por isso que ele foi colocado em uma DLL a parte, chamada de Biblioteca. Utilizamos no cliente a classe ChannelFactory<TChannel> para criar a canal de comunicação entre a aplicação cliente e a fila.
Além do contrato, devemos também informar o binding que irá reger a comunicação, e que como sabemos, será o binding MsmqIntegrationBinding. Em seguida informarmos o endereço (format-name) da fila em que a mensagem será postada. Com a factory criada, agora podemos criar a instância do canal que é efetivamente o proxy:
using (ChannelFactory<IComercioEletronico> factory =
new ChannelFactory<IComercioEletronico>(
new MsmqIntegrationBinding(MsmqIntegrationSecurityMode.None),
@”msmq.formatname:DIRECT=OS:.private$MinhaFila”))
{
var proxy = factory.CreateChannel();
Pedido pedido = new Pedido();
pedido.Codigo = 123;
pedido.Data = DateTime.Now;
pedido.ValorTotal = 1983.81M;
pedido.Cliente = new Cliente() { Codigo = 39, Nome = “Israel Aece” };
proxy.AdicionarPedido(new MsmqMessage<Pedido>(pedido));
Console.WriteLine(“Mensagem Enviada com Sucesso.”);
}
Note que depois da instância da classe Pedido criada e configurada, ela não é passada diretamente para o método AdicionarPedido. Como foi comentado acima, o contrato impõe que a classe Pedido seja envolvida por um wrapper (MsmqMessage<T>), que representará a mensagem dentro do fila, e a instância da classe Pedido será armazenada/serializada no body dela.
Assincronismo
Como sabemos, uma das características do uso do Message Queue é garantir o assincronismo, e permitir ao cliente enviar mensagens ao serviço mesmo que ele esteja offline, mascarando assim eventuais problemas que existam na comunicação entre as duas partes envolvidas.
Conclusão: No decorrer deste artigo vimos que podemos substituir a tecnologia que existe de um dos lados para uma tecnologia mais recente, como é o caso do WCF, e com isso tirar todo o proveito de seus recursos, mas tendo em mente que existem algumas poucas limitações e imposições.
UtilizandoMsmqIntegrationBinding.zip (20.48 kb)
Israel Aece 