MODELO DE API REST PARA INTEGRACAO DE SISTEMAS BIOMETRICOSAGNOSTICOS

Joao N. C. Galvao∗ Fabrizzio A. A. M. N. Soares∗ Priscila Marques Kai∗

∗Universidade Federal de Goıas - Instituto de InformaticaAlameda Palmeiras, Quadra D - Campus Samambaia - CEP 74690-900

Goiania, GO, Brasil

Email: jncgalvao@gmail.comfabrizzio.soares@gmail.compriscila.kai@hotmail.com

Abstract— Several entities are committed to the use of biometrics in the area of security, both in accesscontrol, as well as for the identification of investigated and crime prevention. The objective of this work is thecreation of a prototype of a tool developed within the approach of Services Web, associated to the developmentof an API that will aim at the standardization of the services of biometrics, with a view to the exchange of databetween biometric applications distinct and independent, with a low level of coupling and with interoperabilitybetween systems of different platforms and technologies to perform the task of personal identification.

Keywords— Automation, Biometrics, API, REST, SOA

Resumo— Varias entidades estao empenhadas na utilizacao da biometria na area de seguranca, tanto nocontrole de acesso, quanto para identificacao de investigados e prevencao de crimes. O objeto deste trabalho ea criacao de um prototipo de uma ferramenta desenvolvida dentro da abordagem de Servicos Web, associado aodesenvolvimento de uma API que visara a padronizacao dos servicos de biometria, tendo em vista o intercambiode dados entre aplicacoes biometricas distintas e independentes, com um nıvel reduzido de acoplamento e cominteroperabilidade entre sistemas de diferentes plataformas e tecnologias para executar a tarefa de identificacaopessoal.

Palavras-chave— Automacao, Biometria, API, REST, SOA

1 Introducao

A velocidade para se obter uma informacao so-bre um suspeito, uma pessoa de interesse, em umprocesso de investigacao civil ou criminal e crucialpara o bom desempenho da operacao. No entanto,adquirir uma informacao biometrica, seja a ima-gem de face, a impressao digital, o audio de umagravacao de voz, etc, nao e tao simples como po-deria ser. Isto ocorre em funcao da inexistenciade uma base central com os dados biometricos depessoas previamente inscritas nos diversos bancosde dados biometricos existentes no paıs. De modoque, tais dados estao espalhados pelas secretariasde seguranca de cada Estado e/ou Municıpio, queutilizam softwares biometricos distintos e desco-nectados. Assim, para a realizacao de uma pes-quisa, nos moldes atuais, e necessario o envio dee-mails para varias instituicoes, com o objetivo desolicitar a colaboracao para identificacao de taispessoas de interesse. Esse auxılio pode ser pres-tado atraves da utilizacao de um software ou atemesmo manualmente, o que retarda ainda mais oprocesso. Em vista disso, este artigo apresenta oprototipo de um Sistema Automatico de Biome-tria Modulado - mABIS, cuja arquitetura faz usode uma API REST capaz de centralizar e integrardiferentes bases biometricas atraves de ServicosWeb.

2 Servicos Web

Servicos Web, ou Web Services, conforme a lın-gua inglesa, nada mais sao do que ferramentasque possibilitam o compartilhamento de dados en-tre sistemas desenvolvidos em diferentes localida-des, fazendo uso de diversas tecnologias e pla-taformas. Tais sistemas podem ser construıdoscom base na Arquitetura Orientada a Servicos, ouSOA (Service-Oriented Architecture), que incor-pora uma serie de conceitos que visam assegurar ainteroperabilidade e flexibilidade exigidas por pro-cessos de negocios.

2.1 Arquitetura orientada a servicos

A arquitetura SOA tem como fundamento tres im-portantes aspectos: servicos, interoperabilidade ebaixo acoplamento.

Apesar de poder ser implementada atraves deServicos Web, a adocao da Arquitetura SOA naoesta necessariamente vinculada a uma determi-nada tecnologia. Nesse contexto, vale destacar queexistem duas principais formas de implementacaode Servicos Web: SOAP (Simple Object AccessProtocol, a forma mais tradicional de implementa-cao (Josuttis, 2007), e, a abordagem REST (RE-presentational State Transfer), uma opcao queesta em plena expansao, sobretudo em funcao deser de facil aprendizagem e integracao, razao pelaqual a utilizaremos nesse trabalho, tendo em vistao desenvolvimento de Web APIs RESTful, con-forme detalharemos a seguir.

XIII Simposio Brasileiro de Automacao Inteligente

Porto Alegre – RS, 1o – 4 de Outubro de 2017

ISSN 2175 8905 84

2.2 REST

Recursos formam a base dos princıpios REST epodem ser qualquer informacao que se deseja tor-nar acessıvel a clientes remotos, e que sao endere-cados atraves de um identificador unico, denomi-nado URI (Uniform Resource Identifier).

Uma URI esta sempre associada a pelo me-nos uma representacao, que pode estar disponıvelem diferentes formatos, como XML, JSON, TXT,PDF, HTML e assim por diante. As representa-coes sao obtidas atraves da emissao de pedidos aosservicos Web fornecidos por uma aplicacao REST-ful. Uma implementacao RESTful e aquela quesegue as restricoes definidas pelo estilo arquiteto-nico REST.(Salvadori and Siqueira, 2015)

2.3 JASON

Uma das representacoes de recurso mais utili-zadas em Servicos Web REST e a que utili-zaremos neste trabalho e o JSON (Richardsonet al., 2013), que nada mais e do que uma formatextual de representacao de dados estruturados emum conjunto de pares no formato de nome/valor(Crockford, n.d.).

JSON e muito utilizado no intercambio de in-formacoes, haja vista ser independente de lingua-gem de programacao, alem de ser de facil criacao,manipulacao e analise (Sporny et al., n.d.).

2.4 Web APIs

O termo Web API e utilizado para designar Ser-vicos Web que utilizam os princıpios arquiteturaisREST (Richardson et al., 2013). Neste cenario,cada aplicacao possui sua propria base de dados,sem compartilha-la com demais sistemas. As in-formacoes sao expostas atraves de Web APIs, queformam uma camada de integracao. Os dadossao representados em formatos estabelecidos, ge-ralmente JSON e XML, e transportados atravesdo protocolo HTTP. Com esta abordagem de in-tegracao, a Web se torna uma infraestrutura paraconstrucao de sistemas distribuıdos.

Este modelo de integracao possui a vantagemde reduzir o acoplamento entre as aplicacoes, pos-sibilitando a evolucao em ritmos diferentes, semgrandes impactos nas demais aplicacoes, pois al-teracoes nos modelos de dados nao influenciam di-retamente na integracao. Outro ponto positivo ea possibilidade da integracao se estender para forados domınios da organizacao, em funcao do fatode nao ser necessario que a base de dados sejacompartilhada, tal como ilustrado na Figura 1 ,em vez disso, apenas os dados selecionados e pro-tegidos por controle de acesso precisam ser dispo-nibilizados, o que proporciona maior abrangenciade integracao, veja Figura 2 . Por outro lado,e necessario acrescentar a complexidade de imple-mentacao de uma camada extra, na forma de uma

API que sera responsavel por realizar e atenderchamadas a outras Web APIs, alem de conver-ter os dados nos formatos estipulados (Richardsonet al., 2013).

Figura 1: Compartilhamento de base de dados entreaplicacoes

Figura 2: Modelo de aplicacoes distribuıdas atravesde Web APIs

Na integracao atraves da base de dados, asaplicacoes podem executar operacoes de consulta,criacao, alteracao e remocao de dados.

XIII Simposio Brasileiro de Automacao Inteligente

Porto Alegre – RS, 1o – 4 de Outubro de 2017

85

2.5 Especificacao OpenAPI

A Especificacao OpenAPI, e uma especificacaopara arquivos de interface legıveis por maquinapara descrever, produzir, consumir e visualizarservicos da Web RESTful. Emergiu para permitirque tanto humanos quanto maquinas compreen-dam os Servicos Web sem acessar seu codigo-fonte(Initiative, n.d.), padronizando o processo de de-finicao das APIs RESTful.

3 Arquitetura

A plataforma mABIS fornece uma modelagem queauxilia nas tarefas de analise biometrica disponı-veis pelos servicos a ela agregados. Com isso, deacordo com as tarefas de processamento viabili-zadas por cada servico, pode-se realizar diversastarefas tais como: verificacao e identificacao bi-ometricas; deteccao e extracao de caracterısticaspara analise forense, entre outras.

Com intuito de dividir o problema e conse-quentemente facilitar sua construcao e utilizacao,o mABIS adotou a seguinte divisao: camada apli-cativo, camada gerenciadora de servicos e camadade servicos biometricos.

Figura 3: Visao arquitetural das camadas da mABIS

Na figura Figura 3 e apresentada uma vi-sao arquitetural das camadas. Na primeira ca-mada, localizam-se os aplicativos front-end utili-zados como interface para o usuario. Pretende-se que, atraves dessa modelagem, seja possıvel autilizacao dos servicos de biometria em diversasplataformas, tais como: plataforma desktop, pla-taforma mobile e plataforma web. A segunda ca-mada e um servico que pode ser disponibilizado

na rede local ou na internet, de modo a facili-tar a acessibilidade do sistema em qualquer parte.Nessa camada, sao armazenadas as configuracoesde todo o sistema e os arquivos biometricos for-necidos. Alem disso, essa camada e responsavelpor gerenciar os servicos biometricos concedidospela terceira camada, chamada de servicos biome-tricos, onde sao fornecidos os servicos biometricoscriados por outros desenvolvedores de qualquer lu-gar e com o uso de qualquer tecnologia, desde quemantenha o padrao de comunicacao da API.

3.1 Diagrama de caso de uso

Tendo em vista o nıvel de simplicidade da API,podemos observar na Figura 4 a quantidade re-duzida de comandos. Os programadores de bio-metria criarao seus BSPs (Biometric Service Pro-vider) na linguagem e arquitetura preferıvel, se-guindo os requisitos do padrao da API-BSP pro-posta. O administrador apenas necessitara cadas-trar o endereco (URL) do recurso principal no sis-tema de gerenciamento de servicos. O proprio sis-tema entrara em contato com o servico para bus-car as configuracoes necessarias.

O usuario investigador tera as seguintes acoesbasicas:

Cadastrar arquivos biometricos. Nessaacao sera possıvel cadastrar os mais variados ti-pos de arquivos biometricos, como por exemplo,imagens, audio, fotos, etc. Essa acao e destinadaapenas para o carregamento do arquivo no ser-vidor para fins de armazenamento, facilitando oreuso e evitando duplicidade.

Criar uma atividade de pesquisa. Nessaacao, o investigador iniciara uma pesquisa no sis-tema. Para tanto, escolhera o BSP que deseja uti-lizar. Ao escolher o BSP, recebera dinamicamenteas opcoes de tarefas fornecidas por ele. Nesse mo-mento, o sistema nao se preocupara em possuiras opcoes de tarefas fixas, ou seja, em obter oscomandos e arquivos suportados de modo perma-nente pelo BSP, em vez disso, solicitara as infor-macoes de tarefas, arquivos e metadados do ser-vidor de BSP, para que o usuario escolha o quedeseja processar.

Consultar o resultado da pesquisa. Aposa finalizacao da atividade, o investigador poderaconsultar o resultado fornecido pelo servico, naforma de um arquivo de dados em formato PDF.Esse esquema simples tem como objetivo tornar osistema dinamico e desacoplado.

3.2 Recursos da API

Nossa proposta divide a modelagem do sistemaem duas APIs.

A primeira API chama-se API APP que temcomo finalidade definir o relacionamento entre osaplicativos e o servidor de gerenciamento de ser-vicos. Ela possui os seguintes recursos: Usuarios,

XIII Simposio Brasileiro de Automacao Inteligente

Porto Alegre – RS, 1o – 4 de Outubro de 2017

86

Figura 4: Diagrama Geral de Casos de Uso

Atividades, Tarefas, BSPs, Metadados, Arquivose PessoasdeInteresse.

O recurso Usuarios representa os usuarios dosistema; o recurso Atividades diz respeito as ativi-dades de pesquisas criadas pelo usuario; o recursotarefas corresponde as tarefas de pesquisas dispo-nibilizadas pelos BSPs; o recurso BSPs se refereaos provedores de servicos biometricos disponibili-zados no sistema; o recurso Metadados representaos informacoes dinamicas solicitadas pelo BSP; orecurso Arquivos tem como finalidade armazenaro endereco e as informacoes dos arquivos biome-tricos cadastrados no sistema; e, o recurso Pes-soasdeInteresse permite que os usuarios agrupemos arquivos de um mesmo indivıduo. A Figura5 demonstra os relacionamentos entre os recursosda API APP.

Figura 5: Diagrama de recursos da API APP

A segunda API do nosso sistema chama-seAPI-BSP que e responsavel pela comunicacao en-tre o gerenciador de servicos e os provedores deservicos biometricos (BSP). Para tanto ela possuios seguintes recursos: BSPs, Perfil, Tarefas, Me-tadados, Processamentos, Grupos e Arquivos.

O recurso BSPs representa os provedores deservico de biometria que estao disponıveis; o re-curso Perfil corresponde as configuracoes do BSPque serao fornecidas ao gerenciador de servico; orecurso Tarefas se refere as tarefas disponıveis noservico, a exemplo: reconhecimento e deteccao deface, ıris, impressoes digitais etc.; o recurso Meta-dados corresponde as informacoes especıficas quea tarefa necessita para ser executada, por exem-plo: idade, sexo, cor da pele etc.; o recurso Pro-cessamentos diz respeito as tarefas processadas eas informacoes de resultados obtidos por elas; orecurso Arquivos se refere aos arquivos biometri-

cos utilizados no processamento; e, o recurso Gru-pos trata do agrupamento de arquivos para a re-presentacao de uma pessoa individualmente ou decaracterısticas especıficas de pessoas de interesse,tal como raca, sexo, idade etc.

A Figura 6 demonstra os relacionamentosentre as recursos da API BSP.

Figura 6: Diagrama de recursos da API BSP

3.3 Diagrama de Sequencia

A comunicacao entre as tres camadas e realizadapor meio da API APP e da API BSP, de modoque a API APP e responsavel pela comunicacaoentre o aplicativo do usuario e o gerenciador deservicos. Ja a API BSP cuida da comunicacaoentre o gerenciador de servico e os diversos BSPscriados para a API. A comunicacao inicia-se como cadastro do BSP no gerenciador atraves da APIAPP, no modo administrador. Entao, o gerencia-dor busca o perfil solicitado atraves da API BSP.E permitido ao usuario cadastrar arquivos, ser-vicos e tarefas junto ao gerenciador por meio daAPI APP. Quando e criada uma atividade no ge-renciador, este se comunica com o BSP gerandoum processamento biometrico, iniciando-se umafuncao callback, de modo que ao termino do pro-cessamento o BSP informa ao gerenciador a con-clusao, enviando o resultado. Posteriormente, epossıvel ao usuario consultar a atividade criada,verificando o resultado do processamento. Paraexemplificar, veja a Figura 7 que demonstra acomunicacao com as chamadas das APIs.

3.4 Diagrama de Recursos da API

Buscando seguir o termos do padrao REST, cria-mos as URIs unicas para os recursos. Cada acao erealizada pelos verbos do HTTP e nao por cami-nhos na URIs. As representacoes dos recursos Ta-refas e Servicos possuem a propriedade Contextoque serve, de maneira generica, para informar aousuario sobre os proximos recursos disponıveis aserem utilizados, tal como no caso de um servicoque pode conter dez tipos de tarefas disponıveis,cujas caracterısticas sao informadas no Contexto.

A Figura 8 representa o Diagrama de Recur-sos da API APP, onde pode-se observar os relaci-onamentos entre os recursos.

XIII Simposio Brasileiro de Automacao Inteligente

Porto Alegre – RS, 1o – 4 de Outubro de 2017

87

Figura 7: Diagrama de Sequencia entre as camadas

Na Figura 9 e representado o Diagrama deRecursos da API BSP. Nao e permitido buscartodos os arquivos no servido do BSP, apenas umarquivo especıfico GET/arquivos/id. Ao criar umnovo processamento com POST/processamento einiciada a tarefa no servidor BSP, mas esta e sta-teless, assim o gerenciador ao gravar nao espera oresultado, pois nao tem estado a transacao. Fi-cando a cargo do servidor BSP de executar a cha-mada na url de callback. A unica acao possıvelpara o recurso perfil e GET/perfil onde neste epossıvel saber dados sobre o servidor, como, url-NovoEndereco que caso tenha, valor informa queo servidor tem novo endereco e que o gerencia-dor deve mudar para este, isso faz com que o sis-tema se autoatualize. Em ListaTarefasMetadadostemos um objeto JSON com as configuracoes detarefas e metadados disponıveis.

4 Prototipo

Para se analisar essa modelagem da API foi cons-truıdo um prototipo atendendo-se a modelagemda API. Esse prototipo foi desenvolvido consti-tuıdo por tres camadas: Cliente, Gerenciador deServicos e BSPs.

Na camada Cliente foi desenvolvida tres apli-cacoes front-end da seguinte maneira: a primeiraconsiste em uma Aplicacao Web, que faz uso doframework AngularJS 1, desenvolvida em Javas-cript, ver Figura 10 ; a segunda interface foi de-senvolvida com SDK Android 2 ver Figura 11 ;e, a terceira interface desktop, faz uso da IDE La-zarus 3, sendo compilada para Linux e Windows

1https://angularjs.org/2https://developer.android.com3http://www.lazarus-ide.org

Figura 8: Diagrama de Recurso da API APP

ver Figura 12 . Para a realizacao dos experimen-tos, foram utilizadas as imagens do conjunto ”FEIFace Database”(Thomaz, n.d.).

A camada Gerenciador de Servicos foi desen-volvida na linguagem Java com o framework JAX-RS/Jersey e banco de dados MySQL, com servidorCloud de arquivos.

Na terceira camada foram criados algunsBSPs de exemplo: Um BSP desenvolvido emC++, utilizando a biblioteca OpenCV 4 ; e o ou-tro desenvolvido em Java fazendo uma adaptacaopara uma API em outro formato. Neste momento,e preciso ressaltar que foi criada a documentacaoda API com o uso da ferramenta Swagger UI naespecificacao do OpenAPI 2, permitindo, dessaforma, que os desenvolvedores sejam capazes dede criar front-ends e BSPs com as facilidades daferramenta Swagger. As vantagens relacionadas

XIII Simposio Brasileiro de Automacao Inteligente

Porto Alegre – RS, 1o – 4 de Outubro de 2017

88

Figura 9: Diagrama de Recurso da API BSP

Figura 10: Tela aplicacao Web

Figura 11: Tela aplicacao Mobile

Figura 12: Tela aplicacao Desktop

ao uso dessa ferramenta sao inumeras, dentre asquais merecem destaque as seguintes: A documen-tacao da API atraira um maior numero de interes-sados para utiliza-la; como consequencia, haveramaior facilidade em estudar a API proposta; e,por fim, sera mais facil para o desenvolvedor criarexemplos e testar a API.

5 Conclusoes

Neste trabalho foi apresentado uma modelagempara a criacao de um Sistema Biometrico com acapacidade de incorporacao de novos provedoresbiometricos, de forma expansıvel e colaborativa.O uso do modelo SOA com REST possibilita umasolucao simples e de facil desenvolvimento para acriacao de novos BSPs, facilitando a integracao en-tre as diversas linguagens e plataformas. Todas astecnologias utilizadas na criacao foram de codigoaberto e gratuitas, tornando a evolucao do pro-jeto e futura continuacao um empreendimento debaixo custo, alem de permitir que essa arquiteturaseja de grande benefıcio para a area de segurancapublica no desempenho de sua tarefa de protegere garantir seguranca ao cidadao.

Referencias

Crockford, D. (n.d.). The application/jsonmedia type for javascript object no-tation (json). Disponıvel online emhttps://tools.ietf.org/html/rfc4627.

Initiative, O. (n.d.). Especificacao openapi. Dis-ponıvel online em https://www.openapis.org.

Josuttis, N. (2007). SOA in Practice: The Art ofDistributed System Design, O’Reilly Media.

Richardson, L., Amundsen, M., Amundsen, M.and Ruby, S. (2013). RESTful Web APIs,O’Reilly Media.

Salvadori, I. L. and Siqueira, F. (2015). A matu-rity model for semantic restful web apis., inJ. A. Miller and H. Zhu (eds), ICWS, IEEEComputer Society, pp. 703–710.

Sporny, M., Longley, D., Kellogg, G., Lantha-ler, M. and Lindstrom, N. (n.d.). Json-ld 1.1 a json-based serialization for linkeddata. Disponıvel online em http://json-ld.org/spec/latest/json-ld/.

Thomaz, D. C. E. (n.d.). Fei face da-tabase (on-line). Disponıvel online emhttp://fei.edu.br/cet/facedatabase.html.

XIII Simposio Brasileiro de Automacao Inteligente

Porto Alegre – RS, 1o – 4 de Outubro de 2017

89