soa-db: uma arquitetura orientada a serviÇo para...
TRANSCRIPT
1/4 XXII CBEB 2010
SOA-DB: UMA ARQUITETURA ORIENTADA A SERVIÇO PARA ACESSO
A DISPOSITIVOS BIOMÉDICOS
J. M. T. Lacerda*, B. G. Araújo*, G. B. Brandão**, A. M. G. Guerreiro**, R. A. M. Valentim**
*Departamento de Computação e Automação/Universidade Federal do Rio Grande do Norte, Natal,
Brasil
** Departamento de Engenharia Biomédica/Universidade Federal do Rio Grande do Norte, Natal,
Brasil
e-mail: [email protected], [email protected], Glá[email protected], [email protected],
Abstract: The great diversity in the architecture of
hardware devices allied to many communication
protocols, has been hindering the implementation of
systems that need to access these devices. Given these
differences, it appears the need of providing the
access of these devices in a transparent way. In this
sense, the present work proposes a Biomedical
Devices Service Oriented Architecture, as a way of
abstracting the writing and reading data
mechanisms in hardware devices, contributing this
way, for increasing systems productivity, as the
developers are just focused in their functional
requirements.
Palavras-chave: Monitoramento Remoto, Sinais
Biomédicos, Dispositivos Biomédicos, Arquitetura
Orientada a Serviço.
Introdução
A rápida disseminação de novos dispositivos de
hardware no mercado tem aumentado a complexidade
na comunicação entre esses. Segundo Valentim [1],
muitos dispositivos de hardware disponibilizam suas
funcionalidades através de protocolos proprietários, de
drivers que são dependentes de uma plataforma de
sistema operacional. Diante desse ambiente fechado e
heterogêneo de hardware, uma questão precisa ser
discutida, a interoperabilidade. Isso porque, quanto mais
divergentes forem, mais difícil e complexo serão os
mecanismos de integração. Esse aspecto torna-se ainda
mais forte quando se trata de arquiteturas proprietárias.
Essa problemática está ainda mais presente na área
biomédica, na qual muitos de seus dispositivos são
proprietários e, portanto, dificultam o acesso e
conseqüentemente o desenvolvimento de aplicações,
como por exemplo, o monitoramento de pacientes, a
aquisição de sinais biomédicos, entre outras.
Neste contexto, têm surgido propostas de arquitetura
orientada a serviço (Service Oriented Architecture –
SOA) para dispositivos de Hardware (SODA – Software
Oriented Device Architecture), como mecanismo para
construção de interfaces abertas na forma de acesso (I/O
– Input and output) aos dispositivos de qualquer
natureza, Scott, et. al, [2]. Todavia, apesar de ser uma
boa proposta, SODA é uma tecnologia que ainda não foi
validada. Nesta perspectiva, a proposta SOA-DB
contribui também para demonstrar a viabilidade SODA
através de testes experimentais.
No quesito monitoramento remoto de sinais
biomédicos, existem na literatura atual, alguns trabalhos
semelhantes, mas poucos apresentam resultados
concisos em termos numéricos. Dos que apresentam
esse dados, [3] e [4] podem ser citados.
Este trabalho tem como objeto de estudo, a proposta
de uma arquitetura orientada a serviço para acessar
dispositivos biomédicos, aqui intitulada de SOA-DB.
Essa arquitetura tem como proposta, abstrair (tornar
transparente) os mecanismos de escrita e leitura das
aplicações clientes que acessam os dispositivos
biomédicos, buscando, com essa abstração, alguns
benefícios, como o aumento da produtividade de
desenvolvimento, interoperabilidade e portabilidade.
Materiais e Métodos
Um desenvolvedor de sistemas, ao implementar uma
aplicação que precisa acessar um determinado
dispositivo de hardware, se depara com alguns
problemas:
Mecanismos de acesso do dispositivo;
Implementação dos métodos de acesso ao
dispositivo;
Lógica de negócio da aplicação passa a ficar
em segundo plano.
Esses problemas serviram de motivação para o
desenvolvimento da proposta SOA-DB, que
efetivamente é uma camada de software distribuída que
faz a intermediação entre as requisições e respostas
direcionadas aos dispositivos biomédicos.
A Figura 1 ilustra o SOA-DB inserido num ambiente
hospitalar extremamente heterogêneo, tanto nas
aplicações que acessam os dispositivos biomédicos,
quanto nos próprios dispositivos, ou seja, o SOA-DB
age como elemento de acesso entre as aplicações e os
dispositivos. Deste modo, tornando homogêneo o acesso
a esses.
ISSN 2179-3220 1558
2/4 XXII CBEB 2010
Desenvolvedores de aplicações que utilizam
linguagens de programação como Java, C# ou Python, e
qualquer outra que forneça suporte a SOA, poderão
acessar dispositivos de hardware sem a necessidade de
ter a implementação do acesso a esses dispositivos
dentro de suas aplicações.
Figura 1. O ambiente da SOA-DB
A Figura 1 apresenta requisições sendo realizadas
por aplicações clientes de forma remota, através de uma
arquitetura orientada a serviço, que no SOA-DB é
implementada através de Web Services [5].
Basicamente, são requisições feitas na linguagem de
programação nativa da aplicação, que necessita acessar
um dispositivo qualquer. Essas requisições operam
sobre o padrão W3C XML [6]. O código XML que
chega ao SOA-DB é processado, e posteriormente, com
base no processamento, o SOA-DB realiza o acesso ao
dispositivo de destino que aplicação cliente requisitou.
A comunicação realizada sobre a SOA-DB baseia-se
em um repositório de dispositivos, o qual permite a ela
identificar exatamente o dispositivo requisitado,
provendo deste modo, acesso transparente às aplicações
clientes.
A SOA-DB é composta de dois componentes
principais: A implementação das interfaces de
comunicação (API Mult-I/O) e a implementação de um
serviço baseado em SOA (Componente SOA).
A API Mult-I/O (Figura 2) integra as diferentes
implementações de acesso a dispositivos, tais como
USB, Serial, Paralela, IEEE 802. Essa API provê uma
única interface para a aplicação que servirá de base para
as requisições de I/O. As diferentes implementações são
definidas de acordo com a interface de comunicação que
o dispositivo implementa. Durante o processo que
estabelece a comunicação, a arquitetura SOA-DB utiliza
o padrão de projeto Factory Method [7], para criar uma
interface adequada ao dispositivo. Para isso é realizada
uma consulta ao Repositório de Dispositivos que
contém as informações pertinentes dos dispositivos
integrados ao SOA-DB.
A principal função da API Mult-I/O é abstrair o
protocolo de comunicação de acesso ao dispositivo
biomédico.
O componente SOA (Figura 3) terá como base o
framework SOAP, que é a implementação do protocolo
SOAP [8] direcionada a certa linguagem de
programação, ou seja, ele sofrerá variação de acordo
com a linguagem implementada. Por exemplo, o
Apache Axis [9] para a linguagem Java ou Nusoap [10]
para a linguagem PHP. O protocolo SOAP é
responsável pelo transporte das requisições e respostas
(mensagens em XML) pela rede.
Figura 2. A API Mult-I/O
O padrão W3C WSDL [11] descreve em serviços os
recursos disponibilizados pela implementação da
interface de comunicação.
O Componente SOA fornece a modelagem de um
dispositivo biomédico como um serviço remoto.
Figura 3. Descrição do Componente SOA
Para fins de testes, foram utilizados dois
microcomputadores Desktop e um notebook. Os
microcomputadores Desktop (Microcomputadores 1 e
2) possuem a mesma configiração: Pentium 4 HT, 3.2
Mhz, com 1 Gb de memória RAM e sistema operacional
Windows XP. Já o microcomputador notebook
(Microcomputador3) detém um processador Turion II
Mobile de 1.6 Mhz, 2Gb de memória RAM e sistema
operacional Windows XP.
Foram utilizados dois ambientes na realização dos
testes, com o intuito de demonstrar o custo causado pela
utilização da SOA-DB.
O primeiro ambiente (Figura 4) foi construído sem a
utilização da SOA-DB, apenas com uma aplicação local
(implementada na linguagem de programação Java - um
Eletrocardiograma - ECG – emulado) que teve a função
de ler os dados do paciente (Sinais reais de um paciente,
obtidos de um ECG real, através de um amplificador
customizado (de 2 pólos e passagem de banda de 0.5 a
120Hz) e digitalizados por um microcontrolador PIC
com taxa de freqüência de 225Hz. Esses dados foram
transformados em um vetor (que continha 1 minuto de
batimentos cardíacos) e transmitidos do
Microcomputador 2 para o Microcomputador3, através
da interface RS 232.
O segundo ambiente foi o estudo proposto, com a
inserção da SOA-DB para realizar o acesso ao ECG
emulado (Figura 5).
ISSN 2179-3220 1559
3/4 XXII CBEB 2010
O Microcomputador 1 se comportou como o Cliente
da SOA-DB. Foram implementadas duas aplicações
Cliente, uma com a linguagem de programação Java e
outra com a linguagem de programação C# .NET. Elas
acessaram a SOA-DB através de um WSDL.
Figura 4. Ambiente 1 - Cenário dos testes na ausência
da SOA-DB
Figura 5. Ambiente2 - Testes na presença da SOA-DB
O Microcomputador2 transmitiu os sinais do
paciente para o ECG emulado. A aplicação utilizada
para essa transmissão foi implementada na linguagem
Java.
O Micropomputador3 serviu de hospedeiro para a
SOA-DB, com três dispositivos registrados.
Fluxo dos testes:
1) Execução da aplicação de transmissão dos
sinais do paciente
2) Execução da SOA-DB (Aguardando
requisições)
3) Requisição da aplicação ao ECG registrado na
SOA-DB
4) Resposta da SOA-DB
Resultados
A Figura 6 é um gráfico dos dados extraídos do
ECG real, apresentada em Volts por segundos, para um
tempo de 60 segundos de batimentos cardíacos.
A Tabela 1 apresenta os resultados dos dois
ambientes de testes, para uma taxa de amostragem de
100 acessos. O Tempo de Resposta pode ser descrito
como o tempo em que o dispositivo é acessado pela
aplicação cliente.
As Figuras 7 e 8 ilustram os tempos de resposta para
os testes do Ambiente2.
Discussão
A viabilidade da SOA-DB foi constatada, devido à
pequena variação de acesso entre o Ambiente1 (forma
convencional de acesso) e o Ambiente2 (SOA-DB).
Essa diferença ficou na ordem de 80 milissegundos.
Figura 6. Dados do ECG
0 10 20 30 40 50 60 70 80 90 1001050
1100
1150
1200
1250
1300
1350
1400
1450
1500
1550
Requisição
Tem
po d
e r
esposta
(m
ilissegundos)
Figura 7. Tempo de resposta para o monitoramento do
ECG (Aplicação Cliente Java)
0 10 20 30 40 50 60 70 80 90 1001000
1050
1100
1150
1200
1250
1300
Requisição
Tem
po d
e r
esposta
(m
ilissegundos)
Figura 8. Tempo de resposta para o monitoramento do
ECG (Aplicação Cliente C#)
Uma pequena variação entre os tempos de resposta
das aplicações cliente que acessaram os dados do ECG,
de 30 milissegundos, mostrou a homogeneidade da
SOA-DB diante da alternância das aplicações que
acessam os seus dispositivos, de modo que essa
alternância variou muito pouco o resultado final para a
aplicação cliente.
Em [3] foi utilizado o monitoramento remoto de
sinais biomédicos, Home Health-Care, mas com um
conceito distinto. No trabalho em questão, o
monitoramento dos dados biomédicos foi projetado para
ser realizado no ambiente hospitalar, enquanto que em
[3] foi proposto o monitoramento fora desse ambiente,
envolvendo um investimento muito maior em infra-
estrutura, através de Care Centers. Apesar da diferença
entre as plataformas, os tempos de resposta no acesso
aos dispositivos biomédicos foram similares, na casa de
1000 milissegundos.
ISSN 2179-3220 1560
4/4 XXII CBEB 2010
Conclusão
Desenvolver aplicações para acessar dispositivos
biomédicos remotamente não é uma tarefa trivial.
Alguns obstáculos aparecem quando está se
desenvolvendo, como permissões do SO (Sistema
Operacional), requisitos de comunicação entre o SO e a
aplicação, ou até mesmo problemas referentes à
localização e reconhecimento das bibliotecas de acesso
aos dispositivos. Esses problemas podem tirar o
desenvolvedor do foco principal: Analisar e codificar o
acesso aos dispositivos.
Quesitos como interoperabilidade, integração e
encapsulamento das especificidades de comunicação,
fornecidos pela SOA-DB, contribuem para a
aproximação do desenvolvedor com esse foco principal.
Atualmente a SOA-DB está preparada para
registrar apenas dispositivos biomédicos digitais, porém
já está sendo desenvolvido um hardware próprio para a
manipulação de dispositivos biomédicos analógicos.
Tabela 1: Tempo de Resposta nos ambientes de testes
Tipo de ambiente
Tempo
médio de
resposta
(milissegun
dos)
Aplicação
Cliente
Ambiente 1 – Ausência
da SOA-DB 1030
Acesso
direto
localmente
Ambiente 2 – Presença
da SOA-DB 1109
Java (Web
por WSDL)
Ambiente 2 – Presença
da SOA-DB 1079
C# .NET
(Web por
WSDL)
A diminuição da complexidade no acesso aos
dispositivos biomédicos, provida pela SOA-DB, pode
contribuir para o aumento da qualidade nas aplicações
de monitoramento de pacientes e diminuição na
manutenção de sistemas de monitoramento de dados
biomédicos, visto que o desenvolvedor se preocupará
com poucos detalhes de acesso aos dispositivos
biomédicos, voltando quase que totalmente a sua
atenção para a aplicação de monitoramento dos
dispositivos biomédicos e evitando com que os
desenvolvedores trabalhem com diversas APIs e
protocolos voltados para esses dispositivos.
Agradecimentos
Este trabalho contou com o apoio do Laboratório
de Automação Hospitalar e Bioengenharia (LAHB) do
Departamento de Engenharia de Computação e
Automação e do Departamento de Engenharia
Biomédica, ambos da Universidade Federal do Rio
Grande do Norte.
Referências
[1] Valentim, R. A. M. et al. (2008), “Um Modelo para
Acesso a Dispositivos Biomédicos Dirigido a uma
Arquitetura Orientada a Serviços”, In:
SHEWC'2008 - Safety, Health and Environmental
World Congress, Rio de Janeiro, 20-23 Jul.
[2] Deugd, S., Carroll, R., Kelly, K., Millett, B., Ricker,
J. (2006) “SODA: Service Oriented Device
Architecture,” IEEE Pervasive Computing, vol. 5,
no. 3, p. 94-96.
[3] Wang, C. et al. (2007), “Development of Intelligent
Home Health-Care Box Connecting Medical
Equipments and Its Service Platform”, In: The 9th
International Conference on Advanced Communication
Technology, Gangwon-Do, p., 311-315, 12-14 Feb.
[4] Belardinelii, A. et al. (1998), “Advanced technology
for personal biomedical signal logging and monitoring”,
In: Proceedings of the 20th Annual International
Conference of the IEEE Engineering in Medicine and
Biology Society, Hong Kong, p., 1295-1298, 29 Oct-1
Nov.
[5] Stal, M. (2002) “Web services: beyond component-
based computing”, Communications of the ACM
New York: ACM, v. 45, n. 10, p. 71-76.
[6] W3C. Extensible Markup Language (XML).
Disponível em: www.w3.org/XML/. Acesso em 07
mar. 2010.
[7] GAMMA, E., HELM, R., JOHNSON, R.,
VLISSIDES, J. (1998), Design Patterns: Elements
of Reusable Software, Boston: Addison Wesley
Longman.
[8] W3C. Simple Object Access Protocol (SOAP).
Disponível em: http://www.w3.org/TR/soap/.
Acesso em 02 mar. 2010.
[9] Apache. Apache Axis. Disponível em:
http://ws.apache.org/axis/. Acesso em 03 de mar.
2010.
[10] Microsoft. “Consuming MapPoint Web Service in
PHP”, Disponível em:
http://msdn.microsoft.com/enus/library/ms980207.as
px. Acesso em 25 jan. 2010.
[11] W3C. Web Services Description Language
(WSDL). Disponível em:
http://www.w3.org/TR/wsdl. Acesso em 10 mar.
2010.
ISSN 2179-3220 1561