São três as informações necessárias acerca de cada protocolo de comunicação: ProtocolSchema – consiste num nome único que permite ao bus de
ClientInterection – especifica o modo de interacção com o cliente. São aceites dois valores. “CallBackContract” no caso de o protocolo utilizar a interface duplex do serviço WCF, “directContract” caso o protocolo utilize a interface one-way. No caso de novas implementações, este valor será sempre “CallBackContract”, visto que o binding netNamedPipeBinding está associado à interface duplex.
ClientDeliveryMode – indica de que forma é que as mensagens são entregues aos clientes finais. Se atribuído o valor “Active”, cabe às aplicações cliente verificar junto do bus se existem mensagens para elas. Por outro lado, o valor “passive” indica que as aplicações cliente são de natureza passiva, isto é, cabe ao bus a iniciativa de entregar as mensagens.
As implementações de novos protocolos, antes de enviarem dados para o binding netNamedPipeBinding têm de acrescentar uma nova entrada no ficheiro MessagingProtocolsDescriptor.xml, tendo em atenção que não poderão repetir nenhum dos protocolSheme já existentes.
4.4.1 MB Protocol
O MB Protocol é o protocolo de comunicação criado no contexto deste trabalho e utiliza como formato de dados o SOAP (do qual deriva o formato interno do bus de mensagens). O canal de comunicação utilizado por este protocolo são Web Services, pelo que a comunicação com o bus é feita através de um binding wsHttpBinding associado à interface one-way do serviço. Os clientes MB Protocol têm natureza passiva no que diz respeito à recepção de mensagens.
O MB Protocol prevê a existência de três tipos de mensagens: Mensagens de dados;
Comandos; Respostas.
As mensagens de dados contêm a informação que as aplicações cliente pretendem trocar entre elas. As mensagens de comandos consistem os comandos referidos no capítulo 3.4 e que permitem configurar o funcionamento do bus. A alguns comandos
estão associadas respostas que são enviadas ao utilizador e que compõem o ultimo tipo de mensagens.
Todas as mensagens contêm o elemento <mb:MessageType> no Header do SOAP. Este elemento permite identificar o tipo de mensagem conforme o texto encontrado dentro no seu interior e que pode ser “data”, “command” ou “reply”.
A informação nas mensagens de dados é transportada no campo Body da mensagem SOAP. Dentro desse campo o formato é livre, podendo ser XML ou qualquer outro formato baseado em texto. Se for necessário transportar dados binários, as aplicações deverão incluir o elemento <mb:attachment> dentro do Body onde podem colocar conteúdos codificados em Base64.
O formato (e tipo) dos comandos definidos no MB Protocol está no Anexo 1. Um comando só dará origem a uma resposta caso o cliente inclua no Header o elemento <mb:CorrelationID> cujo texto deverá ter a representação textual de um objecto Guid da plataforma .Net. A mensagem de resposta repetirá o elemento <mb:CorrelationID> para que a aplicação cliente saiba qual o comando a que a resposta se refere.
4.4.2 Advanced Message Queuing Protocol
A implementação do protocolo AMQP foi feita através da criação de um user- defined binding para WCF. Os user-defined binding são utilizados quando nenhum dos bindings fornecidos pelo WCF preenche os requisitos do serviço. Outra alternativa seria criar um custom binding, no entanto, os user-defined bindings têm a vantagem de ser mais facilmente reutilizáveis em vários projectos distintos. [Res08] Desta forma, permite-se que o binding criado seja utilizado por outras implementações de servidores AMQP realizadas fora deste projecto.
Antes de se criar um binding é necessário conhecer o stack do WCF, representado na Figura 34.
Figura 34: Stack de comunicação WCF. Fonte: [JR09]
O stack apresentado na Figura 34 divide-se em duas camadas – channel layer e service layer. A channel layer é responsável pelo envio e recepção de mensagens WCF enquanto a service layer tem a responsabilidade de traduzir essas mensagens nas chamadas aos métodos que implementam determinado serviço. [Sho05]
O binding desenvolvido centra-se exclusivamente na channel layer, pelo que as mensagens WCF ao atingirem a service layer já levam o conteúdo necessário para que seja invocado o serviço disponibilizado pelo bus de mensagens (no caso desta implementação, o serviço MessageBusServerDuplex).
Internamente a channel layer é composta por um elemento de transporte, um elemento de codificação e zero ou mais elementos de protocolo. O elemento de transporte lida com os mecanismos utilizados para mover a mensagem entre o cliente e o servidor (e vice-versa). O elemento de codificação é responsável por codificar/descodificar os dados no formato utilizado pelo transporte em informação interpretável dentro do stack do WCF. Finalmente, os elementos de protocolo destinam- se implementar necessidades específicas de um determinado binding. Essas necessidades incluem aspectos de segurança, gestão de um determinado protocolo, etc.
Os elementos utilizam canais para comunicar com os elementos imediatamente acima e abaixo no stack WCF na Figura 34 podendo esses canais ser de dois tipos – canais de transporte e canais de protocolo. [All07]
Um binding não é mais do que uma colecção de BindingElements onde cada BindingElement consiste num objecto que representa um elemento de transporte,
codificação ou protocolo. O runtime do WCF inspecciona os BindingElements presentes num binding de forma a determinar qual o elemento utilizado para transporte, codificação, etc. Cada BindingElement dispõe de métodos que permitem instanciar o objecto responsável pelas tarefas de codificar, transportar, etc.
A Listagem 5 mostra os passos na criação de um servidor utilizando o objecto ServiceHost. Este objecto automatiza os passos atrás descritos durante a análise de um binding e criação do stack de comunicação para um dado serviço.
ServiceHost host = new ServiceHost(typeof(Service), new Uri("amqp://localhost/")); host.AddServiceEndpoint(typeof(IMessageBusServerDuplex), new AmqpBinding(),
"MessageBus"); host.Open();