Upload
hoangtuyen
View
216
Download
0
Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO
CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA
LUIS AUGUSTO MELO ROHTEN
INTEGRANDO A INTERNET DAS COISAS ÀS APLICAÇÕES:
UMA MODELAGEM DE APLICAÇÃO WSN ORIENTADA A
SERVIÇO E ORQUESTRADA EM BPMN
VITÓRIA
2016
1
LUIS AUGUSTO MELO ROHTEN
INTEGRANDO A INTERNET DAS COISAS ÀS APLICAÇÕES:
UMA MODELAGEM DE APLICAÇÃO WSN ORIENTADA A
SERVIÇO E ORQUESTRADA EM BPMN
VITÓRIA
2016
Monografia apresentada ao curso de Ciência da
Computação do Departamento de Informática da
Universidade Federal do Espírito Santo, como
requisito parcial para obtenção do título de
Bacharel em Ciência da Computação.
Orientador: Prof. Dr. José Gonçalves Pereira Filho
Coorientador: Prof. M.Sc. Sérgio Teixeira
2
LUIS AUGUSTO MELO ROHTEN
INTEGRANDO A INTERNET DAS COISAS ÀS APLICAÇÕES:
UMA MODELAGEM DE APLICAÇÃO WSN ORIENTADA A
SERVIÇO E ORQUESTRADA EM BPMN
COMISSÃO EXAMINADORA
______________________________________
Prof. Dr. José Gonçalves Pereira Filho Departamento de Informática – UFES Orientador
______________________________________
Prof. Sergio Teixeira Departamento de Informática – UFES
Universidade Católica de Brasília - UCB Faculdade Católica Salesiana do Espírito Santo - FCSES
Coorientador
_______________________________________
Prof.ª Dr.ª Roberta Lima Gomes Departamento de Informática – UFES
Vitória, 28 de Janeiro de 2016.
3
Primeiramente gostaria de agradecer a Deus, por ter me
iluminado durante todo o meu caminho. À minha mãe, pai (in
memoriam) e irmã, por toda a orientação, apoio e educação. À
minha linda namorada Julia pela ajuda, paciência e amor. Aos
professores José Gonçalves, Sergio Teixeira e Roquemar
Abaldam pela orientação, apoio e sugestões. Aos meus
amigos próximos e aos amigos do curso de computação da
UFES que me ajudaram percorrer toda à minha caminhada.
4
RESUMO
Um dos grandes desafios para tornar a internet das coisas (Internet of Things ou
IoT) algo mais simples e acessível para quem pretende desenvolver soluções para a
IoT é propor mecanismos que possibilitem identificar e localizar os dispositivos
conectados à rede, abstraindo suas características de baixo nível específicas de
plataforma. Algumas soluções de ambiente corporativo buscam formas de integrar a
IoT aos processos de negócio por meio de aplicações que utilizam linguagens de
alto nível. Esse trabalho propõe um estudo de caso de uma aplicação WSN
orientada a serviços e orquestrada em BPMN.
Palavras-chave: Internet das Coisas, jBPM, BPM, BPMN 2.0, Processos de Negócio,
Arquitetura orientada a Serviço, Web Service Restful.
5
ABSTRACT
A major challenge to make the Internet of Things (IoT) something simpler and
accessible for anyone wishing to develop solutions for the IoT is to propose
mechanisms that enable to identify and locate the devices connected to the network
by abstracting their specific low-level features of the platform. Some corporate
environment solutions seek ways of integrating the IoT to business processes
through applications that use high-level languages. This work presents a case study
of a WSN application-oriented services and orchestrated in BPMN.
Keywords: Internet of Things, jBPM, BPM, BPMN 2.0, Business Process, Service-
oriented Architecture, RESTful Web Service.
6
SUMÁRIO
1 - INTRODUÇÃO..................................................................................................................... 9
1.1 OBJETIVOS ................................................................................................................... 11
1.2 METODOLOGIA ........................................................................................................... 11
1.3 ORGANIZÃO DO TRABALHO ................................................................................... 13
2 – FUNDAMENTAÇÃO TEÓRICA ...................................................................................... 14
2.1 WIRELESS SENSOR NETWORKS ............................................................................. 14
2.2 ABORDAGENS BPM PARA A MODELAGEM DE PROCESSOS DE NEGÓCIOS
INTEGRADAS A IOT ......................................................................................................... 15
2.3 ARQUITETURAS, TECNOLOGIAS E FRAMEWORKS PARA DESENVOLVER
APLICAÇÕES ROA. ........................................................................................................... 21
2.4 FUNDAMENTOS ARQUITETURA E TECNOLOGIAS DO FRAMEWORK JBPM.
.............................................................................................................................................. 22
3 – MODELAGEM DE APLICAÇÕES DE IOT ORIENTADAS A SERVIÇOS,
ORQUESTRADAS EM BPMN COM USO DO JBPM .......................................................... 26
3.1 INSTALAÇÃO DA FERRAMENTA JBPM E SUAS DEPENDÊNCIAS ................... 28
3.2 CRIANDO UM PROJETO JBPM ................................................................................. 30
3.3 MODELANDO UM PROCESSO DE NEGÓCIO NO BPMN2 DIAGRAM EDITOR 31
3.4 CRIANDO A CLASSE PRINCIPAL DE UMA APLICAÇÃO JBPM ......................... 31
3.5 REALIZANDO AS IMPORTAÇÕES DOS SERVIÇOS NECESSÁRIOS PARA A
EXECUÇÃO DOS PROCESSOS ........................................................................................ 32
3.6 EXECUÇÃO DO PROCESSO E OS RESULTADOS OBTIDOS ................................ 35
4 – CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS .............................................. 39
5 – REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................ 41
APÊNDICE A – CÓDIGOS FONTES MAIS RELEVANTES DA APLICAÇÃO ................. 44
7
LISTA DE FIGURAS
Figura 1. Visão geral de uma WSN [14]. ................................................................................. 15
Figura 2. Cinco categorias básicas dos elementos da notação BPMN 2.0 [22]. ....................... 19
Figura 3. Visão geral de um diagrama em BPMN de um processo de atualização dinâmica de
preço conforme a temperatura do produto [23]. ....................................................................... 20
Figura 4. Visão geral da arquitetura do jBPM. ......................................................................... 23
Figura 5. Visão da estrutura do Process Engine. ...................................................................... 24
Figura 6. Fluxo de modelagem de um processo no jBPM. ....................................................... 24
Figura 7. Figura da modelagem do processo de negócios de medição de temperatura. ........... 27
Figura 8. Site oficial do jBPM no qual é possível realiza o download da versão jbpm-
6.3.0.Final-installer-full.zip da ferramenta. .............................................................................. 28
Figura 9. Executando o comando de instação do Jbpm ............................................................ 29
Figura 10. Iniciando os serviços do jBPM 6.3.0.Final. ............................................................ 30
Figura 11. Visão de acesso do Show Property View do BPMN2 Diagram Editor. .................. 33
Figura 12. Visão de acesso da aba Definitions do BPMN2 Diagram Editor. ........................... 33
Figura 13. Definindo objetos de tipos importados no BPMN2 Diagram Editor. ..................... 34
Figura 14. Consumindo um dado sensoriado do servidor Restful e atribuindo o valor da
temperatura a variável temperature. ......................................................................................... 34
Figura 15. Retorno do WS Restful com temperatura -10. ........................................................ 35
Figura 16. Retorno do WS Restful com temperatura -9 ........................................................... 35
Figura 17. Retorno do WS Restful com temperatura -5 ........................................................... 35
Figura 18. Retorno do WS Restful com temperatura -4 ........................................................... 36
Figura 19. Retorno do WS Restul sinalizando que o sensor está ligado. ................................. 36
Figura 20. Retorno do WS Restul sinalizando que o sensor está desligado. ............................ 36
Figura 21. Apresentação dos dados obtidos após a execução................................................... 37
Figura 22. Apresentação dos dados obtidos após a execução................................................... 38
Figura 23. Visão do arquivo pom.xml do projeto. .................................................................... 47
Figura 24. Classe Principal do projeto jBPM ........................................................................... 48
Figura 25. Implementação para a chamada do Web Service Restful através do Jersey. .......... 50
Figura 26. Captura dos objetos do tipo Sensor. ........................................................................ 50
Figura 27. Captura do atributo temperatura do objeto Sensor. ................................................. 51
Figura 28. Captura dos objetos do tipo Sensor. ........................................................................ 51
Figura 29. Captura dos atributos dos objetos do tipo sensor .................................................... 51
Figura 30. Implementação de envio de email em Java. ............................................................ 54
Figura 31. Classe que define os dados do serviço de e-mail. ................................................... 54
8
Figura 32. Implementação do método que realiza o controle para que o alerta de elevação de
temperatura seja enviado de 30 em 30 minutos. ....................................................................... 55
Figura 33. Implementação da classe que manipula o timer do jBPM. ..................................... 57
9
1 - INTRODUÇÃO
O advento da Internet of Things (IoT) aliado aos avanços tecnológicos presenciados
nos últimos cinco anos e com uma grande redução de preços dos produtos e serviços nas áreas
de tecnologia criaram um ambiente fértil e favorável ao desenvolvimento de pesquisas que
podem contribuir ainda mais com os avanços que surgem a todo o momento. Um exemplo
desse avanço é constatado por meio de uma pesquisa feita pelo International Data
Corporation (IDC) em 2015, mostrando que o mercado de IoT será de aproximadamente 655
bilhões de dólares com uma estimativa de 1,7 trilhões em 2020, indicando um crescimento
anual de 16,9% [1].
Um importante componente da IoT são as redes de sensores sem fio ou Wireless
Sensor Networks (WSN). Uma WSN pode ser caracterizada como uma rede móvel ad-hoc
composta por pequenos dispositivos eletrônicos “inteligentes”, organizados em alguma
estrutura topológica, formando uma infraestrutura de comunicação distribuída, cujo objetivo
principal é realizar medições atmosféricas por meio de sensores conectados aos nós, conforme
as necessidades das aplicações[2,3].
O desenvolvimento de aplicações para IoT ainda é algo que pode ser considerado
complexo com necessidade de conhecimento multidisciplinar e com o envolvimento de vários
profissionais para planejar e implantar uma solução. Dentre os profissionais envolvidos é
possível destacar o especialista em WSN que tem o conhecimento específico das plataformas
e linguagens utilizadas na programação e configuração dos nós em uma rede WSN. O padrão
de rede mais utilizado para as WSN é o IEEE 802.15.4[4]. Esse padrão especifica a
arquitetura de comunicação no nível físico de rede para redes de sensores com baixo consumo
de energia, com dispositivos de recursos limitados e largura de banda em torno de
250Kbps[5].
Desde a liberação da primeira versão do padrão em 2003 até o ano de 2015 é possível
constatar o crescimento, na literatura científica, de publicações com propostas para tornar
mais simples, menos complexo e ao alcance de mais profissionais, o desenvolvimento de
aplicações para WSN. Dentre as publicações com esse objetivo existem propostas para a
geração automática dos códigos dos nós sensores a partir de linguagens de alto nível com
abordagem Model-driven [6] e abordagens com foco em Business Process Management
(BPM)[7] com o uso da linguagem gráficas no nível de processos de negócios como o
Business Process Modeling Notation (BPMN) para modelar graficamente as aplicações,
10
gerando os códigos dos nós e com orquestração das aplicações por meio das ferramentas e
soluções BPM disponíveis. Nas abordagens com o uso de BPMN o mais comum é utilizar
algum tipo de middleware para facilitar o processo e concentrar o foco na modelagem em alto
nível. Por exemplo, pesquisadores ligados ao projeto makeSense [8,9] desenvolveram
propostas para trabalhar com uma extensão do padrão BPMN com o objetivo de melhor
adequar o padrão BPMN para a modelagem de aplicações de processos de negócio integradas
a IoT. Nessas abordagens, o profissional especialista em BPMN precisa ter um conhecimento
básico de WSN e o especialista em WSN também precisa ter um conhecimento de BPMN.
Outro profissional também importante no desenvolvimento de aplicações para WSN é o
especialista do domínio que é o profissional interessado nas aplicações. Normalmente, são
engenheiros, biólogos, farmacêuticos ou qualquer profissional de uma área específica com
interesse em aplicações de IoT.
No contexto dessas abordagens surge o profissional engenheiro de software que tem o
objetivo de modelar as aplicações em alto nível em uma arquitetura Model-driven para gerar
automaticamente ou de forma semiautomática os códigos dos nós, diminuindo um pouco a
dependência ou dividindo responsabilidades com o especialista em WSN. Nas abordagens
BPM surge o especialista me BPMN que é o profissional que já tem conhecimento da
linguagem e do ambiente empresarial no qual já tem experiência em modelagem e automação
de processos em fluxos de trabalho.
Nas abordagens BPM com o uso da linguagem BPMN ou alguma extensão o
interessante é que se tratam de linguagens e abordagens já utilizadas e consagradas no
ambiente empresarial. A linguagem BPMN e as diversas ferramentas e soluções existentes no
mercado são mais apropriadas para modelar a camada lógica dos negócios em arquiteturas
empresariais cujos profissionais que trabalham como gerente de sistemas já estão mais
ambientados ou dominam o BPMN. Dessa forma, o desenvolvimento de aplicações com o uso
de abordagem BPM torna o desenvolvimento de aplicações para WSN algo mais popular.
Com o crescimento da demanda por aplicações de IoT e devido as características de
recursos limitados das WSN baseadas no padrão IEEE 802.15.4 é cada vez mais comum e se
consolida como uma tendência o uso de abordagens que utilizam orientação a serviços como
forma de “dividir” o desenvolvimento e modelagem de aplicações para WSN em duas partes.
A leitura e coleta dos dados dos sensores deve conter o mínimo de processamento ou funções
dentro do contexto de desenvolvimento de aplicações para WSN e a modelagem com as regras
do negócio e o desenvolvimento da aplicação ficam na nuvem por meio de webservices. As
11
abordagens com orientação a serviço que se comunicam com sensores de recursos limitados
são conhecidas como Resource oriented architecture (ROA). Nesse caso, se usa protocolos de
comunicação mais enxutos como o CoaP para a comunicação entre o nó sensor e o web
service RESTful, deixando o desenvolvimendo da aplicação propriamente dita para ser feita
na nuvem.
A abordagem ROA associada as abordagens de geração de códigos proporcionam um
ambiente favorável ao desenvolvimento de aplicações WSN em nuvem sem que os
profissionais envolvidos no desenvolvimento tenham que se preocupar com detalhes de baixo
nível específico de plataforma. Nesse caso, se uma abordagem gerou automaticamente o
código do nó e instancia um serviço na nuvem com abordagem ROA que recebe os dados
sensoriados das WSN facilita muito o uso de abordagens com o objetivo de orquestrar
aplicações WSN com BPM. Nesse caso, é possível que toda a modelagem da aplicação seja
feita pelo especialista BPMN sem que tenha conhecimento específico de baixo nível das
plataformas WSN, pois basta ter acesso aos métodos disponíveis no web service para modelar
sua aplicação. Além disso, ao trabalhar com o padrão BPMN sem modificações é possível que
qualquer profissional com o uso de qualquer ferramenta de modelagem e automação de
processos em BPM possa integrar IoT com BP e modelar as aplicações que desejar.
1.1 OBJETIVOS
O objetivo geral deste trabalho é apresentar uma proposta de abordagem para a
modelagem de aplicações de WSN orientadas a serviço e orquestradas em BPMN.
De forma específica, o trabalho apresenta adicionalmente as seguintes contribuições:
Uma arquitetura e uma estrutura de desenvolvimento de aplicações de WSN
orientadas a serviço e orquestrada em BPMN com o uso da ferramenta jBPM;
A implementação em jBPM de um estudo de caso de uma aplicação de monitoramento
da temperatura de frascos de Botox armazenados em Freezer com alerta ao médico
dermatologista.
1.2 METODOLOGIA
A estratégia inicial de pesquisa foi pautada no objetivo de pesquisar formas ou
alternativas amigáveis para integrar IoT com WoT para que qualquer interessado em dados
12
sensoriados possa desenvolver soluções de aplicações BPMN sem nenhum ou pouco
conhecimento prévio de programação, possibilitando assim, a solução de problemas
modelados utilizando Notação de Modelagem de Processos de Negócio.
Uma das premissas básicas da revisão e pesquisa de literatura científica foi identificar
metodologias e tecnologias disponíveis para implementar o estudo de caso em BPMN. Além
disso, utilizar Web Service (WS) para a aplicação do conceito de WoT, utilizando uma
arquitetura orientada a serviço SOA (Service-oriented Architecture) [10] para a obtenção dos
dados sensoriados por meio de uma requisição HTTP.
Para auxiliar na construção do estudo foi identificado frameworks que utilizam
padrões e arquitetura que facilitam o desenvolvimento.
Esse framework foi o jBPM e sua arquitetura conceitual, que reúnem os requisitos
desejados para a aplicação proposta. Quais sejam:
Aplicar e utilizar o BPM. O jBPM oferece ferramentas e tecnologias para trabalhar com
a modelagem de processos de negócio;
Utilizar uma arquitetura que possibilite realizar a automação dos processos modelados
em BPM;
Uma ferramenta que permita implementar e utilizar sistemas externos durante a
execução dos BP.
Por indicação de alguns pesquisadores e artigos relacionados, foi escolhido o jBPM
após uma longa busca por ferramentas já disponíveis no mercado, como Makesense, Alfresco,
Camunda, BPMN.io, Bonita BPM, entre outros. O objetivo era encontrar uma ferramenta que
permitisse a modelagem do processo de negócio e além de tudo, possibilitasse realizar
requisições a um Web Service Restful e a automação dos processos.
Após a escolha da ferramenta, foi necessário realizar a modelagem do processo de
negócio do estudo de caso, esta modelagem inicialmente foi feita utilizando o BPM Visio e
posteriormente desenhada no BPMN2 Diagram Editor do próprio jBPM.
Feita a modelagem, iniciou-se os estudos sobre o funcionamento da ferramenta e como
era realizado a manipulação das Tasks pelo jBPM e o seu comportamento durante a execução
dos processos instanciados. Durante esses estudos, foi possível identificar como poderiam ser
importados métodos implementados em classes Java e como utiliza-las no meio da execução
dos processos. Isso foi necessário, pois o jBPM foi escrito em Java.
13
Definida a arquitetura conceitual, ferramentas, estruturas, tecnologias e protocolos a
serem usados, iniciou-se a implementação do protótipo para finalmente, avançar com os testes
da aplicação utilizando os dados sensoriados disponíveis no Web Service Restful.
A aplicação ou finalidade alvo é monitorar a temperatura de um freezer por meio dos
dados sensoriados e notificar o médico especialista caso ocorra uma elevação de temperatura
ou caso o sistema detecte que a temperatura voltou ao normal, evitando assim, a perda do
material.
1.3 ORGANIZÃO DO TRABALHO
Esta monografia é estruturada em cinco capítulos e contém, além da presente introdução,
motivação, objetivos e metodologia os seguintes capítulos:
Capítulo 2 – apresenta uma revisão da literatura e referencial teórico dos conceitos,
tecnologias, linguagens, protocolos e métodos que embasaram o
desenvolvimento da solução proposta.
Capítulo 3 – apresenta uma aplicação implementada em jBPM recebendo dados
sensoriados a partir de um Web Service Restful.
Capítulo 4 – apresenta as Considerações Finais e as perspectivas de trabalhos que poderão
dar continuidade à proposta apresentada.
Capítulo 5 – apresenta as Referências Bibliográficas utilizadas neste trabalho.
14
2 – FUNDAMENTAÇÃO TEÓRICA
Nesta seção será apresentada a fundamentação e referencial teórico que foi utilizado
para desenvolver a solução proposta.
2.1 WIRELESS SENSOR NETWORKS
As WSN podem ser caracterizadas como um novo domínio da computação distribuída
e têm sido alvo de grande interesse de pesquisa nos últimos anos. Uma WSN é um tipo de
rede ad-hoc com uma série de características e requisitos específicos. Seu principal objetivo é
realizar tarefas de sensoriamento de forma distribuída para atender as demandas de diversos
tipos de aplicações.
Os nós da rede são dispositivos com recursos limitados com pouca memória e baixa
capacidade de processamento e também utilizam uma largura de banda com valores
aproximados de 250Kbps. O uso de energia é limitado, fazendo o uso até mesmo de baterias.
Quando se trata de WSN, estamos falando de nós com pouco poder computacional e energia
restrita, o trabalho é realizado de forma colaborativa possibilitando assim a realização de uma
grande quantidade de tarefas. As informações coletadas pelos sensores distribuídos na rede,
são entregues aos nós sorvedouros (Sink Node), e são conhecidos como os pontos de saída da
rede, possibilitando assim o processamento dessa informação de uma forma mais precisa [11,
12]. Os atuadores também podem compor uma rede, e possuem como objetivo interação direta
com áreas monitoradas, possibilitando a modificação de parâmetros do ambiente e executando
ações necessárias a serem realizadas [12]. As WSNs possuem características diferentes de
redes de computadores convencionais, pois normalmente as redes essas redes possuem uma
grande quantidade de nodos distribuídos, tendo como restrição o consumo de energia, sendo
necessário possuírem alguns mecanismos adaptativos e de autoconfiguração para prevenir
problemas de falhas na comunicação ou morte dos nodos. As WSNs devem ser autônomas e
tendo como principal objetivo um alto grau de cooperação para executar as tarefas definidas
para a rede. [13]. Os algoritmos tradicionais distribuídos, protocolos e eleição de líderes,
precisa necessariamente ser revisto para que esse tipo de ambiente antes que seja usado, sendo
ainda mais desafiador as WSNs do que redes tradicionais [13]. Neste tipo de redes, os nodos
são equipados com uma grande variedade de sensores [12], como por exemplo: acústico,
15
sísmico, infravermelho, vídeo-câmera, calor, temperatura e pressão. No qual, os nodos podem
distribuídos em grupos (clusters) de forma que pelo menos um dos sensores consiga detectar
um determinado evento na região, processar, e se necessário realizar uma difusão (broadcast)
deste resultado para os outros nodos [13]. De uma forma geral, a tendência é que as WSNs
passem a estar presentes em todos os lugares executando algum tipo de tarefa, independente
da sua natureza. A figura 1, mostra uma visão geral da distribuição de uma WSN.
Figura 1. Visão geral de uma WSN [14].
Sendo assim, as WSNs podem ser aplicadas em segurança e monitoramento, controle,
atuação e manutenção de sistemas complexos, e monitoramento de ambientes internos e
externos [12].
2.2 ABORDAGENS BPM PARA A MODELAGEM DE PROCESSOS DE
NEGÓCIOS INTEGRADAS A IOT
A forma de se propor um modelo de negócios nas empresas tem sido afetada
diretamente pelas novas tecnologias da informação e comunicação (TIC). Sensores, tablets,
celulares, redes sociais, dentre outras inovações tecnológicas, estão influenciando e mudando
o conceito e a forma como as pessoas estão desenvolvendo novos produtos ou serviços. O
advento do Big Data e o da IoT são exemplos de conceitos que podem mudar a forma como as
empresas estão desenvolvendo seus processos de negócios[15,16].
16
O advento do Big Data pode ser caracterizado como uma forma de produzir grandes
volumes de diferentes tipos e de várias fontes diferentes que são coletados em tempo real.
Essas características exigem o uso de novas maneiras de processar, acessar, gerenciar, analisar
e integrar tipos de dados complexos e diversificados a uma velocidade aceitável [17].
Por exemplo, uma empresa pode obter dados de base de dados públicas com
informações sobre os meios de transporte para compreender melhor as possibilidades e
tempos médios gastos com locomoção e propor serviços que possam atender as necessidades
de clientes que não querem perder tanto tempo com locomoção. Dessa forma, um serviço de
entrega eficaz que se baseia em bases de dados públicas e que também pode utilizar dados
originários de redes de sensores públicas espalhadas em uma cidade digital, pode oferecer
novos produtos e serviços que já levam em consideração no próprio modelo de negócios, as
influências e as possibilidades do uso do Big Data e da IoT para melhorar e agregar valor ao
negócio.
Um modelo de negócio é um instrumento importante para auxiliar o entendimento e
caracterização dos requisitos e como os dos processos de negócios irão funcionar e como cada
processo irá se relacionar com os envolvidos. A IoT pode ser considerada uma das principais
fontes geradoras de dados para o Big Data[15]. A geração de dados em larga escala
produzidos por sistemas de controle e monitoramento de cidades digitais com o uso de
sensores podem alimentar base de dados de Big Data que podem ser utilizadas como item
impactante no modelo de algum negócio que possa fazer bom uso desses dados.
Uma das principais fontes de dados para o Big Data é a IoT. Dados em grande escala
pode ser produzido a partir de sistemas de controle ou monitoramento usando sensores e
atuadores. Devido ao grande volume de dados originários do Big Data o uso de tecnologias e
plataformas em nuvem tem sido uma alternativa interessante bem alinhada com os requisitos
dessas aplicações.
Para seja possível utilizar e efetivamente levar em consideração a IoT no modelo de
negócio é preciso mudar a essência do negócio, alterando o modelo do negócio para que ele
leve em consideração o Big Data ou a IoT. Por exemplo, Morabito [15] destaca alguns
desafios organizacionais da atualidade e apresenta exemplos de como o Big Data fornece uma
vantagem competitiva. Preferências de consumidores, formas de se fazer compras, modelos de
produção e transporte de mercadorias ou serviços estão mudando o ambiente de negócios.
A Globalização e o e-commerce são conceitos que estão radicalmente influenciando
essas mudanças. Berardinelli [18] apresenta um exemplo de como um modelo de negócios
17
que utiliza um sistema de Agricultura de precisão com o uso de WSN, utilizando um sistema
para regular a irrigação de árvores em um pomar de amêndoa na região semiárida do Murcia
na Espanha, pode influenciar a essência do negócio e trazer um grande diferencial e vantagens
competitivas. Dependendo da temperatura e do impulso de calor ao longo da linha axial do
tronco de árvore, o sistema faz o controle de irrigação, verificando o melhor momento de sua
ativação, trazendo maior produtividade na colheita das amêndoas.
A demanda e a complexidade dos sistemas computacionais estão crescendo,
principalmente nos sistemas empresariais que normalmente possuem múltiplas camadas[19].
Os requisitos da camada lógica dos negócios tendem a mudar com mais frequência do que
outras partes do sistema, pois precisa acompanhar as novas demandas de uma lógica mais
dinâmica nos negócios. Essas mudanças demandam tempo e implicam em custos de
manutenção nos sistemas empresariais. As soluções de sistema que utilizam linguagens em
estilo imperativo com sequências de comandos como, por exemplo, as linguagens Java e C#,
que geram códigos em estilo “spaguetti”, repletos de comandos “if-else” não são as mais
apropriadas para a modelagem da camada lógica dos negócios. A grande questão é que as
linguagens imperativas implementam, ao mesmo tempo, o que precisa ser feito (requisitos do
negócio) e como deve ser feito (algoritmos).
No final da década de 90 é possível observar o processo de consolidação da
implementação de sistemas Enterprise Resource Planning (ERP) nas empresas[20]. Um
sistema ERP permite a gestão integrada de todas as funções da empresa. A partir de 2000, um
grande movimento em direção a uma visão de gestão de processos ganhou grande destaque.
Nessa mesma época ganha força no ambiente empresarial o conceito de Business Process
Management (BPM). BPM é uma abordagem que identifica, desenha, mede, monitora e
melhora os processos de negócio, a fim de alcançar resultados positivos, de acordo com o
planejamento estratégico de uma organização.
No contexto de BPM, existem algumas definições para o termo "Processo", mas a
essência é a mesma. Um "processo" é um conjunto de atividades inter-relacionadas e
interativas para transformar uma entrada em uma saída. A repetição é uma característica de
um processo. Como exemplo de processos podemos citar um processo de ordem, de entrega
de mercadorias ou de monitoramento de um pomar de amêndoas. Existem outras formas de
falar sobre processos. Por exemplo, um "Processo de Fabricação", um "Processo de Produção"
ou um "Processos de Negócios", que é usado mais no setor de serviços. O termo mais
comumente utilizado para definir processo de BPM no contexto organizacional,
18
especialmente quando se pensa em processo como um emprego ou ocupação é um "processo
de negócios" ou “Business Process” (BP).
Dessa forma, o BPM surge como um método sistemático e viável de análise e gestão
de BP na busca de inovação e de resposta rápida às mudanças no mercado como uma
metodologia ou disciplina mais adequada para a modelagem da camada lógica dos negócios
no ambiente empresarial. Existem alguns modelos para a implantação dos conceitos de BPM
nas empresas. Independente do modelo as vantagens competitivas e benefícios estão presentes
em várias dimensões. Dentre as vantagens podemos citar: Melhor coordenação e integração
do trabalho, tempos de resposta mais rápidos, habilita um foco maior no cliente, previne a
ocorrência de erros, antecipa e controla melhor as mudanças, melhor compreensão da cadeia
de valor e possibilita uma visão sistêmica das atividades da organização.
São por essas vantagens e diversos outros benefícios presentes nos conceitos de BPM
que as empresas estão adotando e migrando a estrutura organizacional para uma estrutura
orientada por processos. Nessa estrutura não se elimina por completo a visão funcional por
departamentos, entretanto, tende a criar uma visão mista com foco e maior atenção os
processos no contexto organizacional. O BPM não é uma solução “mágica” para os problemas
e desafios do contexto globalizado da atualidade, entretanto, proporciona vantagens
significativas no modelo de gestão orientado a processos.
O BPM pode e normalmente é utilizado juntamente com outas iniciativas de melhoria
da qualidade como NBR ISO 9001:2000, 14001:2004, SGQ, SGA, etc. Independentemente do
modelo a ser adotado para implantar os conceitos de BPM existem fatores críticos para o
sucesso da implantação. Uma boa implantação de BPM deve ter uma definição clara dos
envolvidos, utilizar boas ferramentas de software, ter uma estratégia clara de como serão
tratadas as mudanças e definir métricas para avaliar o sucesso. Além disso,
independentemente do modelo de BPM adotado a linguagem utilizada para a modelagem e
automação dos processos será a mesma, pois o padrão de notação adotado mundialmente é o
Business Process Model and Notation (BPMN)[21,22]. O BPMN é um padrão criado e
mantido pela Object Management Group (OMG) como o padrão e linguagem mundialmente
adotado e projetado para a modelagem de BP. Por se tratar de um padrão já consolidado e
bastante utilizado existem várias soluções de softwares que auxiliam o desenho e automação
de BP, principalmente, integrado as soluções e arquiteturas empresariais utilizadas pelos
grandes fornecedores de solução de ERP como a SAP e TOTVS.
19
BPMN é um padrão e uma notação gráfica que foi proposta inicialmente em 2004 com
o objetivo de permitir a modelagem de BP de forma simples, flexível, consistente e mais
adequada a modelagem da camada lógica dos negócios de tal forma que pode ser facilmente
utilizada por profissionais não especialistas da área de TI. BPMN usa uma linguagem gráfica
estruturada por meio de um conjunto de símbolos padronizados para representar os processos
por diagramas. A figura 2 apresenta cinco categorias básicas de elementos da notação BPMN
2.0 [22].
Basic
Categories: Flow Objects Data Connecting Objects Swimlanes Artifacts
Elements: Events, Activities
and Gateways
Data Objects, Data
Inputs, Data
Outputs and Data
Stores
Sequence Flows,
Message Flows,
Associations and Data
Associations
Pools and
Lanes
Group and Text
Annotations
Sample
symbols
Figura 2. Cinco categorias básicas dos elementos da notação BPMN 2.0 [22].
Um outro exemplo de como a IoT pode influenciar e alterar um modelo de negócios é
apresentado por Meyer [23]. A figura 3 apresenta o diagrama em BPMN de um processo de
precificação dinâmica, com um sensor de temperatura e um display eletrônico (ESL). De
acordo com a temperatura do espaço em torno das orquídeas, o sistema é capaz de estimar a
qualidade e reduzir automaticamente o preço do produto que é exibido no display de acordo
com a valores e parâmetros pré-estabelecidos. O objetivo é vender o produto por um preço
menor, para evitar a perda total do produto caso as condições de temperatura fiquem fora do
normal e façam com que se deteriore rapidamente.
20
Figura 3. Visão geral de um diagrama em BPMN de um processo de atualização dinâmica de
preço conforme a temperatura do produto [23].
21
2.3 ARQUITETURAS, TECNOLOGIAS E FRAMEWORKS PARA
DESENVOLVER APLICAÇÕES ROA.
A Arquitetura Orientada a Recursos (ROA) é uma arquitetura guiada pelos princípios
de REST e baseada em tecnologias consolidadas da Web como HTTP, URI e tipos e mídia
[24]. Esta arquitetura surgiu das dificuldades que os desenvolvedores enfrentavam ao projetar
aplicações Web com base em REST. As dificuldades estão relacionadas ao alto nível de
abstração dos princípios de REST, que abrem um amplo horizonte de possibilidades de
projeto. Entre as dificuldades está o fato de que REST não está vinculado com a Web e suas
tecnologias, pois é um estilo arquitetural para sistemas de hipermídia distribuídos, dos quais a
Web é uma instância especifica. Deste fato se deriva diretamente outra dificuldade, que é
como utilizar as tecnologias da Web de acordo com as restrições do estilo REST. Das
necessidades de uma abordagem mais concreta e pragmática para os problemas que se
colocavam surgiu a ROA. Esta arquitetura segue os princípios de REST, mas está vinculada
com as tecnologias da Web como o protocolo HTTP, URI e formatos de dados como XML,
XHTML e JSON.
Os recursos são o cerne da ROA, como seu próprio nome indica. Os recursos são
definidos a partir de conceitos existentes no domínio da aplicação em questão.
Coleções de outros recursos são recursos típicos, por exemplo a coleção de todos os
equipamentos em uma planta, que mapearia para um conjunto de enlaces, cada qual
apontando para o recurso de um equipamento. Resultados de algoritmos também podem ser
expostos como recursos, por exemplo uma busca por um determinado equipamento, ou uma
filtragem do histórico de aquisição de dados de um CLP. Outro recurso comum neste tipo de
arquitetura é o ponto de entrada da aplicação, que expõe uma coleção dos recursos da
aplicação, pelos quais um cliente pode navegar. O projetista também pode definir diferentes
graus de granularidade para um mesmo sistema, criando novos recursos ou fundindo recursos
existentes conforme as suas necessidades.
Cada recurso precisa ser identificado para que os diferentes componentes interessados
nele possam referenciá-lo e interagirem com ele. O que determina que determinado conceito
do sistema e um recurso é o fato de este ser identificado a partir de uma URI. Cada URI
identifica unicamente um recurso na Web e simultaneamente o torna endereçável,
possibilitando que ele seja manipulado. A relação entre recurso e URI é uma relação um para
22
muitos, ou seja, um recurso pode ser referenciado por muitas URIs, mas uma URI só pode ser
associada com um recurso.
A ROA também define algumas propriedades que uma aplicação que segue esta
arquitetura deve possuir: Endereçabilidade, Sem-estado, Conectividade e Interface Uniforme.
Desta forma um dos objetivos da ROA é construir recursos que possam ser bem
aproveitados por pessoas e por máquinas.
2.4 FUNDAMENTOS ARQUITETURA E TECNOLOGIAS DO
FRAMEWORK JBPM.
O jBPM é um framework e uma engine workflow escrita em Java para a modelagem e
automação de processos em BPM[25,26]. O jBPM faz parte de um projeto conhecido como
KIE Group que é composto por algumas ferramentas de automação e gerenciamento de
sistemas empresariais, tais como, Drools, OptaPlanner, UberFire e Dashbuilder. Esse projeto é
mantido pela Red Hat com licença open source.
O jBPM é capaz de executar BP descritos em uma linguagem própria conhecida como
Process Definition Language (jPDL). Essa linguagem especifica um esquema XML e um
mecanismo para empacotar todos os arquivos relacionados com a definição dos processos em
um arquivo de processos. Além disso, ele também pode utilizar outras linguagens como o
Business Process Execution Language (BPEL). O jBPM é baseado em uma Máquina Virtual
de Processos (PVM) que faz parte da comunidade JBoss (projeto que também é mantido pela
RedHat) que suporta múltiplas linguagens de processos de forma nativa e atualmente seu foco
principal é trabalhar com processos no padrão BPMN 2.0 e jPDL.
A figura 4 [27] apresenta a visão geral da arquitetura do jBPM e seus componentes. Os
componentes destacados em vermelhos foram os elementos utilizados para a implementação
do estudo de caso. Cada componente da arquitetura executa uma função específica com o
objetivo de resolver uma funcionalidade dentro da arquitetura do sistema. O “Knowledge
Modules” é o componente que recebe uma determinada modelagem em BPMN 2.0 e
transforma em um arquivo XML que posteriormente será interpretado pelo “Semantic
Module” [28,27]. Em seguida, será feito um parser no XML com o objetivo de identificar e
carregar os nós de processo que foram modelados e que serão executados. Esse módulo é
responsável pela definição da linguagem semântica, ou seja, o que cada palavra significa e
23
como isso será traduzido dentro da estrutura interna do “Process Engine” para ser executada.
O “process Engine” é responsável pela execução dos BP. Ele cria as novas instâncias de
processos e mantem seus estados e os passos internos conforme a visão de sua estrutura
apresentada na figura 5 [27]. O “Process Engine” pode se comunicar com serviços ou
aplicações externas. Essa comunicação é identificada pelo componente “External Systems”
[27].
Figura 4. Visão geral da arquitetura do jBPM.
24
Figura 5. Visão da estrutura do Process Engine.
Em geral, o jBPM recebe como entrada uma modelagem gráfica de BP. Cada processo
é composto por tarefas que estão conectadas por meio das suas transições. Cada processo
possui um fluxo de execução conforme a modelagem feita em BPMN. A figura 6 [27]
apresenta o fluxo de modelagem de um processo em jBPM.
Figura 6. Fluxo de modelagem de um processo no jBPM.
O jBPM suporta processos adaptativos e dinâmicos que exigem flexibilidade a
modelos complexos, soluções de vida real que não podem ser facilmente descritas por
processos rígidos [29].
Decorrente das necessidades de integração com a IoT, o foco desse trabalho será
integrar uma aplicação jBPM com um Web Service Restful que recebe dados sensoriados.
Possibilitando assim, o orquestramento dessa aplicação por meio dessas informações.
25
Para pegar os dados deste servidor, será utilizado o Jersey Versão 2.22.1, que nada
mais é do que uma API baseada em Java do lado cliente que possibilita a obtenção dos dados
no formato Json, entretanto, os dados em Json serão manipulados por uma biblioteca chamada
Google Gson Versão 2.5, possibilitando assim a extração de dados relevantes para a tomada
de decisão por meio da aplicação.
Durante a execução da aplicação, em alguns momentos será necessário notificar o
médico sobre a elevação da temperatura, para isso, foi utilizado o JavaMail API 1.5.5 para
realizar os alertas de elevação de temperatura e de temperatura regular ao médico.
26
3 – MODELAGEM DE APLICAÇÕES DE IOT ORIENTADAS A
SERVIÇOS, ORQUESTRADAS EM BPMN COM USO DO JBPM
Com o objetivo de implementar a solução proposta foi desenvolvido um estudo de
caso de uma aplicação para controlar medicamentos ou qualquer tipo de produto que precisa
ser mantido em freezer ou geladeira sob determinado intervalo de temperatura, pois fora do
intervalo específico o produto pode se deteriorar e não terá mais condições de ser utilizado. O
prejuízo pode ser elevado, pois pode ser uma aplicação que controla produtos de alto valor
como, por exemplo, córneas ou outros órgãos para transplante ou sêmen de cavalos de raça
utilizado por criadores que querem controlar a reprodução de animais. Nesse caso, o produto
deve ser mantido a baixas temperaturas. No caso proposto para esse trabalho o estudo de caso
tratará mais especificamente do controle de medicamentos de uso médico. A aplicação
proposta fará o controle e monitoramento da temperatura de frascos de Botox que são
normalmente utilizados por médicos dermatologistas.
O médico especialista em dermatologia reconhecido pela sociedade brasileira de
dermatologista é o profissional qualificado para a aplicação do Botox. Normalmente o médico
que faz esse tipo de procedimento não compra apenas um frasco. O mais comum é fazer
compras mensais ou programadas com aquisição de uma quantidade maior com
aproximadamente 20 frascos de 100 unidades cada. Dessa forma, o médico precisa controlar e
monitorar a temperatura dos frascos de Botox que normalmente são recebidos por serviços
rápidos de entrega de encomendas.
Os produtos são recebidos em um isopor de tamanho pequeno com barras de gelo em
gel que podem ficar mais de um dia de transporte sem que o produto sofra algum tipo de dano
devido à ser submetido a temperaturas maiores que as permitidas. Atualmente o detentor da
marca Botox é a Pfizer muito conhecida por ser a fabricante do Viagra. Ela comprou a
Allergan que era a fabricante do Botox. O Botox é recebido em um frasco ampola de vidro,
contendo o produto onabotulinumtoxiA congelada a vácuo estéril, acondicionada
individualmente em frascos de 100 unidades cada.
Ao ser recebido as caixas com o Botox devem ser mantidas no freezer em uma
temperatura menor ou igual a -5ºC. Após a diluição com soro para o uso conforme bula e
protocolo adotado pelo médico, o produto deve ser mantido somente em geladeira sob um
intervalo de temperatura entre 2ºC e 8ºC por um período de no máximo de 3 dias.
27
Nesse estudo de caso o foco será apenas para o produto com o frasco a vaco que ainda
não foi utilizado ou diluído. Dessa forma, a temperatura deve ser igual ou inferior a -5ºC.
Normalmente o produto é recebido no consultório do médico dermatologista. Assim que o
isopor com os frascos é recebido a secretária ou o próprio médico deve verificar as condições
do produto e, se for possível, fazer a medição da temperatura do interior do isopor com algum
medidor manual de temperatura para saber se a temperatura está igual ou inferior a -5ºC. Após
a verificação o produto deve ser armazenado no freezer do consultório que deve ser
controlado pelo sistema assim que o produto for colocado lá. É muito comum que o médico
não deixe todos os frascos que acabaram de chegar no freezer do consultório. O ideal é deixar
apenas o que normalmente se usa durante uma semana. Conforme o uso, a reposição é feita
por demanda. O restante dos frascos é levado para o freezer de casa que também deve ter um
sistema de monitoramento instalado.
O sistema apresentado nesse estudo de caso propõe a instalação do sistema de
sensoriamento do botox no freezer do consultório e no freezer da casa do médico. O diagrama
da figura 7 apresenta a modelagem em BPMN 2.0 com o fluxo do processo de monitoramento
de temperatura do freezer que contém os fracos do Botox do médico. Para implementar esse
estudo de caso foi utilizado o editor de diagramas do jBPM, mas poderia ser desenhado em
qualquer outra ferramenta de modelagem compatível com o padrão BPMN 2.0.
Figura 7. Figura da modelagem do processo de negócios de medição de temperatura.
28
Nas subseções seguintes serão apresentados os passos e etapas necessários para a
implementação do estudo de caso proposto em jBPM. Com a sequência de passos
apresentados a seguir é possível implementar qualquer aplicação WSN orientada a serviços no
jBPM. A abordagem busca modificar ou adequar o mínimo possível do jBPM para que seja
possível implementar o estudo de caso. Dessa forma, outros pesquisadores podem fazer
alterações equivalentes em outras ferramentas de modelagem e automação em BPMN para
que implementem outras aplicações WSN orquestradas em BPMN.
Por se tratar de uma abordagem orientada a serviços a proposta apresentada parte do
pressuposto que já existe um webservice RESTful já implantado e funcionando, recebendo os
dados do sensor que está conectado ao freezer.
3.1 INSTALAÇÃO DA FERRAMENTA JBPM E SUAS DEPENDÊNCIAS
Para realizar a implementação do estudo de caso proposto em jBPM o primeiro passo é
instalar o jBPM e suas respectivas dependências. Para esse estudo de caso foi utilizada a
versão jbpm-6.3.0.Final-installer-full.zip disponível no site do projeto da ferramenta conforme
apresentado na figura 8.
Figura 8. Site oficial do jBPM no qual é possível realiza o download da versão jbpm-
6.3.0.Final-installer-full.zip da ferramenta.
Após o download da ferramenta, é necessário caminhar até a raiz do diretório e
executar o comando ant install.demo, como mostra na figura 9.
29
Figura 9. Executando o comando de instação do Jbpm
Este comando irá utilizar o Apache Ant para realizar toda a instalação dessa
ferramenta, o Apache ant é uma ferramenta utilizada para automação de compilação na
construção de software, similar ao make mas escrita na linguagem Java e foi desenvolvida
inicialmente para ser utilizada em projetos desta linguagem. Como requisito, caso esteja
utilizando a versão Windows, e o Apache Ant não esteja instalado, recomenda-se ir até o site
http://ant.apache.org/manual/install.html e seguir os passos de instalação da ferramenta, não
esquecendo de adicionar o Apache Ant no Path do Windows para que seja executado a partir
do console do Windows (CMD). Caso a versão seja o linux (ubuntu), foi adicionado nos
fontes desse trabalho um script de instalação automatizada da ferramenta, no qual será apenas
necessário aceitar os termos do Java, e o script seguirá com a instalação completa do jBPM
6.3.0.Final.
Após toda essa instalação, basta apenas executar o comando ant start.demo e todos os
módulos necessários para a execução do jBPM, como por exemplo: o banco de dados h2, o
eclipse luna e o servidor WildFly 8.1.0 .Final do grupo jBoss, como mostrado na figura 10.
30
Figura 10. Iniciando os serviços do jBPM 6.3.0.Final.
Após a execução deste comando, os serviços serão carregados e o eclipse luna será
aberto.
Na próxima seção, será explicado como se cria um primeiro projeto jBPM e daremos
uma breve explicação sobre o gerenciador de dependências Maven.
3.2 CRIANDO UM PROJETO JBPM
A primeira etapa após a instalação, no que se diz respeito a implementação é a criação
do projeto, nesta etapa foi criado um projeto jBPM Project (Maven), no qual vamos utilizar o
Maven para gerenciar todas as dependências do projeto. O maven é um software de
gerenciamento e compreensão de ferramentas, ou seja, baseado sobre o conceito de Project
Object Model (POM), Maven pode gerenciador construção de projetos, reportar e documentar
peças centrais de informações. O que é importante saber para esse projeto, é que o artigo mais
importante do Maven que será manipulado é o pom.xml, no qual todas as dependências
necessárias do projeto vão ser colocados lá dentro e o Maven irá baixar todas as dependências
automaticamente, sem a necessidade de ir até o site das ferramentas e baixar os arquivos .jar.
Algumas ferramentas nesse trabalho que foram importadas utilizando o Maven foi o Cliente
Jersey para realizar a comunicação com o servidor Restful, Javax.Mail para enviar os e-mails
de notificação aos Stackholders do projeto, Google Gson que é um software open source
criado pela google para realizar o tratamento de códigos Json, entre outras dependências
necessárias que serão mostradas mais à frente neste capítulo.
31
Após a criação do projeto Maven, é necessário adicionar as dependências que serão
utilizadas no projeto, conforme o código apresentado na figura 15 do Apêndice A, ao
adicionar as dependências, o Maven irá baixar todos os arquivos necessários para o
desenvolvimento do projeto.
3.3 MODELANDO UM PROCESSO DE NEGÓCIO NO BPMN2 DIAGRAM
EDITOR
Crie um arquivo do tipo jBPM Process Diagram dentro de src/main/recources com o
nome que desejar, neste trabalho o nome do arquivo será chamado de ProcessBotox.bpmn2.
Nesta etapa é necessário fazer a modelagem utilizando a notação BPMN 2.0, na qual foi dada
uma breve introdução de sua utilização em capítulos anteriores deste trabalho. Como foi visto
na figura 7, é necessário iniciar o processo, verificar se o sensor está ligado ou não, caso esteja
ligado verifica qual a temperatura, caso esteja desligado, finaliza o processo. Após verificar a
temperatura, toma decisão de alertar o médico caso a temperatura esteja elevada, ou espera 30
segundos e refaz o processo novamente. A notificação de temperatura regular só é enviada ao
médico caso o mesmo já tenha recebido uma mensagem de temperatura elevada ou em caso
de falha do funcionamento do sensor.
Após a modelagem estar completa, vamos partir para a implementação da classe principal
de um projeto jBPM.
3.4 CRIANDO A CLASSE PRINCIPAL DE UMA APLICAÇÃO JBPM
Antes de seguir adiante, é necessário realizar algumas explicações sobre os próximos
passos. A seguir, será mostrado como implementar uma classe principal do jBPM que irá
consumir a modelagem dada acima e a tomada de decisão a partir dos mais variados
resultados esperados neste modelo. Em primeiro lugar, será necessário criar uma classe java
dentro do diretório src/main/java, o nome fica a cargo do leitor, porém neste trabalho a classe
será chamada de ProcessExecution.java.
A classe ProcessExecution.java pode ser visualizada conforme o código apresentado na
figura 16 do Apêndice A, os conceitos utilizados foram RuntimeManager, KieSession e
32
ProcessInstance. Esses 3 (três) pontos são os pontos fundamentais para todo o funcionamento
do jBPM, foi utilizado o JbpmJUnitBaseTestCase para evitar o trabalho de implementação
dessas funções e facilitar os testes.
3.5 REALIZANDO AS IMPORTAÇÕES DOS SERVIÇOS NECESSÁRIOS
PARA A EXECUÇÃO DOS PROCESSOS
Com apenas essas implementações feitas acima, já é possível rodar testes simples no
jBPM, como simplesmente realizar System.out.println() dentro das task scripts, entretanto, o
objetivo aqui é mostrar muito além disso. Será explicado nesta seção, como implementar suas
próprias classes Java e chamar elas dentro do modelo de processo de negócio utilizando o
BPMN2 Diagram Editor. Vale lembrar, que a utilização do BPMN2 Diagram Editor não é
obrigatória, dentro da ferramenta jBPM existem outros meios de se realizar tal modelagem,
como por exemplo utilizar BPMN2 Process Editor, XML ou até mesmo o KIE que é nada
mais nada menos do que uma interface web super poderosa do grupo jBoss, no qual oferece a
possibilidade de realizar toda essa implementação a partir de sua interface, não sendo
necessário assim a utilização do eclipse, porém essa abordagem não será mostrada neste
trabalho.
Para utilizar as implementações java dentro da modelagem do jBPM, é necessário
realizar a implementação das classes e incluir as mesmas no modelo. Isso pode ser feito
clicando com o botão direito no modelo, dentro do BPMN2 Diagram Editor e indo na opção
Show Property View, irá abrir uma janela, como pode ser visto na figura 11.
33
Figura 11. Visão de acesso do Show Property View do BPMN2 Diagram Editor.
Após isso, é preciso acessar Definitions, como mostrado na figura 12.
Figura 12. Visão de acesso da aba Definitions do BPMN2 Diagram Editor.
A partir daí, é possível importar as classes necessárias do projeto. Feito isso, vá na aba
Data Items e crie variaveis locais que utilizam as classes importadas, como pode ser visto na
figura 13.
34
Figura 13. Definindo objetos de tipos importados no BPMN2 Diagram Editor.
Neste trabalho, foi feito os imports para a manipulação do cliente Jersey, envio de e-
mails do javax.mail, contagem do tempo e do tipo Long, que não é padrão do BPMN2
Diagram Editor.
A partir desses imports, foi possível realizar a chamada das funções utilizando os Task
Scripts utilizados no trabalho, como pode ser visto na figura 14.
Figura 14. Consumindo um dado sensoriado do servidor Restful e atribuindo o valor
da temperatura a variável temperature.
35
Neste trabalho as chamadas das funções foram implementadas como sendo do tipo
static, uma vez que o objeto foi instanciado nas propriedades do modelo. A utilização da
função kcontext.setVariable, é uma função do jBPM utilizado para modificar as variáveis
criadas em Data Items ou passadas como parâmetro no Mapa de String da classe principal do
jBPM, como mostrado na figura 16 do Apêndice A.
3.6 EXECUÇÃO DO PROCESSO E OS RESULTADOS OBTIDOS
Nesta seção serão apresentados os resultados obtidos durante a execução do projeto.
Os dados recebidos do web service e utilizados pela aplicação implementada em jBPM foram
obtidas por meio de um simulador implementado em Jersey que retorna códigos em Json.
Conforme pode ser observado nas figuras 15, 16, 17 e 18 são apresentados exemplos de
retorno deste servidor com medição de temperatura do sensor. Os dados obtidos do sensor
estão em um intervalo de -4 a -10. Após o resultado da requisição, os dados são tratados
utilizando o Gson conforme pode ser visto nas figuras 26,27,28 e 29 do apêndice A. No
simulador a probabilidade de uma temperatura -4 ser retornada é de aproximadamente 14%.
Figura 15. Retorno do WS Restful com temperatura -10.
Figura 16. Retorno do WS Restful com temperatura -9
Figura 17. Retorno do WS Restful com temperatura -5
36
Figura 18. Retorno do WS Restful com temperatura -4
Nas figuras 19 e 20, são mostrados alguns resultados obtidos do WS Restful
sinalizando o estado do sensor, esse resultado determina o momento de parada do processo e a
notificação enviada ao médico especialista, isso irá ocorrer mediante a falha ou desligamento
do sensor. Na implementação, a probabilidade de ocorrer um desligamento é de apenas 5%.
Figura 19. Retorno do WS Restul sinalizando que o sensor está ligado.
Figura 20. Retorno do WS Restul sinalizando que o sensor está desligado.
Nas figuras 21 e 22, pode ser visualizado o passo a passo de uma execução. Para
exemplificar foram colocadas algumas impressões na tela do processo, entretanto, a
modelagem final apresentada na figura 7 não apresenta essas impressões.
Durante a execução do processo mostrado na figura 21, é possível visualizar cada
passo de execução das Tasks, sendo do estado inicialmente ligado, em seguida é feita a
verificação da temperatura até o momento de se detectar uma temperatura elevada e o
profissional for alertado.
37
Figura 21. Apresentação dos dados obtidos após a execução
No final da figura 21, é possível verificar que após uma elevação de temperatura a
temperatura voltou a ficar regular e o profissional foi alertado. Já na figura 22, não houve
elevação de temperatura e o processo foi executado até o desligamento ou falha do sensor,
sendo assim, o médico deve ser notificado deste fato como mostrado no final da figura.
38
Figura 22. Apresentação dos dados obtidos após a execução.
Dessa forma, foi possível verificar que o uso do jBPM com o uso de web services para
orquestrar em BPMN uma aplicação WSN é viável e relativamente simples. Diante disso, foi
apresentado que é viável e possível que um especialista em BPMN pode modelar uma
aplicação sem ter conhecimento específico de plataformas de WSN.
39
4 – CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
Mediante a grande variedade de protocolos, tecnologias, plataformas e métodos ou
abordagens para desenvolver e solucionar problemas para IoT, não existe uma proposta
“padrão” ou mais comum, pois existem diferentes tipos de abordagens para IoT ou WoT.
Independente abordagem adotada para desenvolver aplicações para WoT é preciso
buscar as alternativas mais adequadas caso o interesse seja de utilizar uma abordagem BPM,
pois o ideal é utilizar propostas que aproveitem as competências e habilidades já existentes
nos profissionais do mercado.
Sendo assim, foi mostrado que o jBPM é uma suíte de programas, flexíveis, para o
Gerenciamento de Processo de Negócio, fazendo uma ponte entre os analistas de negócio e os
desenvolvedores. As soluções de modelagem BPM oferecem suíte de programas para facilitar
o trabalho do especialista BPMN sem que ele precise ter um conhecimento mais técnico em
infraestrutura ou programação. O jBPM oferece recursos e várias funcionalidades para a
modelagem e gerenciamento de processos de negócios e desenvolvimento de aplicações para
as organizações [26].
Um processo de negócio permite modelar os negócios com o objetivo de descrever
passo a passo o que precisa ser executado para alcançar esse objetivo e ordem usando fluxos
gráficos. Melhorando muito a visibilidade e a agilidade da lógica de negócios, resultados em
alto nível e representações específicas do domínio que pode ser compreendida por usuários de
negócio e provendo uma maior facilidade de monitoramento.
Como proposta de continuidade a esse trabalho, uma alternativa é melhorar e extender
as funcionalidades do jBPM para que um profissional especialista em BPMN tenha o mínimo
ou nenhum conhecimento específico de programação em Java para orquestrar uma aplicação
WSN em BPMN com possibilidade de modelagem de aplicações sensíveis contexto com
integração com o Drools.
Com o crescimento da demanda de soluções de uso empresarial, unido com a
necessidade de integração com a IoT nas empresas, é importante criar mecanismos que
possam facilitar a modelagem de processos não apenas para BPMN 2.0. Estes mecanismos,
passam a prover uma maior facilidade para que especialistas de processos de negócio
modelem soluções sem a necessidade de desenvolvimento de código em baixo nível.
40
Além disso, seria também desejável incluir funcionalidades de auto geração de código
no jBPM, evitando assim que tarefas simples sejam implementadas com tanta dificuldade
como foi o caso do timer que precisou da implementação de uma classe para a manipulação
do tempo.
41
5 – REFERÊNCIAS BIBLIOGRÁFICAS
1. MacGillivray, C. ; Turner, V. ; Shirer, M. Explosive Internet of Things Spending to
Reach $1.7 Trillion in 2020. IDC Corporate USA: Framingham, Massachusetts: IDC,
2015. Available online: http://www.idc.com/getdoc.jsp?containerId=prUS25658015
(accessed on 18 Ago 2015).
2. Loureiro, A.A.F., el al. Redes de Sensores sem Fio. XXI Simpósio de redes de
computadores, UFMG, 2013.
3. Souza, S. C. Uma abordagem baseada em regras e computação em nuvem para
desenvolvimento de aplicações em redes de sensores sem fio. 2013. Dissertação
(Mestrado em Informática) - UFES/CT/PPGI, Vitória-ES. Acesso em 7 mar. 2014.
4. IEEE Std 802.15.4™ 2011. IEEE Standard for Local and metropolitan area networks -
Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) (Revision of
IEEE Std 802.15.4-2006), IEEE Computer Society, New York, NY, 2011.
5. Memsic, Wireless Sensor Networks. Available online:
http://www.memsic.com/wireless-sensor-networks/ (accessed on 28 Aug 2015).
6. Rodrigues, T., Batista, T., Delicato, F.C., Pires, P.F., Zomaya, A.Y. Model-driven
approach for building efficient Wireless Sensor and Actuator Network applications in
Software Engineering for Sensor Network Applications (SESENA), 2013 4th
International Workshop, p.43 - 48, 2013.
7. Baldam, R.; Valle, R. ; Rozenfeld, H. Gerenciamento de Processos de Negócios -
BPM. Rio de Janeiro: Campus - Elsevier, 2014.
8. Casati, F., Daniel, F., Dantchev, G., Eriksson, J., Finne, N., Karnouskos, S., Montera,
P.M., Mottola, L., Oppermann, F.J., Picco, G.P., Quartulli, A., Romer, K., Spiess, P.,
Tranquillini, S., Voigt, T. Towards business processes orchestrating the physical
enterprise with wireless sensor networks in Software Engineering (ICSE), 2012 34th
International Conference, p.1357 - 1360, 2012.
9. Sungur, C. T. Extending BPMN for Wireless Sensor Networks. Institute of
Architecture of Application Systems. University of Stuttgart, 2013.
10. Internet of Things (IoT): A vision, architectural elements, and future directions in
Future Generation Computer Systems Jayavardhana Gubbia, Rajkumar Buyya Volume
29, Issue 7, September 2013, Pages 1645–1660
11. Delicato, F.C., "Middleware Baseado em Serviços para Redes de Sensores sem Fio",
(In Portuguese), PhD Thesis, Federal University of Rio de Janeiro, Brazil, June, 2005.
12. Loureiro, A. A. F., Nogueira, J. M. S., Ruiz, L. B., de Freitas Mini, R. A., Nakamura,
E. F., and Figueiredo, C. M. S. (2003). Redes de sensores sem fio. In Simposio
Brasileiro de Redes de Computadores, pages 179 – 226.
13. Architecture for Wireless Sensor Network”, Linnyer Beatrys Ruiz, Luiz Henrique A.
Correia, Luiz Filipe M. Vieira, Daniel F. Macedo, Eduardo F. Nakamura, Carlos M. S.
Figueiredo, Marcos Augusto M. Vieira, Eduardo Habib Bechelane, Daniel Camara,
42
Antonio A.F. Loureiro, José Marcos S. Nogueira, Diógenes C. da Silva Jr., Antonio O.
Fernandes, SBRC Tutorial 2004, May 2004. In Portuguese.
14. ALLAN DE FREITAS, WIRELESS SENSOR NETWORKS (WSN) AND WLANS.
Available online: http://www.decom.ufop.br/alan/?hl=en&p=3&id=8.
15. Morabito, V. Big Data and Analytics for Competitive Advantage in Springer
International Publishing, Switzerland, 2015.
16. Sun, Y.; Yan, H.; Lu, C.; Bie, R.; Thomas, P. A holistic approach to visualizing
business models for the internet of things in Communications in Mobile Computing,
2012. Available online: http://www.comcjournal.com/content/1/1/4.
17. Fang, H.; Zhang, Z.; Wang, C.J.; Daneshmand, M.; Wang, C.; Wang, H. A survey of
big data research in IEEE Communications Society, 2015.
18. Berardinelli L.; Cortellessa V.; Pace S. Modeling and analyzing performance of
software for wireless sensor networks in Proceedings of the 2nd Workshop on
Software Engineering for Sensor Network Applications, 2011.
19. Bali, M. Drools JBoss Rules 5.0 Developer's Guide; Packt Publishing: Birmingham,
UK, 2009.
20. Baldam, R.; Valle, R. ; Rozenfeld, H. Gerenciamento de Processos de Negócios -
BPM. Rio de Janeiro: Campus - Elsevier, 2014.
21. Object Management Group. Business Process Modeling Notation (BPMN), Available
online: http://URL http://www.omg.org/bpmn/ (accessed on 01 Nov 2015).
22. Object Management Group. Business Process Modeling Notation (BPMN), Version
2.0.2. OMG Specification. ISO/IEC 19510, 2013.
http://www.omg.org/spec/BPMN/ISO/19510/PDF.
23. Meyer, S.; Ruppen, A.; Magerkurth, C. Internet of Things-aware Process Modeling:
Integrating IoT Devices as Business Process Resources in 25th International
Conference, CAiSE 2013, Valencia, Spain, June 17-21, 2013.
24. Richardson, L.; Ruby, S. RESTful Web Services. O'Reilly Media. ISBN 978-0-596-
52926-0, 2007.
25. Red Hat Inc. KIE Group, Available online: http://URL http://www.kiegroup.org/
(accessed on 01 Nov 2015).
26. Red Hat Inc. jBPM, Available online: http://URL http://www.jbpm.org/ (accessed on
01 Nov 2015).
27. Nicolas Maio, M., Salatino, M., Aliverti E. jBPM6 Developer Guide. PACKT
PUBLISHING. ISBN 978-1-78328-661-4, 2014, Pages 29-33.
28. Jboss.Org Community Documentation, Charpter 4. Kie, Build, Deploy, Utilize and
Run, Available online: https://docs.jboss.org/drools/release/6.2.0.CR4/drools-
docs/html/KIEChapter.html (accessed on 05 Jan 2016).
29. jBoss jBPM. Java Business Process Management, Available online:
https://docs.jboss.org/jbpm/v2/manual/ (accessed on 30 Dez 2015).
43
30. Maciej Swiderski, jbpm, Available online: https://github.com/mswiderski/jbpm
(accessed on 2 Jan 2016).
44
APÊNDICE A – CÓDIGOS FONTES MAIS RELEVANTES DA
APLICAÇÃO
Nesse apêndice serão apresentados os códigos fontes mais relevantes que foi preciso
desenvolver para conseguir implementar o estudo de caso proposto.
Após criar um projeto Maven é necessário adicionar todas as dependências do projeto.
As dependências deste projeto são dependências padrãões do jBPM, Drools, cliente de e-mail,
cliente Jersey, Gson, dentre outros.
A figura 23 apresenta o códido do arquivo pom.xml com as dependências
mencionadas acima registradas.
<?xml version="1.0"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<!-- Script Padrão
* é necessário modificar apenas os 3 campos abaixo!
* groupId, artifactId e name
-->
<groupId>com.medicine.control</groupId>
<artifactId>Build</artifactId>
<name>jBPM6 Build</name>
<version>1.0</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<version.org.drools>6.3.0.Final</version.org.drools>
<version.org.jbpm>6.3.0.Final</version.org.jbpm>
<hibernate.version>4.2.0.Final</hibernate.version>
<hibernate.core.version>4.2.0.Final</hibernate.core.version>
<slf4j.version>1.6.4</slf4j.version>
<jboss.javaee.version>1.0.0.Final</jboss.javaee.version>
45
<logback.version>1.0.9</logback.version>
<h2.version>1.3.161</h2.version>
<btm.version>2.1.4</btm.version>
<junit.version>4.8.1</junit.version>
</properties>
<dependencies>
<!-- define drools BOM -->
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-bom</artifactId>
<type>pom</type>
<version>${version.org.drools}</version>
<scope>import</scope>
</dependency>
<!-- define drools BOM -->
<dependency>
<groupId>org.jbpm</groupId>
<artifactId>jbpm-bom</artifactId>
<type>pom</type>
<version>${version.org.jbpm}</version>
<scope>import</scope>
</dependency>
<!-- Adicionei as dependencias daqui para baixo. -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.6.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jbpm</groupId>
46
<artifactId>jbpm-flow</artifactId>
<version>6.3.0.Final</version>
</dependency>
<dependency>
<groupId>org.jbpm</groupId>
<artifactId>jbpm-flow-builder</artifactId>
<version>6.3.0.Final</version>
</dependency>
<dependency>
<groupId>org.jbpm</groupId>
<artifactId>jbpm-bpmn2</artifactId>
<version>6.3.0.Final</version>
</dependency>
<dependency>
<groupId>org.jbpm</groupId>
<artifactId>jbpm-test</artifactId>
<version>6.3.0.Final</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>2.22.1</version>
</dependency>
<dependency>
<groupId>javax.mail</groupId>
<artifactId>javax.mail-api</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.5</version>
</dependency>
47
</dependencies>
</project>
Figura 23. Visão do arquivo pom.xml do projeto.
Agora que todas as dependências do projeto foram incluidas no pom.xml e a
modelagem do procesos de negócio foi feita no BPMN2 Diagram Editor, é mostrado na figura
24 como se cria uma classe principal no jBPM.
Primeiramente, é necessário realizar a extensão do JbpmJUnitBaseTestCase.
Adicionar a modelagem realizada no BPMN2 Diagram Editor na função
createRuntimeManager.
Instanciar um RuntimeEngine e um objeto do tipo KieSession.
Criar um Map do tipo String para realizar inputs externos no modelo, fazendo
com que o modelo conheça as variáveis externas que serão chamadas dentro
dele.
Instanciar um ProcessesInstance e dar um Start no processo, passando como
parametro as variáveis externas mencionadas anteriormente e aguardar o
termino do processo.
A CountDownProcessEventListener não é essencial para a implementação de um
projeto jBPM, essa classe foi implementada para a manipulação do Evento Timer do
tipo Intermediate Catching Event, como pode ser visto na figura 7 do capítulo 3,
entretanto, para que ele funcione a implementação dessa classe é de extrema
importância, e será mostrada na figura 33.
package com.medicine.control;
import java.util.HashMap;
import java.util.Map;
import org.jbpm.test.JbpmJUnitBaseTestCase;
import org.junit.Test;
import org.kie.api.runtime.KieSession;
import org.kie.api.runtime.manager.RuntimeEngine;
import org.kie.api.runtime.process.ProcessInstance;
48
import com.medicine.control.handler.CountDownProcessEventListener;
public class ProcessExecution extends JbpmJUnitBaseTestCase{
@Test
public void testProcess() throws Exception {
CountDownProcessEventListener countdown = new
CountDownProcessEventListener("timer", 1);
createRuntimeManager("ProcessBotox.bpmn2");
RuntimeEngine engine = getRuntimeEngine(null);
KieSession ksession = engine.getKieSession();
Map<String, Object> params = new HashMap<String, Object>();
params.put("itsON", true);
params.put("alertTemp", false);
ProcessInstance processInstance =
ksession.startProcess("medicine.control.ProcessBotox", params);
countdown.waitTillCompleted();
assertNodeTriggered(processInstance.getId(),"Desligado ou
Removido");
assertProcessInstanceCompleted(processInstance.getId(),
ksession);
}
}
Figura 24. Classe Principal do projeto jBPM
Essa classe é utilizada do lado cliente para realizar por meio do Jersey e do protocolo
HTTP o consumo de dados sensoriados do Web Service Restful. A parte principal dessa
implementação é que, com o client Jersey configurado no pom.xml e todas as dependências
sendo gerenciadas pelo Maven, passa a ser necessário apenas a implementação de uma função
que recebe uma URL e cria um objeto do tipo Client, que a partir desse objeto inicializa o
objeto com o método newClient e utiliza o método target(URL) do objeto para capturar o dado
do Web Service Restful, como mostrado na figura 25.
49
package com.medicine.control.handler;
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.client.WebTarget;
import javax.ws.rs.core.MediaType;
import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
import com.medicine.control.json.handler.ItsONWrapper;
import com.medicine.control.json.handler.SensorWrapper;
public class CallRestfulWebService {
public static WebTarget getRequestRest (String URL){
Client client = ClientBuilder.newClient();
return client.target(URL);
}
public static String getJSON (String URL){
/*Se for JSON*/
WebTarget target1 = getRequestRest(URL);
return
target1.request(MediaType.APPLICATION_JSON).get(String.class);
}
public static int getTemperature (String URL){
Gson g = new GsonBuilder().create();
SensorWrapper temperature = g.fromJson(getJSON(URL),
SensorWrapper.class);
return Integer.parseInt(temperature.toString());
}
public static boolean getItsON(String URL){
Gson g = new GsonBuilder().create();
ItsONWrapper itson = g.fromJson(getJSON(URL),
ItsONWrapper.class);
return Boolean.parseBoolean(itson.toString());
50
}
}
Figura 25. Implementação para a chamada do Web Service Restful através do Jersey.
Após a chamada do Web Service Restful, será retornado um código Json com os dados
sensoriados, entretanto, existe a necessidade de extrair esses dados recebidos no formato Json,
para isso, foi utilizado a biblioteca Google Gson.
A informação mais importante desse código é que, o atributo da classe
SensorWrapper precisa possuir o mesmo nome do atributo retornado no Json, nesse caso o
atributo deve ser sensor. Como esse objeto, é uma instancia de uma classe qualquer, deve ser
atributo dessa classe o nome do campo do objeto sensor que se pretende capturar, que no caso
abaixo é o campo temperatura, como pode ser visto nas figuras 26 e 27.
package com.medicine.control.json.handler;
public class SensorWrapper {
private Sensor sensor;
@Override
public String toString() {
return ""+sensor;
}
}
Figura 26. Captura dos objetos do tipo Sensor.
package com.medicine.control.json.handler;
public class Sensor {
private Integer temperature;
@Override
public String toString() {
return ""+temperature;
}
51
}
Figura 27. Captura do atributo temperatura do objeto Sensor.
A explicação da classe ItsOnWrapper é similar à da figura SensorWrapper, no qual o nome do
objeto Json que se pretende capturar é sensor, e o nome do atributo da classe ItsON que se
deseja é o atributo ItsON, como pode ser visto na figura 28 e 29.
package com.medicine.control.json.handler;
public class ItsONWrapper {
private ItsON sensor;
@Override
public String toString() {
return ""+sensor;
}
}
Figura 28. Captura dos objetos do tipo Sensor.
package com.medicine.control.json.handler;
public class ItsON {
private boolean itsON;
@Override
public String toString() {
return ""+itsON;
}
}
Figura 29. Captura dos atributos dos objetos do tipo sensor
Esse serviço utiliza a biblioteca Javax Mail para o envio de e-mails de alerta. Foram
definidas funções com mensagens padrões e uma função que pode ser utilizada com
mensagens de escolha do especialista de processos de negócio, como mostrado na figura 30.
Os dados do serviço de e-mail são definidos na classe SMTPAuthenticator, como mostrado na
figura 31.
52
package com.medicine.control.handler;
import javax.mail.*;
import javax.mail.internet.*;
import java.util.Date;
import java.util.Properties;
import com.medicine.control.handler.SMTPAuthenticator;
public class MailWithAuthentication {
public static void alert() throws Exception{
String subject = "Elevação de temperatura [URGENTE]";
String body = "Foi detectada a elevação de temperatura do
freezer, recomendado verificar!";
sendEmail(subject, body);
}
public static void announcement() throws Exception{
String subject = "Temperatura estabilizada";
String body = "A temperatura do freezer voltou ao normal!";
sendEmail(subject, body);
}
public static void sendEmail(String subject, String body) throws
Exception{
Properties props = new Properties();
props.put("mail.smtp.user", SMTPAuthenticator.SMTP_AUTH_USER);
props.put("mail.smtp.host", SMTPAuthenticator.SMTP_HOST_NAME);
props.put("mail.smtp.port", SMTPAuthenticator.SMTP_HOST_PORT);
props.put("mail.smtp.starttls.enable","true");
props.put("mail.smtp.debug", "true");
props.put("mail.smtp.auth", "true");
props.put("mail.smtp.socketFactory.port",
SMTPAuthenticator.SMTP_HOST_PORT);
props.put("mail.smtp.socketFactory.class",
53
"javax.net.ssl.SSLSocketFactory");
props.put("mail.smtp.socketFactory.fallback", "false");
SMTPAuthenticator auth = new SMTPAuthenticator();
Session session = Session.getInstance(props, auth);
// creates a new e-mail message
Message msg = new MimeMessage(session);
msg.setFrom(new
InternetAddress(SMTPAuthenticator.SMTP_AUTH_USER));
//InternetAddress[] toAddresses = { new
InternetAddress(SMTPAuthenticator.SMTP_AUTH_USER) };
//msg.setRecipients(Message.RecipientType.TO, toAddresses);
msg.addRecipient(Message.RecipientType.TO, new
InternetAddress(SMTPAuthenticator.SEND_TO));
msg.setSubject(subject);
msg.setSentDate(new Date());
// creates message part
MimeBodyPart messageBodyPart = new MimeBodyPart();
messageBodyPart.setContent(body, "text/html");
// creates multi-part
Multipart multipart = new MimeMultipart();
multipart.addBodyPart(messageBodyPart);
// sets the multi-part as e-mail's content
msg.setContent(multipart);
try{
Transport transport = session.getTransport("smtps");
transport.connect(SMTPAuthenticator.SMTP_HOST_NAME,
Integer.valueOf(SMTPAuthenticator.SMTP_HOST_PORT),
SMTPAuthenticator.SMTP_AUTH_USER, SMTPAuthenticator.SMTP_AUTH_PWD);
transport.sendMessage(msg, msg.getAllRecipients());
transport.close();
54
} catch (AddressException e) {
e.printStackTrace();
} catch (MessagingException e) {
e.printStackTrace();
}
}
}
Figura 30. Implementação de envio de email em Java.
package com.medicine.control.handler;
import javax.mail.PasswordAuthentication;
package com.medicine.control.handler;
import javax.mail.PasswordAuthentication;
public class SMTPAuthenticator extends javax.mail.Authenticator {
public static final String SMTP_HOST_NAME = "smtp.gmail.com";
public static final String SMTP_HOST_PORT = "465";
public static final String SMTP_AUTH_USER =
public static final String SMTP_AUTH_PWD = "*********";
public static final String SEND_TO = "[email protected]";
public PasswordAuthentication getPasswordAuthentication() {
String username = SMTP_AUTH_USER;
String password = SMTP_AUTH_PWD;
return new PasswordAuthentication(username, password);
}
}
Figura 31. Classe que define os dados do serviço de e-mail.
55
Durante a execução do processo de negócio, é necessário enviar um e-mail de aviso
caso haja alguma elevação de temperatura, entretanto, passados 30 minutos e a temperatura
continue elevada, outra mensagem deve ser enviada. Sendo assim, a partir do momento em
que o e-mail é enviado, um temporizador mede até que o tempo de 30 minutos seja atingido
novamente e um outro e-mail seja enviado novamente, entretanto, caso uma temperatura
regular seja atingida, esse temporizador deve ser resetado e marcado novamente no próximo
alerta de temperatura elevada.
O método isThirtyMinutes é responsável por receber o tempo corrente e a partir dai
realizar uma verificação através do tempo corrente do sistema se já passou 30 minutos, caso
tenha passado 30 minutos, a aplicação será notificada. A implementação desse método pode
ser visto na figura 32.
package com.medicine.control.handler;
public class VerificationCurrentTime {
private static final int THIRTY_MINUTES = 30 * 60 * 1000; //30
minutos
public static boolean isThirtyMinutes(long currentTimestamp){
long thirtyAgo = System.currentTimeMillis() - THIRTY_MINUTES;
if (currentTimestamp < thirtyAgo) {
return true; //Se passou 30 minutos;
}
return false; //Não passou 30 minutos.
}
}
Figura 32. Implementação do método que realiza o controle para que o alerta de elevação de
temperatura seja enviado de 30 em 30 minutos.
Decorrente do mal funcionamento dos timers no jBPM, é necessário a implementação
de uma classe que estende de DefaultProcessEventListener e instanciar um objeto desse
mesmo tipo na classe principal do jBPM, como pode ser visto na figura 16. O método
waitTillCompleted() deve ser utilizado para esperar o tempo definido no Timer Intermediate
56
Catch Listener. Após instanciar esse objeto na classe principal jBPM e colocar o
waitTillCompleted(), qualquer tempo pode ser definido dentro do objeto timer do modelo, e o
mesmo será aguardado durante a execução do processo. A implementação original deste
método feita para persistencia de dados pode ser encontrado em um repositório no Git Hub
[30] e o código para a manipulação de Timer sem persistencia pode ser visto na figura 33.
package com.medicine.control.handler;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;
import org.kie.api.event.process.DefaultProcessEventListener;
import org.kie.api.event.process.ProcessNodeLeftEvent;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class CountDownProcessEventListener extends
DefaultProcessEventListener {
private static final Logger logger =
LoggerFactory.getLogger(CountDownProcessEventListener.class);
private String nodeName;
private CountDownLatch latch;
public CountDownProcessEventListener(String nodeName, int threads) {
this.nodeName = nodeName;
this.latch = new CountDownLatch(threads);
}
@Override
public void afterNodeLeft(ProcessNodeLeftEvent event) {
if (nodeName.equals(event.getNodeInstance().getNodeName())) {
countDown();
}
}
57
public void waitTillCompleted() {
try {
latch.await();
} catch (InterruptedException e) {
logger.debug("Interrputed thread while waiting for all
triggers for node {}", nodeName);
}
}
public void waitTillCompleted(long timeOut) {
try {
latch.await(timeOut, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
logger.debug("Interrputed thread while waiting for all
triggers for node {}", nodeName);
}
}
protected void countDown() {
latch.countDown();
}
}
Figura 33. Implementação da classe que manipula o timer do jBPM.