Brokering de Recursos

Um sistema desta natureza assenta num comportamento contínuo, dinâmico e evidente onde participantes (melhor, recursos) podem ou não estar disponíveis ou capazes. A necessidade de encontrar recursos mais adequados ou capazes de substituir ou complementar outros é normal. Devido ao vasto Mercado de Recursos que uma rede deste tipo pode usufruir, é necessária a existência de um agente capaz de “oferecer” sugestões

ao utilizador tendo em conta a relação “contexto-necessidade”. Neste protótipo, esse agente designa-se “Broker de Recursos”.

Apesar da existência do sistema de widgets, apresentado no capítulo 4.2.7, e da capacidade que oferece, os resultados “despoletados” a partir deste broker, ao nível do dashboard, poderiam ser representados por um widget normal, capaz de reagir a qualquer alteração realizada em qualquer um dos outros widgets. Devido à importância do broker no sistema, decidiu-se manter permanente os resultados devolvidos nas suas operações de seleção. Criou-se então uma secção na barra lateral esquerda no dashboard, que apresenta a lista das sugestões para o utilizador tendo em conta as suas necessidades atuais.

O funcionamento do broker em si passa, primeiramente, pela realização de uma coleta de dados em relação

aos processos que vão decorrendo no dashboard do utilizador. Em cada evento que ocorre existe um conjunto de dados associados que podem ser utilizados com o objetivo de perceber que tipo de acontecimentos estão a decorrer no contexto do utilizador. Perante esses dados, o broker gera um conjunto de sugestões que se aplicam ao contexto corrente. Para tal, foi definido que a informação “disparada” a cada evento, ou parte dela, pode também ser enviada para o sistema de brokering (Figura 39).

Figura 39 - Integração do Broker de Recursos

Ou seja, sempre que o servidor recebe dados, derivados de ações do lado do cliente e/ou de fontes externas à rede (Figura 39 – 2), estes dão entrada em processos específicos que, além de realizarem determinadas operações e despacharem informações para certos canais (Figura 39 – 3), seguem um conjunto de regras que permitem “decidir” se enviam determinados “pedidos” para o sistema de brokering (Figura 39 – 4). Recebendo os dados, o broker detém a capacidade necessária para trabalhar sobre os “pedidos”, pesquisando na rede recursos que os satisfaçam. Por fim, caso encontre, esses recursos são enviados para o utilizador (Figura 39 – 5). Futuramente, a pesquisa por recursos poderá também ser realizada externamente, i.e., devido à capacidade oferecida pelo sistema em relação à possibilidade de ter vários “conceitos” no mesmo dashboard, os dados que circulam na rede poderão não chegar para satisfazer as necessidades dos utilizadores.

Devido à possível existência de múltiplos widgets num mesmo dashboard, a informação (recursos) coletada poderia tornar-se imensa e difícil de lidar, afetando a qualidade das sugestões oferecidas pelo broker. Nesse sentido, foi decidido que a informação enviada para o broker deve estar classificada, assim como respeitar alguns critérios de temporalidade.

Parte desta semântica foi conseguida utilizando JSON-LD (capítulo 2.2.2.2), visto que permite descrever dados, associá-los a um contexto e acrescentar outros atributos. A utilização dos atributos “@context” e “@type” permite facilmente identificar em que contexto/tipologia determinada “coisa” está inserida. No Código 30 é possível visualizar a associação desses atributos a um recurso da rede. O recurso apresentado é

uma pessoa (tipo de recurso é “Person”) e através do subdocumento “@context” consegue-se perceber que

está presente em vários contextos. Neste caso, além de ser uma pessoa, possui também outro dado importante a nível de classificação de um recurso: “job”. Por isso, além estar presente num contexto de “pessoas” (Código 30 – linha 20), também está num contexto de “profissões/trabalho” (Código 30 – linha 21), cujo “@id” (valor associado) da profissão é “electrical-engineer” (Código 30 – linha 8).

Código 30 - Presença dos atributos "@context" e "@type" num documento da coleção "Thing"

4.2.10.1. Case Study: Monitorização Ambiental numa Estufa

Tendo em conta a modelação da semântica apresentada (em JSON-LD) e a existência de um widget desenvolvido com capacidade de apresentar, em tempo-real, informação relativamente à temperatura de um sensor, vejamos que tipo de informação poderia ser enviada para o sistema de brokering caso os indicadores estivessem, por exemplo, num nível alto (Código 31):

Código 31 - Tipo de Informação recebida pelo Broker de Recursos

Imaginando que o tal sensor estaria fisicamente presente numa estufa e que de repente começou a enviar leituras com valores fora dos padrões normais, então esse acontecimento poderá ser uma consequência de uma avaria ao nível do equipamento ao qual o sensor está associado ou de uma suposta rutura de um tubo, por exemplo. Sabendo em que tipo de ambiente o sensor está inserido e os padrões normais de leituras que deve enviar, neste caso, no ponto de entrada dos dados (que depois são enviados para o widget) poderão existir regras para que, no caso de uma situação destas, seja enviado de imediato ao utilizador sugestões de “coisas” que o podem ajudar, como é o caso de “engenheiros eletrónicos” (avaria no sensor) e/ou “picheleiros” (rutura de um tubo). A informação despoletada para o broker, assim como a informação que o broker liberta, são guardadas por utilizador, isto é, no “documento” referente ao utilizador, armazenado na base de dados através da chave “broker”. Devido à enorme possibilidade da informação armazenada ser imensa, existe uma gestão de armazenamento desses dados a nível temporal, razão pela qual cada item (por categoria) tem associado uma data (Código 31 – linha 05). Desta forma, é possível precaver a ampliação do campo “broker”, assim como a existência de dados que a nível temporal perdem credibilidade ou relevância. Além de datar cada item, também é atribuída uma prioridade para cada um, de forma a que os resultados apareçam ao utilizador ordenados através de uma relação entre tempo e prioridade.

No momento, a pesquisa de recursos por parte do broker é realizada internamente, mas, no futuro, poderá também ser externamente, i.e., tendo em conta o contexto dos dados enviados para o broker, este decide se realiza a pesquisa de recursos na própria rede ou se consulta serviços externos. Internamente, esta recolha de recursos é executada através do método de pesquisa apresentado no capítulo 4.2.9 – Full-Text Search. Externamente, o plano passa por estabelecer uma associação entre determinados contextos e serviços web específicos. Por exemplo, associando este protótipo a um tipo de rede profissional, dados dentro do contexto “job” podem ser pesquisados internamente, já que a rede oferece recursos desse tipo. Mas um contexto como

“transports”, imaginando que no widget de agendamento de compromissos foi marcado um compromisso para

uma determinada cidade, o melhor será consultar um serviço que ofereça transportes disponíveis para o local desejado.

Por fim, o envio dos resultados obtidos para o utilizador é realizado tal como no sistema de widgets, existindo do lado do utilizador uma vinculação a um evento que está sempre à escuta de novos dados, representando-os de seguida.