O MB_Core pesquisa o ficheiro procurando os nós existentes em “/configurations/localProcess/.” e lançando num novo processo o executável indicado pelo atributo exeFile.
Para lançar mais do que uma instância de um módulo (apenas para os módulos que o suportem) basta repetir o elemento correspondente ao módulo. No exemplo exposto, serão lançadas duas instâncias do módulo Router e apenas uma dos restantes módulos. É da responsabilidade do administrador do sistema garantir que pelo menos uma instância de cada módulo é lançada.
O ficheiro MBconfig contém ainda a connection string que utilizada para aceder à base de dados.
4.3 Módulo Input/Output
O módulo de Input/Output (I/O) é o ponto de entrada e saída de mensagens no bus. Conforme exposto na Figura 27, a implementação do módulo I/O divide-se em duas partes – Receiver e Dispatcher. O Receiver processa as mensagens que dão entrada no bus através de um dos múltiplos protocolos de comunicação suportados. Um aspecto
comum a todos os protocolos de comunicação é o de, directa ou indirectamente, assentarem a sua comunicação em WCF.
O bus de mensagens define duas interfaces distintas às quais correspondem dois serviços, cabendo às implementações de protocolos de comunicação optar por usar um deles. As funcionalidades oferecidas por cada um dos serviços são semelhantes, apenas diferindo no modo de comunicação (channel shape) – One Way num dos serviços e Duplex no outro. A Figura 32 representa o diagrama de classes das interfaces e classes que compõem ambos os serviços.
Figura 32: Diagrama de classes do serviço WCF
Na Figura 32 a) todas as comunicações entre cliente e bus de mensagens são one- way. O cliente terá ele próprio de implementar uma componente servidora que implemente a interface IMessageBusClient. Nessa interface existe o método deliverMessage que servirá para o servidor comunicar com o cliente, tanto para entregar mensagens de dados, como repostas a comandos que o cliente tenha executado.
A Figura 32 b) representa as classes que implementam a mesma funcionalidade mas com comunicação duplex. Através de atributo ServiceContract aplicado à interface IMessageBusDuplex, indica-se que IClientCallBack é a interface que o servidor dispõe para comunicar com o cliente. Desta forma, em qualquer ponto na implementação do servidor podem ser invocados os métodos de IClientCallBack.
Em ambos os casos, sempre que o cliente pretender enviar uma mensagem (de dados ou um comando) para o servidor, é utilizado o método sendMessage. O método sendMessage verifica se a mensagem é um comando do tipo AddUser e apenas em
caso negativo é que a mensagem é colocada na fila incomingQueue, ficando então disponível para ser processada pelo bus. No caso de se tratar de um comando AddUser, a sua execução é feita logo no momento por ser necessário travar o processamento caso o nome de utilizador pedido já existir.
4.3.1 Receiver
A função do Receiver é recolher as mensagens da incomingQueue, formata-las e coloca-las na fila outputQueue. As mensagens que entrarem em incomingQueue já se encontram formatadas no formato interno do bus. Ao longo da passagem pelos vários módulos do sistema, serão acrescentados vários cabeçalhos SOAP à mensagem. A formatação referida por parte de Receiver consiste em limpar da mensagem todos esses cabeçalhos, evitando assim que algum cliente tente voluntariamente interferir com o normal funcionamento do bus.
O Receiver constituiu o núcleo do módulo I/O e é implementado pela classe MessageBusReceiver que estende de MBusModule. Não se permitem várias instâncias deste módulo pelo facto do processo que executa o módulo I/O incluir também a implementação dos protocolos de comunicação. Vários tipos de ligação (por exemplo TCP/IP utilizado pelo AMQP) não permitem que exista mais do que um servidor na mesma máquina.
4.3.2 Dispatcher
Quando as mensagens estão prontas para entregar ao destino final são colocadas na fila dispatchQueue. O dispatcher é responsável por ler as mensagens dessa fila, fazer o mapeamento entre o endereço virtual e físico do destino e finalmente entregar a mensagem ao cliente final de acordo com o protocolo que este utilizar (tendo em conta se o protocolo do cliente utiliza um serviço duplex ou one-way).
Na Figura 33 observa-se o diagrama de classes do tipo Dispatcher, que realiza os passos atrás descritos.
Figura 33: Diagrama de classes da implementação do dispatcher
O Dispatcher contém internamente:
Informação sobre o modo de funcionamento de cada protocolo de comunicação (campo protocolsInfo);
Referências para os objectos callback de clientes que utilizem o serviço duplex (callbackObjects);
Informação da disponibilidade de cada cliente para receber mensagens (clientAvailability);
Conjunto de mensagens que ainda não estão entregues ou porque a primeira tentativa de envio falhou ou porque o cliente não estava
receptivo (notDeliveredMessages e
_directContractPendingMsg);
Mecanismos que permitem saber a que cliente deve ser entregue determinada resposta a um comando (replyUri e replyCallback).
As entregas a clientes com protocolos baseados no serviço one-way são suportadas por objectos do tipo DispatcherItem. Este objecto estabelece uma ligação com a aplicação cliente (na qual é o bus de mensagens que se comporta como cliente) e procede ao envio da mensagem. Caso o envio falhe, existe um campo do tipo Timer que dispara eventos em intervalos de tempo configuráveis para que seja tentado o reenvio.
4.3.3 Comandos
O módulo I/O é responsável pela execução de três tipos de comandos: GetMessage;
GetUserMessagesList; SetEndPointState.
Para todos os comandos, o responsável pela sua execução é o Receiver (embora durante a execução invoque métodos do Dispatcher).
4.4 Protocolos de comunicação
Na implementação fornecida do bus de mensagens são suportados três protocolos de comunicação – MB Protocol, AMQP e RestMs. Novos protocolos podem ser implementados enviando para o binding netNamedPipeBinding mensagens com o formato de MB Protocol. Este binding está associado à interface do serviço duplex atrás exposta.
O bus de mensagens necessita de um conjunto de informações acerca do modo de funcionamento de cada protocolo de comunicação. Essa informação é fornecida através do ficheiro de configuração MessagingProtocolsDescriptor.xml que é disponibilizado na mesma máquina onde for executado o módulo I/O. A Listagem 4 mostra um exemplo do conteúdo deste ficheiro.
<MessagingProtocols> <amqp clientInteraction="CallbackContract" clientDeliveryMode="Passive" protocolScheme="amqp"/> <RestMS clientInteraction="CallbackContract" clientDeliveryMode="Active" protocolScheme="rm"/> <MessageBusProtocol clientInteraction="directContract" clientDeliveryMode="passive" protocolScheme="mb"/> </MessagingProtocols>