Implementação dos módulos SoS Composer, SoS Manager e SoS Server

O SoS Composer é o responsável em criar os SoS com base nos sistemas candidatos a constituintes armazenados na plataforma. A criação do SoS é realizada pelo desenvolvedor do SoS e é efetuada diretamente na IDE Eclipse.

Para montar um SoS, no entanto, foi necessário instalar um plugin do BPMN na IDE Eclipse, para representar o fluxo baseado em processos de negócio. Esse plugin permite que as missões globais sejam geradas, um diagrama baseado em BPMN seja modelado e um fluxo seja criado. Detalhes sobre o plugin instalado para realizar essas operações estão presentes na Figura 25.

Figura 25: Plugin utilizado na IDE Eclipse para modelar a missão global do SoS

Após a instalação do plugin, uma pequena configuração precisou ser realizada para que ele fosse reconhecido corretamente e apresentasse os componentes necessários ao Mandala. Foi criado um perfil (vide Figura 26) e, associado a este perfil, os componentes do BPMN necessários para modelar a missão global do SoS. Os componentes escolhidos para esta versão do Mandala foram Start Event, End Event, Base Element e Sequence Flow.

Quando o perfil do Mandala é criado na ferramenta de modelagem e os sistemas candidatos a constituintes começam a ser cadastrados, ao abrir, no Eclipse IDE, uma tela para edição de um diagrama BPD, que é baseado em BPMN, tanto os sistemas quanto as funcionalidades ou tarefas cadastradas no formulário, estarão disponíveis para que o desenvolvedor do SoS possa realizar a associação de sistemas e funcionalidades ao SoS e montar a sua missão global. A Figura 27 apresenta esta situação.

Feita a associação dos sistemas candidatos (a partir de agora podem ser considerados constituintes de um SoS), um arquivo XML, fruto do modelo recém-criado, é gerado e

Figura 26: Criação do perfil do Mandala na ferramenta de modelagem baseada em BPMN

Figura 27: Criação de um diagrama BPD relativo a uma missão global de um SoS

para que seja entendível pelo Mandala, este arquivo precisa ser traduzido para objetos JAVA.

A conversão dos dados inseridos no arquivo XML para objetos JAVA é realizada por uma biblioteca baseada na convenção DOM (do termo em inglês, Document Object Model ). A Figura 28 apresenta detalhes dessa biblioteca. Uma vez convertidos, estes objetos JAVA são armazenados no repositório do SoS Manager.

O SoS Server, no atual estágio do Mandala, responde, além da função de armazena- mento das informações de metadados dos sistemas constituintes e dos SoS gerados, pelas funções de divulgação aos Broker relativos aos sistemas constituintes e pela solicitação de publicação do serviço Web gerado para o SoS.

Quando o SoS é criado (ou editado) e o SoS Manager recebe a solicitação de gravação dos dados em seu repositório, este componente automaticamente entende que precisa divulgar as informações aos Broker participantes, como também solicitar ao SoS Server a publicação do serviço Web relativo ao SoS. A Figura 29 mostra detalhes do código

Figura 28: Utilização da Biblioteca DOM para Modelagem do arquivo XML

implementado para executar a função de divulgação.

Como reforço, cabe lembrar que a comunicação entre o SoS Manager e o Broker é baseada no envio de mensagens entre agentes de software.

Para a publicação do serviço Web relativo ao SoS, uma classe, em JAVA, pertencente ao SoS Server é editada e executada com o nome do serviço que se deseja publicar (vide Figura 30). Para fins de registro, como esta classe é editada pelo desenvolvedor do SoS, no momento da criação do SoS, não houve a preocupação em desenvolver uma interface gráfica para tal. Após a publicação, o serviço estará disponível para acesso pelos clien- tes, bastando requisitá-lo, informando o endereço e o verbo HTTP (GET, POST, PUT, DELETE) disponível. No caso do serviço apresentado na Figura 31, o acesso ocorre via solicitação GET.

Quando o serviço Web é requisitado e a requisição chega ao SoS Server, para que o agente do SoS possa se comunicar com os agente do Broker, informando que o SoS deve ser executado, é necessário que esta solicitação seja traduzida para uma linguagem entendível

Figura 29: Divulgação aos Broker participantes sobre a criação do SoS

pelo agente. Por causa disso, há um módulo, denominado JADEGateway, que tem como função traduzir algo não reconhecido pelo agente para algo entendível pelo agente.

O JADEGateway faz a criação de um agente temporário para cada requisição que chega ao SoS. Isto ocorre para que seja possível o agente do SoS receber a requisição e dar início ao processo de execução do SoS.

Para finalizar todo o processo de criação, divulgação e acesso ao SoS dentro do Man- dala, no contexto da implementação, a Figura 32 apresenta trecho do código de chamada ao Broker que executa o primeiro passo do fluxo de execução do SoS.

Figura 30: Classe editada para a publicação do serviço Web

Figura 31: Serviço Web publicado para acesso pelos clientes

Figura 32: Código que apresenta quando a mensagem de solicitação de execução do SoS é enviada ao Broker responsável pela execução do primeiro passo do fluxo.

4

Avaliação

A necessidade de integração que os sistemas possuem para poderem gerar novos be- nefícios, inalcançáveis quando estes sistemas trabalham de forma isolada, é a grande mo- tivação para o SoS. Contudo, para criar SoS, algumas premissas precisam ser seguidas. Estas premissas, bem detalhadas no Capítulo 2, são os diferenciais entre a integração dos sistemas tradicionais e um SoS. Nesse contexto, visando verificar a capacidade que o Mandala tem de integrar os sistemas com base nas premissas definidas para um SoS, este capitulo objetiva validar a plataforma utilizando um estudo de caso, em forma de provas de conceito(JR.; CHEN; PURDIN, 1990). Um estudo de caso é um método empírico explo- ratório planejado para investigar fenômenos em um ambiente natural usando múltiplas fontes de evidência (YIN, 2017)(ROBSON; McCartan, 2016).

Dadas as características de dinamismo, distribuição geográfica e independência, tanto funcional quanto gerencial, além da grande heterogeneidade dos seus sistemas e do objetivo permanente do provimento de benefícios aos seus cidadãos, o ambiente ideal, perfeito e plausível para a utilização de SoS, e, por conseguinte, para a validação do Mandala, é o de cidades inteligentes.

Porém, alguns pontos merecem ressalvas quanto a esta validação:

• O número de cidades inteligentes no Brasil ainda é escasso e a cidade do Natal ainda não se enquadra nesta categoria;

• É difícil encontrar sistemas em produção disponíveis para a montagem de um SoS;

• Por ser uma área em desenvolvimento, é raro encontrar desenvolvedores de SoS para utilizarem o Mandala e informarem sobre a sua visão sobre os testes.

Diante deste quadro, o estudo de caso é referente a dois SoS desenvolvidos especifi- camente para este fim, não sendo, portanto, sistemas em produção ou de alguma cidade inteligente conhecida.