UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO … · 2.4 FUNDAMENTOS ARQUITETURA E TECNOLOGIAS DO...

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





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





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 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


36


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>



<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>



<dependency>

<groupId>org.drools</groupId>

<artifactId>drools-bom</artifactId>

<type>pom</type>

<version>${version.org.drools}</version>

<scope>import</scope>

</dependency>



<dependency>

<groupId>org.jbpm</groupId>

<artifactId>jbpm-bom</artifactId>

<type>pom</type>

<version>${version.org.jbpm}</version>

<scope>import</scope>

</dependency>



<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>


<scope>test</scope>

</dependency>

<dependency>

46

<artifactId>jbpm-flow</artifactId>

<version>6.3.0.Final</version>

</dependency>

<dependency>


<artifactId>jbpm-flow-builder</artifactId>


</dependency>

<dependency>


<artifactId>jbpm-bpmn2</artifactId>


</dependency>

<dependency>


<artifactId>jbpm-test</artifactId>


</dependency>

<dependency>

<groupId>commons-logging</groupId>

<artifactId>commons-logging</artifactId>


</dependency>

<dependency>

<groupId>org.glassfish.jersey.core</groupId>

<artifactId>jersey-client</artifactId>


</dependency>

<dependency>

<groupId>javax.mail</groupId>

<artifactId>javax.mail-api</artifactId>


</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.


public class Sensor {

private Integer temperature;

@Override


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.


public class ItsONWrapper {

private ItsON sensor;

@Override


return ""+sensor;

}

}

Figura 28. Captura dos objetos do tipo Sensor.


public class ItsON {

private boolean itsON;

@Override


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


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.


import javax.mail.PasswordAuthentication;


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 =

"[email protected]";

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.


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.


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.

UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO … · 2.4 FUNDAMENTOS ARQUITETURA E TECNOLOGIAS DO...

Documents

Transcript of UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO … · 2.4 FUNDAMENTOS ARQUITETURA E TECNOLOGIAS DO...