Política de Qualidade de Serviço

A especificação DDS aborda um rico conjunto de políticas de QoS com base em contrato entre Publisher e Subscriber, incluindo, entre outros: durabilidade, tempo de vida, prazo e prioridade de transporte. Políticas de QoS fornecem um mecanismo para as aplicações distribuídas poderem controlar o comportamento de uma entidade [36].

As entidades da especificação DDS incluem tópicos, que descrevem o tipo de dados a ser escrito ou lido; Os DataReaders, que registram o interesse em receber os dados de um tópico específico; e DataWriters, que publica os dados ou instâncias para tópicos específicos. Várias propriedades dessas entidades podem ser configuradas

4.2 Data Distribution Service 54

Figura 4.2: Arquitetura DDS. Fonte: Xiong et al. [71].

usando combinações das 22 Políticas de QoS presente na especificação DDS. Em vários casos, para que a comunicação ocorra de forma eficiente, a política de QoS do lado do DataWriter deve ser compatível com a política correspondente do lado do DataReader.

Por disponibilizar um conjunto de políticas de QoS, o DDS proporciona às aplicações clientes a capacidade de controlar e limitar a utilização de recursos, tais como, consumo da largura de banda e memória, e muitas propriedades não funcionais, tais como, persistência, confiança e pontualidade. E nesse trabalho, destacamos as seguintes políticas de QoS:

1. RESOURCE_LIMITS: permite controlar a quantidade de mensagens armazenadas na cache das entidades;

2. TIME_BASED_FILTER: permite aos DataReaders limitar o número de dados recebidos dentro de um intervalo de tempo;

3. DEADLINE: garante que publicador publicará pelo menos uma atualização no tópico dentro de um intervalo de tempo;

4. LATENCY_BUDGET: especifica um atraso aceitável entre o tempo no qual o DataWriter grava um dado e o tempo no qual o DataReader recebe a notificação de que esse dado está disponível;

4.3 Considerações Finais 55 5. DURABILITY: permite às entidades determinar se os tópicos serão salvos pelo

middleware DDS;

6. LIFESPAN: permite definir o prazo de validade para os dados publicados;

7. HISTORY: especifica a quantidade de dados que serão armazenados para uma entrega posterior;

8. RELIABILITY permite à aplicação controlar o nível de confiabilidade na entrega dos dados;

9. DESTINATION_ORDER: permite controlar a ordem de chegada dos dados publicados;

10. OWNERSHIP: permite controlar o número de publicadores com permissão para um determinado tópico.

4.3 Considerações Finais

O modelo DCPS fornece as funcionalidades necessárias para o desenvolvimento de aplicações cientes de contexto, garantindo um fraco acoplamento entre os consumidores e produtores de dados. Em uma infraestrutura publish/subscribe, os publishers produzem as publicações, unidades de informação não endereçadas que são entregues ao sistema. Os subscribers, por sua vez, expressam o seu interesse em publicações com determinadas características. Cabe à infraestrutura publish/subscribe a responsabilidade de entregar as publicações aos subscribers que nelas estejam interessados.

Na definição do middleware proposto neste trabalho de mestrado, adotou- se uma abordagem orientada a dados para a definição do modelo de comunicação, no qual os dados são transmitidos na forma de tópicos, formando o dicionário de dados do MobileHealthNet. Cada tópico possui informações de entidades ou de ações realizadas por estas e permitem a troca de dados entre clientes e provedores de serviços.

O modelo orientado a dados molda-se perfeitamente às necessidades do projeto MobileHealthNet , pois a notificação da produção de informação de interesse

4.3 Considerações Finais 56 contribui para a redução do número de mensagens desnecessárias. Essa característica é útil para aplicações móveis, cuja comunicação está sujeita à conectividade intermitente e eventuais desconexões. Além disso, o DDS suporta diversas políticas de QoS relacionadas à distribuição de dados. Essas políticas são utilizadas em nossa proposta para atender alguns parâmetros de QoC.

57

5 MOBILEHEALTHNET CONTEXT SERVICE

Este capítulo apresenta o middleware MobileHealthNet Context Service - MHNCS, cuja principal responsabilidade é a coleta e distribuição de informações de contexto para aplicações ubíquas. O MHNCS disponibiliza uma linguagem flexível que dá suporte à especificação de requisitos de contexto com qualidade (QoC), bem como a obtenção, validação, e distribuição de dados de contexto, considerando parâmetros de QoC, esses parâmetros foram descritos no capitulo 3, especificados pelo desenvolvedor da aplicação ubíqua que faz uso do middleware. O objetivo principal deste trabalho é criar um middleware que gerencie a distribuição de contexto e facilite o desenvolvimento de aplicações móveis cientes de contexto contemplando requisitos específicos da área da saúde.

A infraestrutura proposta neste trabalho está inserida na arquitetura do MobileHealthNet descrito no capítulo 2, o qual corresponde ao Context Service da camada Core Services, conforme a Figura 2.4. Apesar de na arquitetura do MobileHealthNet ele ser referenciado como serviço, ele pode ser instanciado e utilizado de forma independente do MobileHealthNet, o que justificaria chamá-lo de middleware.

5.1 Requisitos do MHNCS

O acompanhamento do estado de saúde dos pacientes através de recursos da computação ubíqua permite aos profissionais da área da saúde obter dados diariamente de seus pacientes. Em outras palavras, o suporte da mobilidade promovida pela tecnologia móvel na medicina permite o acompanhamento e o tratamento contínuo ou pontual dos pacientes, mesmo à distância, fora do ambiente hospitalar. O acompanhamento de pacientes utilizando recursos ubíquos requer importantes requisitos relacionados ao desenvolvimento de aplicações cientes de contexto [6]. O MHNCS possui os seguintes requisitos funcionais:

5.2 Linguagem para Especificação de Requisitos de Contexto 58