O SysSU (System Support for Ubiquity)(LIMA, 2011) é uma infraestrutura de su- porte ao desenvolvimento de sistemas ubíquos baseada nos modelos Linda (CARRIERO; GE- LERNTER, 1989) e Publish/Subscribe (EUGSTER et al., 2003). Ele utiliza tuplas para re- presentar dados contextuais e permite que as entidades do sistema se comuniquem de forma desacoplada e interoperável. O SysSU realiza o gerenciamento das informações de contexto de forma centralizada e oferece mecanismos para troca de mensagens, coordenação de atividades e descoberta/invocação de serviços.
A arquitetura do SysSU é do tipo cliente/servidor e suas principais entidades são: App, UbiBroker, e UbiCentre (Figura 3.1). A App representa as aplicações ou serviços que compõem o sistema. O UbiCentre é a entidade que representa o espaço de tuplas centralizado, ele permite que as tuplas sejam acessadas concorrentemente pelas Apps através de seus respec- tivos UbiBrokers. O UbiBroker é o responsável pela comunicação entre a App e o UbiCentre, ele oferece uma interface padronizada para as funcionalidades oferecidas pelo UbiCentre, o que assegura a interoperabilidade. Cada App pode acessar um ou mais espaços de tuplas. Além
disso, o SysSU possui componentes especiais chamados Agregadores, que atendem ao requisito de gerenciamento do ciclo de vida dos dados contextuais, citado na seção 2.3. Os Agregado- res estão associados ao UbiCentre e permitem que sejam feitas composições de campos, tuplas e/ou eventos. Um Agregador tem a finalidade de gerar novas tuplas oriundas da composição de tuplas existentes, por exemplo, gerar uma tupla com o valor médio da temperatura coletada por todos os dispositivos em um ambiente.
Figura 3.1: Arquitetura original do SysSU (LIMA et al., 2011).
As funcionalidades oferecidas pelo UbiCentre são baseadas nas operações realiza- das sobre os espaços de tuplas por ele gerenciados. Essas operações seguem uma padronização de comportamento formada por um conjunto fixo de primitivas baseadas em lógica de primeira ordem e teoria dos conjuntos.
No SysSU uma tupla é formada por um conjunto de campos do tipo chave/valor (e.g. {(name, “roberto”), (location, “casa”)}). O UbiCentre oferece importantes funcionalida- des sobre o conjunto de tuplas que formam seus espaços de tuplas, dentre elas destacamos o mecanismo de associação (Matching) e mecanismo de eventos (Reactions).
Mecanismo de Associação (Matching): O mecanismo de associação é utilizado nas operações de leitura e remoção de tuplas presentes em um espaço de tuplas. Ele retorna um subcon-
junto de tuplas que satisfazem um padrão da tupla e a um filtro, o par ordenado composto por uma padrão de tupla e um filtro é chamado de Query, esse mecanismo vai de encontro ao que foi definido no requisito de gerenciamento do ciclo de vida dos dados contextuais, citado na seção 2.3, o qual destaca a importância da adoção de técnica de filtragem de dados contextuais para a inferência sobre os mesmos.
Um padrão de tupla define o formato, valor e/ou o tipo de dado que a tupla possui, por exemplo, o padrão de tupla (null, string),(null, string), representa tuplas contendo dois campos do tipo string, já o padrão {(contextData, “umidade-relativa”), (value, null)}, representa tuplas com qualquer valor de umidade relativa. O filtro é definido através de uma função booleana, na qual apenas as tuplas que satisfizerem essa função poderão ser selecionadas pelo mecanismo de associação.
Os filtros são escritos usando a linguagem Javascript, o que gera maior expressividade e dinamicidade para expressar relações entre os campos das tuplas. Assim, com esse mecanismo de associação é possível, por exemplo, fazer uma consulta por todas as tu- plas com informações contextuais de temperatura coletadas pelo termômetro interno do dispositivo e que possuam valor superior a 25. Para isso basta utilizar uma Query com- posta pelo padrão de tupla {(contextData, “temperatura-ambiente”), (value, null)}, e pelo filtro “function filter(tuple) {return (tuple.value > 25 && tuple.source == ’termometroIn- terno’)}”.
Mecanismo de Eventos: O mecanismo de eventos possui um conjunto de ações, chamado de Reaction, que devem ser realizadas dada a ocorrência de um evento. Todas as informações relacionadas ao evento devem estar contidas em uma tupla, que é utilizada como modelo de dados, enquanto que os padrões de tuplas são utilizados como modelo de filtros. A principal operação deste mecanismo é a subscrição ao um evento, na qual é informado o identificador da Reaction e uma Query. A Reaction será executada sempre que for inserida uma tupla associada a Query informada. Uma mesma Query pode estar relacio- nada a várias Reactions, quando o evento é disparado todas a Reactions associadas serão notificadas.
O mecanismo de eventos também permite que aplicações inativas no momento da ocor- rência de eventos, possam consultar as notificações que deveriam ter recebido se esti- vessem ativas no sistema, esse comportamento garante o desacoplamento temporal das
aplicações em relação aos eventos. Esse modelo herda a expressividade das tuplas, pa- drões de tuplas e filtros, e com o uso de filtros pode-se implementar notificações sensíveis ao contexto.
O mecanismo de associação baseado em padrão de tupla e filtros também é utilizado no LIME e no TOTA, mas apenas o SysSU possibilita verificar relacionamentos entre os campos das tuplas. No SysSU os filtros são dinâmicos e são passados por parâmetro nas operações entre UbiBroker e UbiCentre. Uma outra vantagem é que o mecanismos de associação do SysSU promove independência do tamanho das tuplas e da posição dos campos, o que facilita a busca por tuplas. Assim, não é necessário conhecer todos os campos de uma tupla para conseguir consulta-la, e a adição de novos campos em uma tupla não afeta as consultas definidas antes da alteração. Essa característica vai de encontro ao comportamento dinâmico e evolutivo do contexto, citado na subseção 2.1.2 permitindo a representação de informações contextuais através de tuplas.
O SysSU é baseado em espaço de tuplas centralizado, como pode ser visto na Figura 3.1. Apesar dessa abordagem simplificar o gerenciamento, ela faz com que todas as informações contextuais, representadas pelas tuplas, sejam armazenadas em um mesmo local. Dessa forma o SysSU inviabiliza a comunicação diante de desconexões constantes e não permite que aplica- ções ubíquas executem sem estar conectadas a um servidor central. Portando, as contribuições apresentadas nesta dissertação seguem o caminho natural de evolução do SysSU, permitindo que exista mais de uma opção de acesso às tuplas contextuais, seja através de consultas a um servidor, seja através do acesso a tuplas armazenadas localmente, ou ainda através de uma rede Ad hoc.