LE TRAVAIL IDENTITAIRE (TI)

Um dos pontos fundamentais em sistemas ubíquos é referente ao armazenamento e re- cuperação de sinais (dados e/ou informações) em sistemas ubíquos. Em sistemas clássicos, bases de dados relacionais são adotadas, e neste modelo o armazenamento, manipulação e recuperação dos dados são estruturados na forma de tabelas. Entretanto, sistemas clás- sicos apresentam muitas questões que impõe limitações na computação ubíqua, como: (i) serviço quanto a escalabilidade horizontal; (ii) exigem esquemas de tabela de tamanho fixo, etc.

Lima et al., (2011) propôs um Sistema de Suporte para Computação Ubíqua (SysSU, System Support for Ubiquity), que proporciona uma maneira flexível de acessar, agregar e filtrar os dados sensoriais. Suas funcionalidades permitem que informações contextuais em forma de tuplas sejam dispostas e acessadas de forma síncrona e assíncrona, caracte- rística atingida a partir das abordagem de espaço de tuplas do modelo Linda [CARRIERO; GELERNTER, 1989] e Publish/Subscribe [EUGSTER et al., 2003]. SysSU atua apenas como a

camada de Gerenciamento descrita por BALDAUF; DUSTDAR; ROSENBERG, (2007), não possuindo funcionalidades como aquisição de contexto ou enriquecimento de informa- ções contextuais.

Todo o funcionamento desse sistema é baseado em tuplas. Uma tupla é uma compo- sição de um conjunto de campos chave/valor, por exemplo: (user,“John”), (age,10), (gender,“M”). Existem duas formas para que aplicações possam utilizar informações publicadas no SysSU:

(i) Realizar uma consulta direta o que exige que as informações tenham sido disponi- bilizadas nele antes da consulta ser realizada; e

(ii) Baseada em eventos (publicação/subscrição), que é utilizada quando a informação ainda não está disponível, mas uma aplicação deseja ser notificada quando estiver. As duas formas de acesso a informações fazem uso de templates e filtros para selecionar as tuplas desejadas.

Um template é uma coleção de campos representando um conjunto ou subconjunto de campos que compõem uma tupla requerida. Por exemplo, para encontrar uma tupla com um campo contendo a chave user o seguinte template poderia ser utilizado: (user, ?). Um template também pode ser utilizado para retornar tuplas com valores específicos para

uma chave. Por exemplo, (user, ?),(age, 10) retorna todas as tuplas que contenham qualquer valor para o campo com chave user e que também contenham um campo com chave age e valor exatamente igual a 10.

O uso de templates permite realizar apenas comparações de igualdade de valores. Para melhorar a expressividade da seleção de tuplas, um filtro deve ser utilizado. Filtros são criados utilizando JavaScript e são limitados apenas pela própria expressividade da linguagem. O Algoritmo 2.1 mostra um exemplo de filtro que seleciona tuplas onde um campo com a chave age possui valores a partir de 18.

Algoritmo 2.1: Exemplo de implementação de um filtro

1 f u n c t i o n filter ( tuple ) { 2 if ( tuple . age >= 18) { 3 return true; 4 } else { 5 return false; 6 } 7 }

O SysSU tem a sua arquitetura baseada no modelo cliente/servidor, onde o UbiCentre, o servidor, é um repositório de espaços de tuplas acessados concorrentemente por vários agentes através do UbiBroker, um middleware responsável pela comunicação entre os agentes e o UbiCentre. A Figura 3 mostra a sua arquitetura.

O UbiBroker é um middleware responsável pela comunicação entre os agentes e o UbiCentre. Ele é o responsável por fornecer a visão uniforme da arquitetura garantindo, assim, a interoperabilidade. Sua implementação pode ser realizada por meio de um driver embutido no sistema operacional dos dispositivos acessado pelos agentes ou através de um componente que possui meios de comunicação com o UbiCentre reutilizado na imple- mentação dos agentes. Nessas implementações, o importante é a presença de uma API que esteja disponível para uso pelos agentes.

Já o UbiCentre é um repositório de espaços de tuplas acessados concorrentemente por vários agentes através do seu respectivo UbiBroker. Cada agente pode acessar um ou mais espaços de tuplas, os quais são diferenciados por um nome (identificador único). O UbiCentre pode ser implementado como um serviço ou como uma simples aplicação que aceita conexões por meio de alguma tecnologia de comunicação.

Para cada plataforma de execução que compõe o sistema ubíquo, deve existir uma implementação apropriada do UbiBroker capaz de se comunicar com o UbiCentre. Essa comunicação é realizada pelo uso de uma tecnologia de Chamada Remota de Procedimento (Remote Procedure Call -– RPC) que permita callback [MÜHL; FIEGE; PIETZUCH, 2006],

sendo as interoperáveis (e.g., CORBA ou Web Services [ALONSO et al., 2004]) as mais

indicadas. Além disso, a implementação é independente da tecnologia de transmissão de dados (e.g., 802.11, Bluetooth). Essa característica é representada pelas partes hachuradas na figura. Além disso, o UbiCentre tem que possuir os mesmos mecanismos de RPC e tecnologias de transmissão de dados utilizados pelos UbiBrokers para que a comunicação seja possível.

Essa independência em relação a forma como o UbiBroker se comunica com o Ubi- Centre favorece um maior grau de heterogeneidade no sistema ubíquo. O fato de serem utilizados mecanismos de execução remota de métodos não invalida o propósito de se atin- gir o desacoplamento desejado. Eles são utilizados somente como veículos de comunicação para a realização das operações disponibilizadas pelo UbiCentre, que são limitadas e fixas e que somente os UbiBrokers podem executá-las.

O UbiCentre disponibiliza um conjunto de operações que podem ser executadas sobre os espaços de tuplas por ele gerenciado. Essas operações seguem uma padronização de comportamento e são executadas a partir dos UbiBrokers pelo envio de solicitações em alguma tecnologia de execução remota de métodos. Uma implementação do UbiBroker é considerada apropriada quando ele segue a linguagem de definição de interface estabele- cida. Essa padronização determina o conjunto de primitivas (relacionadas às operações)

que são usadas pelos agentes nas suas interações, bem como os parâmetros e os valores de retorno. Assim, agentes de software, construídos e executando em plataformas diferentes, podem se comunicar entre si adequadamente através do UbiCentre. Essa especificação das mensagens trocadas entre UbiBrokers e UbiCentre e do comportamento de cada operação correspondente devem ser seguida na implementação de ambos.