Apesar dos trabalhos apresentados neste cap´ıtulo serem bastante relevantes e solu- cionarem os problemas alvos de cada um, nenhum deles se ad´equa completamente aos requisitos para o desenvolvimento de sistemas ub´ıquos apresentados no cap´ıtulo 2. A
tabela 3.1 sumariza a rela¸c˜ao entre esses trabalhos e os requisitos. Dessa forma, novas solu¸c˜oes de software se fazem necess´arias para atendˆe-los apropriadamente.
Tabela 3.1: Rela¸c˜ao entre os trabalhos abordados neste cap´ıtulo e os requisitos discutidos no cap´ıtulo 2.
Esta disserta¸c˜ao prop˜oe uma nova solu¸c˜ao chamada SysSU que ´e apresentado nos cap´ıtulos. 4 e 5. Na descri¸c˜ao das solu¸c˜oes deste cap´ıtulo foi destacado a diferen¸ca do
SysSU com cada uma delas, mas, em resumo, o SysSU provˆe suporte, especialmente,
para os requisitos de coordena¸c˜ao, descoberta/invoca¸c˜ao de servi¸cos e interoperabilidade considerando as caracter´ısticas especias de cada um no contexto da Computa¸c˜ao Ub´ıqua. Al´em disso, ´e poss´ıvel estendˆe-lo ou utiliz´a-lo para atender ao requisito de sensibilidade ao contexto e us´a-lo para implementar mecanismos de invisibilidade e autonomicidade.
4
O Sistema de Suporte SysSU
O objetivo deste trabalho ´e fornecer uma nova infraestrutura de software, na forma de um sistema de suporte, destinada a atender aos requisitos de coordena¸c˜ao, descri¸c˜ao/- descoberta de servi¸cos e interoperabilidade discutidos nos cap´ıtulos anteriores. Ela tem como base um modelo misto do modelo Linda e do modelo publish/subscribe, mas permite uma maior flexibilidade e expressividade no mecanismo de busca associativo no espa¸co de tuplas e na subscri¸c˜ao de eventos, al´em de permitir agrega¸c˜oes de campos, tuplas e eventos. Al´em disso, esse mesmo mecanismo de intera¸c˜ao ´e usado para a descri¸c˜ao/desco- berta de servi¸cos, pois, devido ao desacoplamento e a expressividade fornecida, ´e poss´ıvel solucionar os problemas desse requisito no contexto da Computa¸c˜ao Ub´ıqua.
Contudo, a maior vantagem na utiliza¸c˜ao do SysSU ´e a sua interoperabilidade. O
SysSU ´e apresentado atrav´es de uma especifica¸c˜ao da sintaxe das mensagens poss´ıveis de
serem usadas na intera¸c˜ao entre agentes, bem como a semˆantica de suas opera¸c˜oes (i.e., uma linguagem de defini¸c˜ao de interface). Essa especifica¸c˜ao ´e independente de linguagem de programa¸c˜ao ou plataforma de desenvolvimento e, assim, sendo poss´ıvel implement´a-lo em diferentes plataformas, desde que obede¸cam a especifica¸c˜ao imposta.
Este cap´ıtulo aborda a arquitetura de referˆencia e a especifica¸c˜ao formal do SysSU, nas se¸c˜oes 4.1 e 4.2 respectivamenente. J´a na se¸c˜ao 4.3 ´e mostrado o conceito de agregadores e na se¸c˜ao 4.4 a conclus˜ao do cap´ıtulo.
4.1
Arquitetura de Referˆencia
A arquitetura de referˆencia de um sistema ub´ıquo est´a ilustrada na Figura 4.1. Um sistema ub´ıquo ´e formado por v´arios dispositivos, que, por sua vez, pode conter v´arios agentes (na figura ´e mostrado somente um por dispositivo). Nessa representa¸c˜ao, a pla- taforma na qual os agentes foram desenvolvidos e a que est˜ao sendo executados n˜ao ´e importante.
Figura 4.1: Arquitetura do SysSU.
O UbiBroker ´e um middleware respons´avel pela comunica¸c˜ao entre os agentes e o
UbiCentre. Ele ´e o respons´avel por fornecer a vis˜ao uniforme da arquitetura garantindo,
assim, a interoperabilidade. Sua implementa¸c˜ao pode ser realizada por meio de um driver, acessado pelos agentes, embutido no sistema operacional dos dispositivos ou atrav´es de um componente reutilizado na implementa¸c˜ao dos agentes que possui meios de comunica¸c˜ao com o UbiCentre. Nessas implementa¸c˜oes, as caracter´ısticas importantes s˜ao: estar de acordo com a especifica¸c˜ao estabelecida (detalhada adiante), a presen¸ca de uma API que esteja dispon´ıvel para uso pelos desenvolvedores dos agentes e que a forma como ser´a realizada a comunica¸c˜ao seja transparante.
J´a o UbiCentre ´e um reposit´orio de espa¸cos de tuplas acessado concorrentemente por v´arios agentes atrav´es do seu respectivo UbiBroker. Cada agente pode acessar um ou mais espa¸cos de tuplas, os quais s˜ao diferenciados por um nome (identificador ´unico). O uso de espa¸cos de tuplas desacopla os agentes no tempo e no espa¸co, pois a comunica¸c˜ao ´e realizada por meio do espa¸co compartilhado de tuplas. Assim, um agente pode inserir uma tupla e sair do sistema enquanto outro agente pode entrar no sistema e retirar essa tupla sem saber qual foi o agente que a inseriu e nem quando isso aconteceu. Al´em disso,
os espa¸cos de tuplas podem servir como reposit´orios de informa¸c˜oes contextuais na forma de tuplas, os quais permitem que os agentes obtenham informa¸c˜oes sobre “o que est´a acontecendo” no ambiente. Na se¸c˜ao 4.2 s˜ao descritas as opera¸c˜oes relacionadas com a utiliza¸c˜ao os espa¸cos de tuplas por parte dos agentes.
O UbiCentre pode ser implementado como um servi¸co ou como uma simples aplica¸c˜ao que aceita conex˜oes por meio de alguma tecnologia de comunica¸c˜ao. Ele pode ser implan- tado em um ´unico computador ou em v´arios, o importante ´e seguir as especifica¸c˜oes das opera¸c˜oes e das mensagens e estar acess´ıvel para os UbiBrokers na rede de dados utilizada. Para cada plataforma de execu¸c˜ao que comp˜oe o sistema ub´ıquo, deve existir uma implementa¸c˜ao apropriada do UbiBroker capaz de se comunicar com o UbiCentre. Essa comunica¸c˜ao ´e realizada pelo uso de uma tecnologia de RPC que permita callback (M¨uHL; FIEGE; PIETZUCH, 2006), sendo as interoper´aveis (e.g., CORBA ou web services) as mais indicadas. Al´em disso, a implementa¸c˜ao ´e independente da tecnologia de transmiss˜ao de dados (e.g., 802.11, bluetooth). Essa caracter´ıstica ´e representada pelas elipses hachu- radas na figura. J´a o UbiCentre pode ser implementado usando apenas uma plataforma de desenvolvimento, pois somente ´e necess´ario um UbiCentre em um sistema ub´ıquo. Entre- tanto, ele deve ser implementado tendo como base todas as tecnologias de comunica¸c˜ao (dados e RPC ) utilizada pelos UbiBrokers. Por esse motivo, para uma maior abran- gˆencia, a tecnologia de comunica¸c˜ao deve, preferencialmente, seguir um padr˜ao aberto e interoper´avel.
Essa independˆencia em rela¸c˜ao `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¸c˜ao remota de m´etodos n˜ao invalida o prop´osito de se atin- gir o desacoplamento desejado. Eles s˜ao utilizados somente como ve´ıculos de comunica¸c˜ao para a realiza¸c˜ao das opera¸c˜oes disponibilizadas pelo UbiCentre. Essas opera¸c˜oes, por sua vez, s˜ao limitadas e fixas e somente os UbiBrokers podem execut´a-las.
O UbiCentre disponibiliza um conjunto de opera¸c˜oes que podem ser executadas sobre os espa¸cos de tuplas por ele gerenciadas. Essas opera¸c˜oes seguem uma padroniza¸c˜ao de comportamento, detalhada na subse¸c˜ao 4.2.1, e s˜ao executadas a partir dos UbiBrokers pelo envio de solicita¸c˜oes em alguma tecnologia de execu¸c˜ao remota de m´etodos. Uma im- plementa¸c˜ao do UbiBroker ´e considerada apropriada quando ele segue a IDL estabelecida, a qual ´e descrita na subse¸c˜ao 4.2.2 e exemplificada no cap´ıtulo 5. Essa padroniza¸c˜ao de- termina o conjunto de primitivas (relacionadas `as opera¸c˜oes) que s˜ao usadas pelos agentes nas suas intera¸c˜oes, bem como os parˆametros e os valores de retorno. Assim, agentes de
software, constru´ıdos e executados em plataformas diferentes, podem se comunicar entre si adequadamente atrav´es do UbiCentre.
A Figura 4.2 apresenta um exemplo de implementa¸c˜ao dessa arquitetura. Nela o Ubi-
Centre utiliza duas formas de comunica¸c˜ao: web service SOAP e JSON-RPC (ambos
sobre TCP/IP ). Duas implementa¸c˜oes do UbiBroker tamb´em s˜ao representadas, uma que utiliza JSON-RPC e outra que usa SOAP. Na figura, o retˆangulo arrendondado maior representa o dispositivo que cont´em o UbiCentre ou o UbiBroker e as setas tracejadas representam a comunica¸c˜ao l´ogica entre o UbiBroker e o UbiCentre, sendo que a comuni- ca¸c˜ao real ´e desempenhada pelas camadas TCP/IP, representada pelas setas cheias.
Figura 4.2: Exemplo de implementa¸c˜ao da arquitetura do SysSU.
Por fim, os agregadores s˜ao componentes especiais ligados ao UbiCentre com respon- sabilidades de alterar o comportamento padr˜ao das opera¸c˜oes. Esses componentes s˜ao desenvolvidos na mesma plataforma do UbiCentre seguindo um determinado contrato (interface) e podem ser adicionados e removidos em tempo de execu¸c˜ao do UbiCentre. Sua funcionalidade ´e a intercepta¸c˜ao de qualquer invoca¸c˜ao de opera¸c˜oes realizada nos espa¸cos de tuplas no UbiCentre alterando o resultado padr˜ao, normalmente retornando tuplas que possuem agrega¸c˜oes de campos e/ou de tuplas, pois s˜ao capazes de executar opera¸c˜oes nos espa¸cos de tuplas e combinar resultados. Eles ser˜ao melhor detalhados na se¸c˜ao 4.3.