ROMILDO JUNIOR BESSEGATO
DISTRIBUIÇÃO DE SERVIÇOS DA ARQUITETURA AGROMOBILE
UTILIZANDO WEBSERVICES
Santa Rosa
2014
ROMILDO JUNIOR BESSEGATO
DISTRIBUIÇÃO DE SERVIÇOS DA ARQUITETURA AGROMOBILE
UTILIZANDO WEBSERVICES
Trabalho de Conclusão de Curso do Curso
de Ciência da Computação da Universidade
Regional do Noroeste do Estado do Rio
Grande do Sul.
Orientador: Dr. Gerson Battisti
Santa Rosa
2014
Dedico este trabalho aos meus familiares, que sempre estiveram ao meu lado, me apoiando, me incentivando e ajudando em todos os momentos e tanto contribuíram para minha formação. Dedico também a minha esposa que foi amiga, conselheira e sempre me encorajou a seguir em frente.
AGRADECIMENTOS
Primeiramente agradeço a Deus por estar sempre iluminando os meus
caminhos. Aos meus pais e irmãs, pelas palavras de incentivo e por estarem comigo
em todos os momentos.
Ao meu orientador Gerson Battisti por sempre estar à disposição para tirar
minhas dúvidas, pelo apoio durante o trabalho e por aprimorar os meus
conhecimentos com desenvolvimento de WebServices.
Agradeço aos meus colegas que estiveram comigo durante estes anos e
pelas amizades que conquistamos. Á todos os professores do curso de Ciência da
Computação, pelos conhecimentos sabiamente transmitidos e pelas informações
passadas que foram adquiridas através de suas experiências, especialmente ao
Vinicius Maran mentor do projeto AgroMobile.
RESUMO
A partir de um projeto em desenvolvimento na Universidade Regional do
Noroeste do Estado do Rio Grande do Sul (UNIJUI), o qual visa uma arquitetura de
software para auxílio na agricultura de precisão, a beneficiar pequenos e médios
produtores, a arquitetura AgroMobile baseia-se em diversos módulos desde o
sensoriamento, a modelagem do conhecimento, as interfaces para usuários e o
gerenciamento baseado em WebServices. Este trabalho objetiva desenvolver a
parte do gerenciamento, os quais farão a interligação entre todos os módulos a fim
de estabelecer o pleno funcionamento. Estas interligações são baseadas em
WebServices desenvolvidos em Java no padrão RESTful com o tráfego de dados
em JSON para se tornar uma interligação ágil e funcional.
Palavras chave: Agricultura de Precisão, WebServices, RESTful.
.
ABSTRACT
From a project under development at the Northwest Regional University of the
State of Rio Grande do Sul (UNIJUI), which targets a software architecture to aid in
precision agriculture, small and medium producers qualify, AgroMobile architecture is
based in several modules from the sensing, modeling of knowledge, the user
interfaces and management based on WebServices. This work aims to develop the
part of management, which will make the interconnection between all modules in
order to establish the full operation. These interconnections are based on
WebServices developed in Java on standard RESTful with JSON data traffic in order
to become an agile and functional interconnection.
Keywords: Precision Farming, WebServices, RESTful.
LISTA DE ABREVIATURAS E SIGLAS
API
Application Programming Interface
Embrapa
Empresa Brasileira de Pesquisa Agropecuária
GPS
Sistema de Posicionamento Global
HTML
HyperText Markup Language
HTTP
Hypertext Transfer Protocol
JSON
JavaScript Object Notation
PH
Potêncial Hidrogeniônico
REST
Representational State Transfer
RSSF
Rede de Sensores Sem Fio
SOAP
Simple Object Access Protocol
URL
Uniform Resource Locator
UTF-8
8-bit Unicode Transformation Format
XML
eXtensible Markup Language
LISTA DE FIGURAS
Figura 1 - A) Diagrama de um nó de rede de sensores; B) Protótipo do nó da RSSF.
... 16
Figura 2 - Diagrama de Sequência do Coletor Definido ... 17
Figura 3 - Invocação Arquitetura WebServices ... 21
Figura 4 - Exemplo de Arquivo XML ... 23
Figura 5 - Exemplo de arquivo JSON ... 24
Figura 6 - Diagrama Lógico da Modelagem da Informação ... 26
Figura 7 - Arquitetura de software ... 26
Figura 8 - Diagrama de Pacotes dos WebServices. ... 28
Figura 9 - Classe ApplicationConfig ... 29
Figura 10 - Métodos genéricos da classe AbstractFacade ... 29
Figura 11 - Diagrama de Classes do Pacote Entidades ... 30
Figura 12 - Classe Técnico do Pacote Entidades. ... 31
Figura 13 - Diagrama de Classes Pacote Recursos ... 32
Figura 14 - Exemplo do Inicio da Classe Fachada. ... 32
Figura 15 - Exemplo Método Create (POST) ... 33
Figura 16 - Exemplo Método Edit (PUT) ... 33
Figura 17 - Exemplo Método Remove (DELETE) ... 34
Figura 18 - Exemplo Método Find (GET) ... 34
Figura 19 - Esquema do Protótipo ... 35
Figura 20 - Estrutura lógica da tabela leituras. ... 35
Figura 21 - Classe NewJerseyClient no Cliente. ... 36
Figura 22 - Método Mount no Cliente. ... 36
Figura 23 - Retorno do Cliente ao Fazer POST no Recurso Leituras ... 37
LISTA DE TABELAS
SUMÁRIO
INTRODUÇÃO ... 11
1
O PROJETO AGROMOBILE ... 13
1.1
Módulos da Arquitetura ... 14
1.2
Sensoriamento ... 15
1.3
Representação do Conhecimento ... 17
2
WEBSERVICES ... 20
3
DISTRIBUIÇÃO DE SERVIÇOS DA ARQUITETURA AGROMOBILE
UTILIZANDO WEBSERVICES... 25
3.1
Informações do Projeto AgroMobile com WebServices ... 25
3.2
Desenvolvimento dos WebServices ... 27
3.2.1
Pacote Config ... 28
3.2.2
Pacote entidades ... 30
3.2.3
Pacote Recursos ... 31
3.3
Protótipo para AgroMobile ... 34
CONCLUSÃO... 38
REFERÊNCIAS ... 39
APÊNDICE A – Classes do Pacote Config ... 41
APÊNDICE B – Classes do Pacote Entidades ... 44
INTRODUÇÃO
A agricultura tem evoluído muito nos últimos anos, e com o avanço da
tecnologia há um foco especial de estudos na área da agricultura de precisão. Este é
um tema abrangente, pois não se limita a algumas culturas e nem a algumas
regiões. É um sistema (baseado em um conjunto de processos) de manejo integrado
de informações e tecnologias, fundamentado nos conceitos de que as variabilidades
de espaço e tempo influenciam diretamente nos rendimentos dos cultivos
(CAMPANHOLA, 2004).
A agricultura de precisão visa auxiliar o gerenciamento mais detalhado dos
sistemas de produção agrícola, não somente das aplicações de insumos ou de
mapeamentos diversos, mas de todos os processos envolvidos na produção.
Segundo a Empresa Brasileira de Pesquisa Agropecuária (Embrapa), um dos pontos
que convergem em excelência de resultados para a agricultura de precisão é a
Tecnologia da Informação.
Atualmente, existem vários sistemas que fornecem auxílio à agricultura de
precisão, porem há uma resistência dos produtores na utilização destes sistemas,
pois eles são feitos para especialistas da área, e não para leigos, além de seu custo
ser elevado, possibilitando acesso a poucos.
O projeto AgroMobile busca minimizar essa desigualdade através do
desenvolvimento de uma arquitetura que auxilia os assistentes técnicos como
técnicos agrícolas e engenheiros agrônomos, com a utilização de ferramentas de
fácil manuseio, sejam elas website ou softwares instalados em dispositivos móveis
com Sistema de Posicionamento Global (GPS) para a agricultura de precisão.
Desta forma, os mesmos terão um acompanhamento preciso nas áreas de
produção, para que seja detectada qualquer ameaça e/ou aplicada à correção
necessária em determinado ponto da lavoura, tornando assim um gerenciamento
preciso e com as dosagens certas para tal problema, gerando um melhor cultivo e
um aumento significativo na produção.
A dependência da automação para a agricultura de precisão segundo
Boemo:
A agricultura de precisão também necessita cada vez mais de acesso a um grande número de dados o que é possível devido aos avanços obtidos no processamento computacional (2011).
Buscando beneficiar o maior número de produtores, o projeto AgroMobile,
em desenvolvimento na Universidade Regional do Estado do Rio Grande do Sul
(Unijuí), tem como principal objetivo propor uma arquitetura de software onde
possam ser feitas recomendações aos produtores utilizando informações de
sensores e tecnologias da computação móvel e pervasiva (KIRSCHNER; MARAN,
2012).
Esta arquitetura é composta por diversos serviços. Estes serviços são
separados por funcionalidades, tais como: coleta de dados, engine, modelos de
dados, entre outros. Para que seja possível que estes serviços sejam interligados e
distribuídos (devido a quantidade de informação gerada e processada pela
arquitetura), é necessário que existam interfaces na forma de WebServices para os
serviços da arquitetura.
Sendo assim, como parte da arquitetura AgroMobile, o objetivo é utilizar os
conceitos e tecnologias da área de sistemas distribuídos, desenvolvimento Java
Web, padrão RESTful e definir um conjunto de interfaces WebServices com padrões
para a troca de mensagens, que possam se comunicar com as demais partes da
arquitetura AgroMobile, tais como: a interface Web ou o aplicativo Android utilizado
pelos usuários, o coletor responsável pelas informações dos sensores na lavoura e
também com a ontologia que modela o conhecimento do domínio de agricultura de
precisão. Com isso é formada uma camada de software capaz de gerenciar toda
essa arquitetura, visando seu total funcionamento, gerando as sugestões mais
apropriadas para a solicitação ou vir a alertar ao usuário por algum evento anormal
inesperado.
1 O PROJETO AGROMOBILE
O Projeto AgroMobile, a partir de estudos relacionados nas áreas de
Computação Móvel, Ubíqua e Aplicada na Agricultura de Precisão, tem como
objetivo o desenvolvimento de uma arquitetura de software, e com essas
ferramentas auxiliar engenheiros agrônomos na tomada de decisões mais precisas
quanto às dosagens certas de insumos, coleta de amostras, fornecendo também um
histórico para o melhor aproveitamento e melhor produção agrícola, informações
necessárias para se ter um bom gerenciamento dos negócios.
Com a mudança no padrão agrícola brasileiro, a agricultura não está mais
sendo vista como uma atividade primária isolada, sendo cada vez mais associada
aos setores industriais e comerciais. Países importadores de produtos primários
exigem uma variedade cada vez maior de critérios de qualidade antes de comprar
alimentos, causando grandes impactos na cadeia de produção de alimentos,
especialmente entre pequenos e médios agricultores, os quais são pouco integrados
a organizações ou circuitos de comercialização (ASSAD et al., 2004).
Buscando atender a esta demanda, com tecnologia de ponta e custo baixo,
o AgroMobile beneficia produtores de pequeno e médio porte que não possuem
recursos suficientes para adquirir sistemas proprietários encontrados hoje no
mercado. Através da utilização desta ferramenta, estes agricultores terão um melhor
controle e produção de suas lavouras, além de contribuir com a preservação do
meio ambiente, este sendo considerado por Assad et al. (2004) um dos principais
desafios da atividade agrícola.
Esta arquitetura tem como principal finalidade alertar e sugerir medidas
preventivas para os Engenheiros Agrônomos e Técnicos Agrícolas. De acordo com
as informações do ambiente de produção (a lavoura), estes receberão
recomendações do sistema quando qualquer anomalia for identificada, sugerindo
uma determinada ação a ser tomada para o problema. Assim, ele terá posse de
várias informações importantes, como umidade, variações de temperatura, Potencial
Hidrogeniônico (PH) do solo, entre outras.
A partir de sensores localizados nas lavouras o agricultor terá informações
precisas de sua área, ao passo que qualquer anomalia identificada possa gerar um
alerta e uma sugestão para tal problema a fim de minimizar o impacto na sua
produção. Essas informações serão disparadas para seu dispositivo móvel o qual
possuirá a aplicação desenvolvida ou ao utilizar o website.
Para isto, necessita-se de uma rede de sensores para uma informação
precisa e atualizada, da definição de uma ontologia a ser aplicada para embasar o
conhecimento e assim gerar as sugestões apropriadas, uma aplicação para
dispositivos móveis a fim de fazer a intermediação entre o hardware e o produtor ou
um website para acessar por qualquer plataforma, tudo isso para que ele possa ter o
controle e o ponto exato do evento alertado tomando assim sua decisão.
1.1 Módulos da Arquitetura
A arquitetura AgroMobile é dividida em 6 módulos, sendo eles: Rede de
Sensores; Coletores; Aplicativo de Interface para Dispositivos Móveis e WebSite;
Servidor de Serviços para a Arquitetura (Gerenciamento) e a Representação do
Conhecimento através de ontologias.
Rede de Sensores: na rede de sensoriamento serão criados nós com
sensores utilizando a plataforma Arduino, os quais constantemente
estarão lendo informações em tempo real e enviando estes pacotes
de informações aos atuadores para que estes possam tratá-las e
verificar se existe algum fator de risco;
Coletor: os coletores são responsáveis pelo recebimento e filtragem
das informações enviadas pelos nós de sensores, que posteriormente
serão enviadas para os WebServices. São desenvolvidos na
linguagem de programação Java e fisicamente estarão junto ao
ambiente de produção (na lavoura);
Aplicativo Móvel: desenvolvido em Java para sistemas Android, este
aplicativo fará o auxilio e comunicação com o usuário (Engenheiros e
Técnicos), nele terá todas as informações que poderão vir a ser
consultadas de determinadas áreas mapeadas com o GPS e também
receberá os alertas e sugestões levantadas pela arquitetura;
Interface WEB: tem as mesmas funcionalidades do aplicativo para
Android, sendo uma segunda opção para o usuário, a fim de poder
ser utilizada em qualquer plataforma e em qualquer dispositivo.
Servidor de Serviços: os WebServices terão um papel fundamental
na arquitetura com um todo, pois eles que darão a possibilidade de
interligação dos módulos. Serão desenvolvidas interfaces de
comunicação em Java utilizando a arquitetura RESTful com o tráfego
de dados no formato JavaScript Object Notation (JSON) que se
comunicará com os coletores, aplicativos móveis, interface Web e as
ontologias;
Representação do Conhecimento: o conhecimento do domínio da
Agricultura de Precisão será desenvolvido através de uma ontologia,
a qual foi definida através da ferramenta Protége e modelada através
da linguagem OWL-DL (Aurélio et al., 2013).
1.2 Sensoriamento
O módulo de sensoriamento da arquitetura AgroMobile é formado por uma
rede de sensores específicos, destinados às suas funções que são manipuladas
através de um algoritmo de gerenciamento. Estes sensores enviam as leituras para
os coletores (softwares que filtram as informações dos sensores) que por sua vez se
comunicam como os servidores (MORGENSTERN et al., 2013).
Estes sensores são interligados por uma Rede de Sensores Sem Fio
(RSSF), a qual consegue fazer o compartilhamento de dados de cada nó e com que
cada sensor se comunique com o agregador de dados (coletor) enviando suas
informações.
Os sensores utilizados neste projeto são acoplados sob a plataforma
Arduino juntamente com diversos itens essenciais para seu funcionamento. Dentre
estes sensores existem o sensor de PH do solo, o sensor de umidade e temperatura
modelo DHT11, sensor de umidade modelo BSoil-01, módulo de GPS, placa de
fotovoltaica e o módulo transmissor e receptor de rádio frequência. A Figura 1
apresenta o diagrama de um nó da rede de sensores e o protótipo de um nó da
RSSF.
Figura 1 - A) Diagrama de um nó de rede de sensores; B) Protótipo do nó da RSSF.
A)
B)
Fonte: MORGENSTERN et al. (2013).
Os sensores numerados apresentados no diagrama de um nó de rede de
sensores, na Figura 2: parte A, possuem as seguintes funções:
1. Sensor de PH do Solo: faz a coleta de dados referente ao PH do solo;
2. Sensor de Umidade e Temperatura (DHT11): faz e medição da
temperatura, sendo que possui uma versão interna ao solo e outra
externa;
3. GPS: responsável pelo mapeamento e localização;
4. Sensor modelo BSoil-01: informa a quantidade de umidade do solo ao
seu redor;
5. Placa de Alimentação Solar: responsável por captar radiações solares
e convertê-las em energia para recarregar as baterias;
6. Módulo Transmissor e Receptor de Rádio Frequência: fazem a
comunicação entre os nós em uma determinada frequência a qual deve
ser diferenciada para o envio e recebimento.
A integração com o restante da arquitetura fica de responsabilidade do
coletor de dados o qual foi desenvolvido em Java e sua função é o recebimento dos
dados, envio de confirmação de recebimento dos mesmos, filtragem das
informações coletadas pelos sensores, fragmentação da mensagem, armazenando
em um banco de dados local para que o servidor os acesse quando necessitar. A
Figura 2 apresenta o fluxograma do agregador de dados.
Figura 2 - Diagrama de Sequência do Coletor Definido
Fonte: MORGENSTERN et al. (2013)
1.3 Representação do Conhecimento
O domínio de estudo deve ser representado de forma a auxiliar na
compreensão de cada aspecto do mesmo. Assim, as ontologias se aplicam de forma
a organizar as informações dos mais diferentes domínios, trazendo uma série de
vantagens no uso da representação do conhecimento (AURÉLIO et al., 2013). Uma
melhor definição de ontologia é dada por Gruber (1995), o qual afirma que uma
ontologia é uma especificação de uma conceituação, ou seja, uma descrição de
conceitos e relações que existem em um domínio de interesse.
Segundo Duarte et al. (2000), ontologias são úteis para apoiar a
especificação e implementação de qualquer sistema de computação complexo.
Dentre os propósitos para a construção de uma ontologia é possível destacar o
auxílio na compreensão de certa área de conhecimento e o auxílio na obtenção de
um consenso sobre determinado assunto.
Dentro do projeto AgroMobile está sendo desenvolvida uma ontologia
utilizando a ferramenta Protégé para fazer a modelagem semântica de informações
compreendidas no domínio da Agricultura de Precisão, através da linguagem
OWL-DL (Aurélio et al., 2013). A ontologia se encontra atualmente em fase de
especificação e aquisição de conhecimento. A sua modelagem está sendo realizada
seguindo a metodologia Methontology, a qual é considerada a mais popular para o
desenvolvimento de ontologias, o que torna o processo mais fácil e cria certo
padrão. A especificação da ontologia servirá como base para todo o resto da
modelagem, pois através da documentação utilizando de linguagem natural, é
possível captar o objetivo da ontologia e seus demais propósitos. Já o processo de
aquisição de conhecimento é marcado pela pesquisa às possíveis fontes
disponíveis, tais como entrevistas com especialistas no domínio, consulta a livros,
além de ontologias já existentes, entre outros.
Esta ontologia será utilizada como base para as etapas posteriores à
modelagem conceitual proposta, pois através dela serão modelados os serviços e
demais componentes do sistema de apoio à decisão.
Como cita o artigo de Aurélio et al. (2013), a metodologia utilizada para
iniciar o desenvolvimento da ontologia é baseada em conhecimentos adquiridos
através de estudos a outras ontologias já propostas na área de Agricultura de
Precisão. Para modelar o ambiente rural, foram extraídos dados do Manual de
Adubação e de Calagem para os estados do Rio Grande do Sul e Santa Catarina
(2004), além de informações sobre eventos, principalmente climáticos, que podem
interferir diretamente no domínio de agricultura de precisão.
A cultura inicialmente utilizada para a criação da ontologia é a soja, sendo
que a definição pode ser aplicada também em outras ontologias, para outras
culturas. Foram definidas algumas superclasses, as quais desencadeiam uma vasta
lista de subclasses que se relacionam ao representar os elementos do contexto, os
quais podem influenciar no projeto AgroMobile. Os principais elementos do contexto
são os seguintes:
Áreas e Glebas (Area, Gleba): englobam as informações geográficas
da agricultura de precisão, através de conceitos como coordenadas e
referências geográficas.
Clima (Weather): descreve possíveis eventos climáticos que podem
atuar sobre o ambiente na qual a arquitetura AgroMobile atua;
Safra, Planejamento, Produtor e Técnicos (Harvest, Planning,
durante o ciclo da safra, desde o princípio até o final, com o auxílio de
técnicos e o envolvimento dos produtores;
Grãos (Grain): definição da cultura a ser utilizada no plantio;
Solo (Soil): composto por vários fatores determinantes, como
nutrientes, PH, entre outros que são indispensáveis durante as
análises para determinados fins;
Critérios de Recomendações de Calagem e Adubagem (Criteria of
Recommendation of Liming and Composting): são geradas
recomendações para realização de determinados serviços, conforme
os critérios a serem analisados, de acordo com o que está
acontecendo ou aconteceu no ambiente;
Serviço (Service): considerada uma das classes mais importantes pela
sua utilização, é nela que estão contidos os serviços a serem
realizados no domínio de Agricultura de Precisão através da
arquitetura AgroMobile.
As classes citadas contém atributos específicos e individuais que podem
armazenar tanto objetos concretos quanto abstratos, mas são os relacionamentos
que fazem a ligação entre as classes e dão clareza para identificar um ambiente
real.
Através das regras de inferência que serão definidas na ontologia, será
possível propor serviços específicos da agricultura de precisão para determinados
relacionamentos criados.
2 WEBSERVICES
Nos últimos anos a tecnologia WebServices vem despertando a atenção de
analistas e arquitetos de programação, pois modifica o modo de como os sistemas
são
desenvolvidos,
prometendo
excelentes
ganhos
como
produtividade,
portabilidade e independência.
Tendo como finalidade principal prover serviços, uma empresa pode
automatizar diversas áreas com serviços web, sem a necessidade de uma pessoa
física para intermediar a negociação. Podemos citar como exemplo uma empresa na
qual o seu cliente já tem em mãos os dados principais para fazer um pedido de
compras, como preço, descrição, código, entre outros. O mesmo pode acessar um
serviço web disponibilizado pela empresa e diretamente fazer seu pedido sem que
haja esta intermediação.
Com este intuito foi criado os WebServices, para construção de aplicações
automatizadas que nada mais são do que serviços disponibilizados na internet.
Porém, vale lembrar que a criação de interfaces gráficas para usuários não faz parte
deste conceito de WebServices, ficando a cargo de outro setor da programação.
Esta arquitetura pode ser definida como uma arquitetura de software que
relaciona os componentes de um sistema em um ambiente distribuído onde são
disponibilizados serviços que podem ser acessados dinamicamente através de uma
rede (AMORIM, 2004 apud SILVA, 2004). A tecnologia WebServices propõe a
exposição das transações e das regras de negócios por meio de protocolos que
podem ser acessados e entendidos por qualquer linguagem de programação, em
qualquer sistema operacional, rodando em qualquer dispositivo (COSTA, 2002 apud
SILVA, 2004).
Para Zavalik (2004) o objetivo dos WebServices é obter interoperabilidade
entre aplicações através do uso de padrões Web.
A utilização de WebService é uma das maneiras mais comuns de integrar
aplicações diferentes, possuindo diferentes tipos de arquiteturas para esta finalidade
podemos destacar o Simple Object Access Protocol (SOAP) e o Representational
State Transfer (REST) sendo este mais simples comparado com o anterior.
O SOAP (2003) é um protocolo que se destina à troca de informações
estruturadas em um ambiente distribuído e descentralizado. Definido no W3C é
baseado em eXtensible Markup Language (XML) e contém alguns elementos, tais
como:
Envelope: Identifica o documento XML como uma mensagem SOAP e
é responsável por definir o conteúdo da mensagem;
Header (opcional): Contém os dados do cabeçalho;
Body: Contém as informações de chamada e de resposta ao servidor;
Fault: Contém as informações dos erros ocorridos no envio da
mensagem. Esse elemento só aparece nas mensagens de resposta
do servidor.
Na Figura 3, podemos ver a representação gráfica deste protocolo,
mostrando a troca de mensagens entre o cliente (Client Wrapper) e o servidor
(Server Wrapper) que disponibilizam a transparência para as aplicações e seguindo
o protocolo SOAP sobre Hypertext Transfer Protocol (HTTP) só trafega XML.
Figura 3 - Invocação Arquitetura WebServices
Fonte: SUMRA (2003)
Já o termo REST (Representacional State Transfer), originou-se da
dissertação de doutorado de Roy Fielding, publicada em 2000.
Segundo Fielding (apud OLIVEIRA, 2009), REST é “um conjunto de
princípios arquiteturais que quando aplicadas como um todo enfatiza a
escalabilidade da interação entre componentes para reduzir a latência de interação,
garantir segurança e encapsular sistemas legados
”.
Cliente / Servidor;
Apoiar sistemas de cache;
Sistemas em camadas (suportar escalabilidade);
Estado nulo (cada requisição de um cliente ao servidor deve conter
todas as informações necessárias para entender a requisição);
Stateless (comunicação sem controle de estado);
Sistema uniforme utilizando 4 métodos padronizados:
o GET – operação de leitura;
o PUT – relacionada e inserção ou alteração;
o POST – cria um objeto no servidor;
o DELETE – operação de remoção;
Conforme Tilkov (apud OLIVEIRA, 2009), o REST é
“um conjunto de
princípios que definem como os padrões Web, como o HTTP e URIs devem ser
utilizados
”. Tilkov conclui dizendo que “a principal promessa do REST é que se você
aderir aos princípios durante o projeto de sua aplicação, você irá acabar com um
sistema que explora a arquitetura Web em seu benefício
”.
Neste modelo de arquitetura o que mais importa são as URLs do sistema e
os resources. Um recurso (resources) ou uma entidade é um objeto contendo
informações que será representada por meio de um XML ou JSON. Geralmente a
URL para acessar este recurso será a mesma, o que muda é o método HTTP (GET,
PUT, POST DELETE) o qual vai definir o resultado da requisição.
Para utilizar qualquer um dos padrões citados acima é necessário conhecer
as linguagens de marcação XML e JSON, pois o padrão de SOAP utiliza-se de
text/XML e a arquitetura REST de text/JSON.
A XML (eXtensible Markup Language) é uma linguagem de marcação para
propósitos especiais, usada para descrever e organizar dados para aplicações.
Diferentemente da Linguagem de Marcação de Hipertexto (HTML), suas etiquetas
não são pré-definidas. O desenvolvedor poderá criar suas próprias etiquetas (BRAY,
et al., 2008), capaz de descrever diversos tipos de dados, podendo ser utilizada para
formatação de textos, armazenamento em banco de dados, armazenamento de
propriedades de áudio e vídeo, imagens vetoriais, entre outros.
Como a XML segue um método hierárquico de formatação, ou seja, possui
tecnologias que temos hoje as quais já diferenciam o que são tags do que é
conteúdo propriamente dito.
O cabeçalho e a tag-root é o conteúdo mínimo para ser considerado um
arquivo XML. O cabeçalho é onde se encontra a versão (Version) a qual implica no
modo de leitura dos interpretadores e juntamente temos o tipo de padrão de
caracteres utilizados em seu conteúdo (Encoding), sendo que o UTF-8 é o padrão
popular internacional e o ISO-8859-1 é o padrão nacional. A tag-root consiste em
uma tag que engloba todas as outras tags do arquivo e tem a função de especificar
onde é o começo e o fim deste XML.
Na Figura 4, podemos ver um exemplo de arquivo no formato XML, onde
“<população>” é a tag-root, aberta no inicio do arquivo e fechada no final com
“</população>” englobando todas as demais tags dentro dela.
Figura 4 - Exemplo de Arquivo XML
Fonte: Própria (2014)
Já a Notação de Objetos JavaScript (JSON) conforme Crockford (2006), é
um formato para representação textual de dados, em objetos. Suas principais
características vantajosas são os fatos de ser leve e simplificada. Baseada em
JavaScript, consegue descrever diferentes tipos de dados como por exemplo objetos
e arrays. Por consumir menos banda e ser mais intuitiva que XML torna-se ideal
para transferência de dados, sendo comum sua utilização em projetos de
WebServices baseados em RESTful.
Neste formato, diferentemente de XML o qual se trabalha com tags, usamos
uma coleção de pares constituídos por um nome e um valor respectivamente, ou
uma lista ordenada de valores (array), tornando assim este formato mais simples
para ler e escrever e muito mais ágil na transferência de dados.
Na Figura 5, temos um exemplo de arquivo no formato JSON, o qual possui
uma lista de dados chamado “MinhaLista” e dentro dela temos os dados de “nome” e
“fone”, que por sua vez são os objetos desta lista.
Figura 5 - Exemplo de arquivo JSON
Fonte: Própria (2014)
3 DISTRIBUIÇÃO DE SERVIÇOS DA ARQUITETURA AGROMOBILE
UTILIZANDO WEBSERVICES
Neste capitulo será apresentada a arquitetura AgroMobile, bem como o
objetivo principal deste trabalho que é o desenvolvimento de WebService para
interligação da mesma exemplificando o código-fonte do software. Também é
apresentado um protótipo do projeto para comprovar o pleno funcionamento na
utilização do WebService.
3.1 Informações do Projeto AgroMobile com WebServices
O projeto AgroMobile, a partir de estudos relacionados nas áreas de
Computação Móvel, Ubíqua e Aplicada na Agricultura de Precisão, tem como
objetivo o desenvolvimento de uma arquitetura de software, e com essas
ferramentas auxiliar engenheiros agrônomos e técnicos agrícolas na tomada de
decisões mais precisas para se ter um bom gerenciamento dos negócios, evitando
desperdícios de insumos e consequentemente minimizando o impacto ambiental.
Como parte desta arquitetura, este trabalho tem como principal objetivo criar
interfaces na forma de WebServices a fim de interligar os módulos da arquitetura
AgroMobile, visando prover serviços para que se possam gravar, excluir, alterar e
consultar as informações entre eles.
Estas interfaces baseiam-se na estrutura dos dados utilizados na arquitetura
do banco de dados. Para isto, a modelagem das informações no diagrama lógico
das tabelas do banco de dados (Figura 6) utilizado pelo sistema é fundamental para
que se tenha o sincronismo com os WebServices. O banco de dados relacional
utilizado pela Arquitetura AgroMobile foi o Postgres com a extensão PostGIS da qual
dá suporte a dados geo-referênciados e é de distribuição livre.
Figura 6 - Diagrama Lógico da Modelagem da Informação
Fonte: Própria (2014)
A arquitetura de software representada na Figura 7 resume o AgroMobile.
Nele contamos com uma rede de sensores distribuídos em nós que farão as coletas
dos dados na lavoura transmitindo-os ao coletor de dados, que por sua vez faz a
filtragem das informações e envia ao seu WebService para a persistência destes
dados no banco. As ontologias são a base de conhecimento modelada, elas fazem o
raciocínio dos dados obtidos dos sensores e dos informados pelos dispositivos
(App/Web). Possui duas formas de utilização do sistema, sendo uma baseada em
um aplicativo desenvolvido para Android e a outra forma via Web HTTP, onde
ambas terão sincronismo com os dados através dos WebServices.
Figura 7 - Arquitetura de software
3.2 Desenvolvimento dos WebServices
O desenvolvimento dos WebServices destina-se a interligação entre os
módulos da arquitetura, fazendo o gerenciamento do fluxo das informações,
garantindo o pleno funcionamento do AgroMobile. O padrão REST, se baseia em
métodos padrões da HTTP Web como GET, PUT, POST e DELETE e tem como
foco principal explorar estes métodos com seus chamados recursos, que nada mais
são que os endereços das URLs a serem utilizados.
Para o desenvolvimento do WebService é necessário utilização de algumas
tecnologias, onde para mapeamento das tabelas do banco de dados foi utilizado o
framework Hibernate. Ele oferece todas as ferramentas para o serviço web estar em
plena comunicação com a base de dados (BAUER; KING, 2005). Também foi
utilizada a API Jersey que é open source e mantida pela Oracle e que possui as
especificações da Interface de Programação de Aplicativos (API) JAX-RS das quais
se baseiam em anotações. Estas anotações são feitas nas classes do projeto, como
por exemplo: @Path, @Get, @Put, @Post, @Delete, @Produces, @Consumes,
@PathParam entre outras, que servem para simplificar a necessidade extra de
configurações. Na Tabela 1, veremos a utilidade das principais anotações do nosso
projeto.
Tabela 1 - Anotações e sua Funcionalidade
ANOTAÇÃO FUNÇÃO
@GET HTTP GET lista os recursos
@PUT HTTP PUT atualiza um recurso
@POST HTTP POST adiciona um recurso
@DELETE HTTP DELETE remove um recurso
@PATH Configura o caminho do recurso
@PRODUCES Indica qual o tipo de conteúdo será produzido pelo método ao
devolver a requisição
@CONSUMES Indica qual o tipo de arquivo que espera receber para trata-lo
@STATELESS Reconhece cada requisição como uma requisição nova
@PERSISTENCECONTEXT
Local de armazenamento dos objetos (entidades) que estão sendo manipuladas pelo EntityManager (responsável pelo sincronismo com o banco de dados, gerenciando o ciclo de vida da entidade)
@OVERRIDE Anotação de que o método é uma reescrita
@ENTITY Informa que a classe é uma tabela do banco de dados
@TABLE Indica o nome da tabela do banco em questão
@NAMEDQUERIES Especificação de uma consulta estática no banco de dados
@COLUMN Indica o nome da coluna da tabela em questão
@NOTNULL Indica que o valor do objeto não pode ser nulo
@SIZE Indica os limites de tamanho do elemento especificado
Fonte: Própria (2014)
Para rodar o WebService RESTful, necessita-se de um Web Container, do
qual utilizaremos o servidor de aplicação Java EE com o Glassfish, que por sua vez
já possui tal implementação.
Visando uma melhor organização, o desenvolvimento dos WebServices
REST em Java foram divididos em três pacotes conforme suas funções. Abaixo, a
Figura 8 ilustra o diagrama de pacotes do desenvolvimento.
Figura 8 - Diagrama de Pacotes dos WebServices.
Fonte: Própria (2014)
O WebService é composto pelo pacote config, entidades e recursos os quais
serão explanados nas próximas seções.
3.2.1 Pacote Config
As classes do pacote config são as classes padrões utilizadas por todos os
recursos do projeto. Neste pacote temos a classe ApplicationConfig que tem a
função de adicionar todos os recursos que possuímos e também definir parte da
URL com o ApplicationPath, que será utilizada para chamar os recursos. Esta classe
é ilustrada abaixo na Figura 9.
Figura 9 - Classe ApplicationConfig
Fonte: Própria (2014)
Neste mesmo pacote config também temos a classe AbstractFacade, ou
Fachada Abstrata, nela contém métodos genéricos do projeto como salvar, editar,
excluir e encontrar (Figura 10), os quais são relacionados a persistência dos dados.
Esta classe serve como modelo para as subclasses e não permite instanciá-la.
Figura 10 - Métodos genéricos da classe AbstractFacade
3.2.2 Pacote entidades
No pacote entidades, estão às classes POJO (Plain Old Java Objects) as
quais possuem os getters, setters, anotações das características relacionadas às
tabelas do banco de dados (mapeamento) e métodos utilizados pelo Hibernate para
persistência. No diagrama de classes apresentado na Figura 11 são ilustradas as
classes que compõe este pacote.
Figura 11 - Diagrama de Classes do Pacote Entidades
Fonte: Própria (2014)
Estas classes, como mencionado anteriormente, possuem características
semelhantes, alterando de uma para outra apenas os nomes dos campos e os tipos
dos objetos conforme foram criadas as tabelas no banco de dados. Todas estas
classes iniciam com as anotações @Entity que as referenciam como uma entidade,
@Table que indica referente à qual tabela do banco de dados é a referida classe e
@XmlRootElement que indica que o mapeamento da classe ocorrerá em um
elemento XML. As anotações @NamedQueries são as possíveis consultas que
poderão ser realizadas para aquela entidade. Na sequência vem à classe principal
serializada com os atributos definidos e suas características, vindo a formar o
espelho da tabela do banco de dados e que será utilizada pelo framework Hibernate
em suas persistências. Na sequência, possuímos os getters e setters dos atributos
da classe para as manipulações dos referidos dados.
Como exemplo na Figura 12, temos o início da classe Tecnico do pacote
Figura 12 - Classe Técnico do Pacote Entidades.
Fonte: Própria (2014)
3.2.3 Pacote Recursos
Por fim o pacote recursos, hospedeiro das classes fachadas especificas de
cada recurso. Estas classes estendem a classe AbstractFacade que possuem os
métodos genéricos, e juntamente no parâmetro recebem a lista da classe entidade
(POJO) do recurso em questão. São nelas que possuímos o final do endereço da
URL que vimos na classe ApplicationConfig, o qual vamos utilizar o WebService e
destinar os dados a determinada entidade. É aqui que possuímos os métodos
padrões HTTP dos quais o REST faz uso, sendo que estes são desenvolvidos
igualmente para todas as classes contidas neste pacote, alterando apenas as
entidades a serem trabalhadas pela classe. No diagrama de classes apresentado na
Figura 13 são ilustradas as classes que compõe o pacote recursos.
Figura 13 - Diagrama de Classes Pacote Recursos
Fonte: Própria (2014)
Nestas classes contamos com alguns recursos específicos do tipo
anotações que serão abordados a seguir. Ao iniciarmos a classe fachada de um
recurso, a anotação @Stateless tem a função de reconhecer a cada requisição
como uma requisição nova, isto é uma característica do padrão REST, em seguida,
a anotação @Path é onde configura o caminho do recurso, no exemplo abaixo
(Figura 14) o caminho deste recurso ficaria
“http://.../webresources/tecnico” sendo
que o
“webresource” vem da classe ApplicationConfig que vimos anteriormente,
completando a URL com o “tecnico” do Path da classe TecnicoFacadeREST.
Figura 14 - Exemplo do Inicio da Classe Fachada.
Fonte: Própria (2014)
Em seguida, contamos com o método local create exemplificado abaixo na
Figura 15, que por ter a anotação @POST terá a função de incluir dados no banco.
Para isto, é preciso ter a anotação @Consumes especificando qual o tipo de
formatação de dados se espera receber, neste caso estamos trabalhando com
informações no formato JSON. Ao receber estes dados é povoada a entidade da
qual foi feita a requisição do recurso e por fim o método create da classe
AbstractFacade que foi estendida é invocado passando a entidade para persistência
Figura 15 - Exemplo Método Create (POST)
Fonte: Própria (2014)
Já o outro método local chamado edit conforme abaixo exemplificado na
Figura 16, possui a anotação @PUT que tem como função a alteração de dados já
gravados no banco. Para isto é preciso da anotação no método @Path recebendo o
identificador do registro na tabela a ser alterada, juntamente com os dados alterados
no formato JSON através da anotação @Consumes. Igualmente no método anterior,
ao receber estas informações será povoada a entidade e invocado o método edit da
classe AbstractFacade para a persistência no banco.
Figura 16 - Exemplo Método Edit (PUT)
Fonte: Própria (2014)
Para fazer a exclusão de um registro do banco de dados é utilizado o
método local remove com a anotação @DELETE, que também recebe através do
@Path no método, o identificador do registro a ser eliminado na tabela do banco de
dados. Para tal execução, é invocado o método padrão remove da classe
AbstractFacade concatenado ao método find desta mesma classe que tem como
função encontrar na tabela especifica o identificador passado no parâmetro para
finalmente excluí-lo. Abaixo na Figura 17 tem-se o exemplo deste método de
remoção.
Figura 17 - Exemplo Método Remove (DELETE)
Fonte: Própria (2014)
Finalizando as classes do pacote recursos, contamos com o método local
find que atrelado à anotação @GET tem a função de retornar uma pesquisa feita
através do identificador do registro. Para isto, é necessária a anotação no método
@Path indicando
que deverá receber o “id” a ser encontrado na tabela, e,
diferentemente dos demais métodos ao invés de consumir dados, este irá produzir
dados para o retorno da informação a quem a solicitou utilizando a anotação
@Produces indicando o formato do retorno, que neste caso também é JSON. Após
receber este identificador é invocado o método find da classe AbstractFacade que
fará a pesquisa e retornará os dados solicitados. O exemplo do método de pesquisa
consta na Figura 18.
Figura 18 - Exemplo Método Find (GET)
Fonte: Própria (2014)
3.3 Protótipo para AgroMobile
Nesta seção, é apresentado um protótipo desenvolvido em Java baseado
em RESTful com padrão de troca de dados JSON, utilizando banco de dados
Postgresql. O caso em questão corresponde ao envio de dados a partir de um
módulo Arduíno para o WebService, simulando dados coletados dos sensores e
gravando estes no banco de dados para que posteriormente sejam feitas possíveis
consultas ou alertas a serem enviados ao agricultor.
Devido ao foco do trabalho não ser a parte do banco de dados e nem do
cliente que irá consumir o WebService, será abordado somente as partes básicas
destes dois elementos para que se possa entender e provar o pleno funcionamento
do WebService. Abaixo na Figura 19, o esquema do protótipo em questão.
Figura 19 - Esquema do Protótipo
Fonte: Própria (2014)
A tabela do banco de dados para gerar este modelo chama-se “leituras”,
aonde serão armazenados dados dos sensores que serão enviados ao coletor que
posteriormente enviará as mesmas para o WebService, que fará a persistência dos
dados nesta tabela. Sua estrutura é mostrada na Figura 20.
Figura 20 - Estrutura lógica da tabela leituras.
Em relação ao Cliente que consumirá o WebService, precisamos de uma
classe POJO com os atributos da tabela “leituras” para que possam ser criados os
objetos para enviar ao recurso desejado do WebService. Para o envio destes dados
é necessário uma classe aonde seja criado um Cliente, um recurso (caminho para
aonde enviar os dados), um método (create) para o qual se deseja enviar a
solicitação ao WebService (neste caso é um POST) e um método (close) que fecha
o Cliente após o envio dos dados. Na Figura 21, pode-se ver como ficou a classe
NewJerseyClient que executa estes procedimentos.
Figura 21 - Classe NewJerseyClient no Cliente.
Fonte: Própria (2014)
Estas duas classes descritas acima são chamadas pelo método mount
também no Cliente conforme ilustra na Figura 22, que tem a função de povoar a
classe POJO e chamar o método create da classe NewJerseyClient, afim de enviar
o arquivo no formato JSON ao WebService, e ao final fechar esta conexão do
Cliente.
Figura 22 - Método Mount no Cliente.
Como podemos obsevar na Figura 23, os dados enviados pelo Cliente
através do Arduíno estão sendo gravados com sucesso no banco de dados ao
passarem pelo recurso do WebService. Neste caso, está sendo feito um POST no
recurso Leituras que foi definido no Path do WebService.
Figura 23 - Retorno do Cliente ao Fazer POST no Recurso Leituras
Fonte: Própria (2014)
Constatou-se ainda, que ao fazer uma requisição via HTTP pelo browser no
recurso criado (Figura 24), retorna a lista em formato JSON dos dados inseridos na
tabela Leituras do banco de dados. Esta solicitação caracteriza uma consulta na
requisição GET.
Figura 24 - Consulta via HTTP GET no Recurso Leituras
Fonte: Própria (2014)
Com os códigos e os resultados apresentados acima, demonstra-se o pleno
funcionamento no WebService Leituras, o qual tem a finalidade de receber os dados
enviados pelos sensores ao coletor e este encaminhar ao WebService que
designará ao método create para fazer a inserção destas informações na tabela
Leituras do banco de dados.
CONCLUSÃO
Uma das atividades mais importantes na agricultura de precisão é o
acompanhamento do desenvolvimento da cultura em tempo real e a correção dos
fatores deficientes no instante em que é diagnosticado. A tecnologia possui técnicas
que podem auxiliar na identificação dos fatores que afetam a variação da
produtividade em áreas distintas da lavoura. Estes fatores podem ser a infestação
de pragas que atacam a plantação, de ervas daninhas que concorrem com a planta,
entre outros.
A agricultura de precisão é a nova tendência do mercado agrícola. As
vantagens que podem obter com ela são inúmeras, colheitas mais produtivas, uma
menor poluição devido ao uso reduzido de insumos e consequentemente uma
grande economia. Ela tende a se tornar cada vez mais comum nas propriedades
rurais. As tecnologias hoje existentes já permitem que se tenha um grande
conhecimento das variabilidades encontradas entre as diferentes áreas da
propriedade, o que já proporciona a tomada de decisões com base em dados mais
precisos.
Este trabalho demonstrou o desenvolvimento de uma aplicação na
linguagem de programação Java, baseada em WebServices aonde segue-se
padrões pré-definidos do RESTful juntamente com algumas tecnologias embutidas
como o framework Hibernate, a API Jersey com anotações do JAX-RS, dos quais
pode-se tirar o máximo de proveito no desenvolvimento, segurança e rapidez da
informação a fim de gerenciar o tráfego dos dados e fazer a sincronização entre os
módulos da arquitetura AgroMobile.
O padrão RESTful vem confirmar seu ótimo funcionamento em
WebServices, tornando sua utilização ideal em projetos que necessitam de agilidade
e eficiência na interoperabilidade entre as partes. Por utilizar métodos padrões
HTTP, torna-se amplamente acoplada a qualquer tipo de desenvolvimento em
diferentes linguagens de programação explorando toda arquitetura Web em seu
benefício.
Diante disto, com os recursos de WebServices desenvolvidos neste trabalho
a Arquitetura AgroMobile torna-se totalmente interligada entre seus diversos
módulos, proporcionando a interoperabilidade entre eles.
REFERÊNCIAS
ASSAD, Maria Leonor Lopes; ALMEIDA, Jalcione. Agricultura e sustentabilidade. Contexto, Desafios e Cenários. Artigo publicado Ciência & Ambiente, 2004.
AURÉLIO, Rafael; MORGENSTERN, Marcos; MARAN, Vinicius. UMA DEFINIÇÃO ONTOLÓGICA DO DOMÍNIO DE AGRICULTURA DE PRECISÃO PARA A ARQUITETURA AGROMOBILE. Salão do Conhecimento, 2013.
BAUER, Cristian; KING, Gavin. Java Persistence com Hibernate. Editora Ciência Moderna, 2005. BOEMO, Daniel, Desenvolvimento de Sistemas de Geoprocessamento e tecnologia móvel aplicados à agricultura de precisão. Santa Maria-RS, Abril 2011. Disponível em:
<http://cascavel.cpd.ufsm.br/tede/tde_busca/arquivo.php?codArquivo=3905> Acessado em 09/10/2013.
BRAY, Tim. et al. E.Extensible MarkupLanguage (XML) 1.0 (Fifth Edition), 2008. Disponível em: <http://www.w3.org/TR/REC-xml>, Acessado em 02/11/2013.
CAMPANHOLA, C. Novos significados e desafios. Brasília, DF: Embrapa Informação Tecnológica, 2004.
COMISSÃO DE QUÍMICA E FERTILIDADE DO SOLO. Manual de adubação e de calagem para os estados do Rio Grande do Sul e Santa Catarina. SBCS/NRS. Porto Alegre, 2004.
CROCKFORD, Douglas. JavaScript Object Notation (JSON), Julho 2006. Diponível em <http://www.ietf.org/rfc/rfc4627.txt?number=4627>, Acessado em 02/11/2013.
DUARTE, Katia C.; FALBO, Ricardo A. Uma ontologia de qualidade de software. In: Workshop de Qualidade de Software, João Pessoa. 2000.
EMBRAPA. Rede Agricultura de Precisão (AP 2). O que é Agricultura de Precisão?. Disponível em: <http://www.macroprograma1.cnptia.embrapa.br/redeap2/o-que-e-agricultura-de-precisao> Acessado em 20/11/2013.
GRUBER, Thomas R. Toward principles for the design of ontologies used for knowledge sharing?. International journal of human-computer studies,1995.
KIRSCHNER, S. F. ; MARAN, V. . Um Sistema de Auxílio à Coleta de Dados na Área de Agricultura de Precisão Baseada em Aplicações Móveis. In: XX Seminário de Iniciação Científica - Salão do Conhecimento 2012 - Unijuí, 2012, Ijuí.
MORGENSTERN, M. S. ; AURELIO, R. ; ALVES, R. ; MARAN, V. . Definição de uma Rede de Sensores para a Arquitetura AgroMobile. In: XII Simpósio de Informática da UNIFRA (SIRC), 2013, Santa Maria - RS. Anais do XII Simpósio de Informática da UNIFRA (SIRC), 2013.
OLIVEIRA, Leonardo Eloy. Estado da arte de banco de dados orientados a documento, 2009. Monografia (Conclusão do Curso de Graduação em Ciências Tecnológicas)–Universidade de Fortaleza –UNIFOR, Ceára, 2009.
SILVA, Grace Kelly de Castro; PEREIRA, Patrícia Maria; MAGALHÃES, Geovane. Disponibilização de Serviços Baseados em Localização via Web Services. In: Simpósio Brasileiro de
GeoInformática, GeoInfo. 2004.
SOAP, 2003, “Simple Object Access Protocol” (27 de abril, 2007); Disponível em <http://www.w3.org/TR/soap12 >. Acessado em 02/11/2013.
SUMRA, Rajesh. “Developing JAX-RPC-Based Web Services Using Axis and SOAP”, 2003. Disponível em:
<http://www.developer.com/open/article.php/2237251/Developing-JAX-RPCndashBased-Web-Services-Using-Axis-and-SOAP.htm>, Acessado em 01/11/2013. ZAVALIK, Claudimir. Integração de sistemas de informação através de web services. 2004. Dissertação de Mestrado (Programa de Pós Graduação em Computação)–Universidade Federal do Rio Grande do Sul. Porto Alegre, 2004.
APÊNDICE A
– Classes do Pacote Config
Classe AbstractFacade.java
package config; import java.util.List;
import javax.persistence.EntityManager;
public abstract class AbstractFacade<T> { private Class<T> entityClass;
public AbstractFacade(Class<T> entityClass) { this.entityClass = entityClass;
}
protected abstract EntityManager getEntityManager();
public void create(T entity) {
getEntityManager().persist(entity); }
public void edit(T entity) {
getEntityManager().merge(entity); }
public void remove(T entity) {
getEntityManager().remove(getEntityManager().merge(entity)); }
public T find(Object id) {
return getEntityManager().find(entityClass, id); }
public List<T> findAll() {
javax.persistence.criteria.CriteriaQuery cq =
getEntityManager().getCriteriaBuilder().createQuery(); cq.select(cq.from(entityClass));
return getEntityManager().createQuery(cq).getResultList(); }
public List<T> findRange(int[] range) {
javax.persistence.criteria.CriteriaQuery cq =
getEntityManager().getCriteriaBuilder().createQuery(); cq.select(cq.from(entityClass));
javax.persistence.Query q = getEntityManager().createQuery(cq); q.setMaxResults(range[1] - range[0] + 1);
q.setFirstResult(range[0]); return q.getResultList(); }
public int count() {
javax.persistence.criteria.CriteriaQuery cq =
getEntityManager().getCriteriaBuilder().createQuery(); javax.persistence.criteria.Root<T> rt = cq.from(entityClass); cq.select(getEntityManager().getCriteriaBuilder().count(rt)); javax.persistence.Query q = getEntityManager().createQuery(cq); return ((Long) q.getSingleResult()).intValue();
} }
Classe ApplicationConfig.java
package config; import java.util.Set;
import javax.ws.rs.core.Application;
@javax.ws.rs.ApplicationPath("webresources") public class ApplicationConfig extends Application {
@Override
public Set<Class<?>> getClasses() {
Set<Class<?>> resources = new java.util.HashSet<>(); addRestResourceClasses(resources);
return resources; }
private void addRestResourceClasses(Set<Class<?>> resources) { resources.add(recursos.AnoagricolaFacadeREST.class); resources.add(recursos.CidadeFacadeREST.class); resources.add(recursos.CultivaresFacadeREST.class); resources.add(recursos.CulturaFacadeREST.class); resources.add(recursos.EspeciemFacadeREST.class); resources.add(recursos.EstadioFacadeREST.class); resources.add(recursos.EventoscFacadeREST.class); resources.add(recursos.GlebaFacadeREST.class); resources.add(recursos.GlebasvinculadasFacadeREST.class); resources.add(recursos.ItemplanjFacadeREST.class); resources.add(recursos.LeiturasFacadeREST.class); resources.add(recursos.MonitoramentoFacadeREST.class); resources.add(recursos.PlanejamentoFacadeREST.class); resources.add(recursos.PontoamostraFacadeREST.class); resources.add(recursos.ProdutoFacadeREST.class); resources.add(recursos.ProdutorFacadeREST.class); resources.add(recursos.PropriedadeFacadeREST.class); resources.add(recursos.SafraFacadeREST.class); resources.add(recursos.TecnicoFacadeREST.class); resources.add(recursos.VariedadesFacadeREST.class); resources.add(recursos.VariedadesglebaFacadeREST.class); } }
APÊNDICE B
– Classes do Pacote Entidades
Classe Anoagriola.java
package entidades; import java.io.Serializable; import java.util.Collection; import javax.persistence.Basic; import javax.persistence.CascadeType; import javax.persistence.Column; import javax.persistence.Entity; import javax.persistence.GeneratedValue; import javax.persistence.GenerationType; import javax.persistence.Id; import javax.persistence.NamedQueries; import javax.persistence.NamedQuery; import javax.persistence.OneToMany; import javax.persistence.Table; import javax.validation.constraints.Size; import javax.xml.bind.annotation.XmlRootElement; import javax.xml.bind.annotation.XmlTransient; @Entity @Table(name = "anoagricola") @XmlRootElement @NamedQueries({@NamedQuery(name = "Anoagricola.findAll", query = "SELECT a FROM Anoagricola a"),
@NamedQuery(name = "Anoagricola.findByIdAnoagricola", query = "SELECT a FROM Anoagricola a WHERE a.idAnoagricola = :idAnoagri cola"), @NamedQuery(name = "Anoagricola.findByDescricao", query = "SELECT a FROM Anoagricola a WHERE a.descricao = :descricao"), @NamedQuery(name = "Anoagricola.findByAnoinicial", query = "SELECT a FROM Anoagricola a WHERE a.anoinicial = :anoinicial"), @NamedQuery(name = "Anoagricola.findByCondicao", query = "SELECT a FROM Anoagricola a WHERE a.condicao = :condicao"),
@NamedQuery(name = "Anoagricola.findByFlagSincronizacao", query = "SELECT a FROM Anoagricola a WHERE a.flagSincronizacao = :flagSincronizacao")})
public class Anoagricola implements Serializable {
private static final long serialVersionUID = 1L; @Id
@GeneratedValue(strategy = GenerationType.IDENTITY) @Basic(optional = false)
@Column(name = "id_anoagricola") private Integer idAnoagricola;
@Size(max = 25)
@Column(name = "descricao") private String descricao; @Size(max = 4)
@Column(name = "anoinicial") private String anoinicial; @Size(max = 1)
@Column(name = "condicao") private String condicao; @Size(max = 1)
@Column(name = "flag_sincronizacao") private String flagSincronizacao;
@OneToMany(cascade = CascadeType.ALL, mappedBy = "idAnoagricola") private Collection<Safra> safraCollection;
public Anoagricola() { }
public Anoagricola(Integer idAnoagricola) { this.idAnoagricola = idAnoagricola; }
public Integer getIdAnoagricola() { return idAnoagricola;
}
public void setIdAnoagricola(Integer idAnoagricola) { this.idAnoagricola = idAnoagricola;
}
public String getDescricao() { return descricao;
}
public void setDescricao(String descricao) { this.descricao = descricao;
}
public String getAnoinicial() { return anoinicial;
}
public void setAnoinicial(String anoinicial) { this.anoinicial = anoinicial;
}
public String getCondicao() { return condicao;
}
public void setCondicao(String condicao) { this.condicao = condicao;
}
public String getFlagSincronizacao() { return flagSincronizacao;
}
public void setFlagSincronizacao(String flagSincronizacao) { this.flagSincronizacao = flagSincronizacao;
}
@XmlTransient
public Collection<Safra> getSafraCollection() { return safraCollection;
}
public void setSafraCollection(Collection<Safra> safraCollection) { this.safraCollection = safraCollection;
}
@Override
public int hashCode() { int hash = 0;
hash += (idAnoagricola != null ? idAnoagricola.hashCode() : 0); return hash;
}
@Override
if (!(object instanceof Anoagricola)) { return false;
}
Anoagricola other = (Anoagricola) object;
if ((this.idAnoagricola == null && other.idAnoagricola != null) || (this.idAnoagricola != null && !this.idAnoagricola.equals(other.idAnoagricola))) { return false; } return true; } @Override
public String toString() {
return "entidades.Anoagricola[ idAnoagricola=" + idAnoagricola + " ]"; } }
