A especificação OSGi Device Access

O cenário descrito na secção 4.2.1 requer que o gateway de serviços (incluído no gateway residencial) comunique com um dispositivo externo ao próprio gateway residencial. Desta forma, a plataforma OSGi apresenta mecanismos que permitem precisamente comunicar e controlar dispositivos ligados através de uma dada tecnologia (por exemplo USB, RS-232, entre outras) ao gateway de serviços, mas que não fazem parte integrante do mesmo. Isto significa que a presença desses dispositivos pode variar ao longo do tempo. Este conjunto de mecanismos, brevemente descritos de seguida, é conhecido como DA (Device Access). Importa referir que estes mecanismos são considerados como opcionais e poderão não estar presentes em todas as implementações ou instalações da plataforma.

De uma forma sintética, a especificação DA permite a representação de um dispositivo físico na framework através de um serviço OSGi, o que significa que os bundles instalados na

plataforma “vêem” esse dispositivo físico apenas como mais um serviço registado na plataforma. A presença desse serviço no registo de serviços da framework significa que o dispositivo está conectado ao gateway de serviços, enquanto que a ausência do serviço significa a ausência do dispositivo. Para além desta funcionalidade, a especificação DA define ainda um processo através do qual é possível encontrar o driver mais adequado para comunicar com cada dispositivo. No seu conjunto a especificação DA define quatro tipos de entidades: o DM (Device Manager), o(s) DS (Device Service)(s), o(s) DLS (Driver Locator Service)(s) e o(s) DrS (Driver) Service)(s), cada uma das quais é descrita de seguida:

• Device Service (DS): Como próprio nome indica, um DS é primeiro de tudo um serviço OSGi (e como tal é também um bundle) que é registado na framework (com um conjunto de propriedades específicas). Este serviço representa dispositivos físicos que podem ir de uma simples porta de comunicações (por exemplo uma porta série) a dispositivos mais complexos (por exemplo um modem conectado à porta série). Quando o dispositivo físico está presente, o DS correspondeste é registado na framework e a operação inversa acontece quando o dispositivo é removido. Como todos os serviços na plataforma OSGi, um DS é definido através de uma interface Java, interface esta que apresenta métodos que permitem interagir com o dispositivo representado. Importa referir que no exemplo referido anteriormente dois DS seriam registados na framework quando o modem estivesse conectado à porta série: um DS que representa e possibilita a comunicação através de uma porta série e outro DS que representa e possibilita a comunicação com o modem.

• Driver Service (DrS): importa desde já referir que o termo driver no contexto da especificação Device Access não se refere a drivers de baixo nível (normalmente ao nível do sistema operativo). A especificação DA assume que esse tipo de drivers altamente específicos ao sistema operativo em uso estejam devidamente instalados e configurados de antemão. Assim, no contexto DA, um driver é uma entidade que regista na framework um ou mais Device Services contidos no bundle que implementa o DrS e que pretendem refinar (oferecendo uma semântica mais rica e/ou um nível de abstracção mais elevado) um Device Service já registado na plataforma. No exemplo anterior o DS que possibilita a comunicação com o modem e que vem refinar o DS que representa a porta série, seria registado na plataforma por um DrS. • Driver Locator Service (DLS): um DLS (podem estar vários simultaneamente registados) sabe onde encontrar bundles que implementem um dado DrS necessário para refinar um DS.

• Device Manager (DM): o DM é o coordenador de todas as acções efectuadas pelas entidades DS, DrS e DLS.

A figura seguinte representa o processo de refinamento de um DS e as várias interacções que ocorrem entre as entidades definidas na especificação Device Access.

Figura 33: Processo de refinamento de um Device Service [116]

Um novo Device Service é registado na framework (figura 33 passo 1). O Device Manager, que está continuamente a observar o registo de Device Services, detecta que um novo DS (DS1) foi registado e portanto interroga todos os Driver Locator Services acerca do seu conhecimento de Driver Services que possam refinar o DS que acabou de se registar. Dos DLSs presentes, apenas o DLS2 responde afirmativamente (figura 33 passo 2). Com base nesta resposta, o DM interroga o DLS2 acerca da localização do DrS que contém o DS que o levou a responder afirmativamente à solicitação anterior. Este pedido resulta na instalação e activação do DrS3 na framework (figura 33 passo 3). Uma vez que todos os DrSs que podem refinar o DS1 já estão registados na plataforma, o DM questiona cada um deles acerca da sua capacidade para refinar o DS que acabou de se registar (figura 33 passo 4). Com base nas respostas obtidas o DM elege o DrS3 como o que deve refinar o DS1, o que resulta no registo de um novo Device Service, o DS2, por parte do DrS3 (figura 33 passo 5). Uma vez registado o DS2, um processo de refinamento semelhante ao que agora termina, poderá ser iniciado para este novo Device Service. Este processo irá continuar até que não haja DLSs que demonstrem conhecimento acerca de DrSs que possam refinar o DS que acabou de se registar.

A descrição anterior deixa todavia duas questões em aberto: Como é que um DLS determina que um dado DrS pode ou não refinar o DS em questão e como é o DM elege um entre os vários DrSs que mostram capacidade para refinar o DS. A resposta à primeira questão reside num conjunto de propriedades que todos os Device Services possuem quando são registados na framework e que estão disponíveis aos vários DLSs interrogados pelo DM. Exemplos dessas propriedades são a categoria do dispositivo que o DS representa (ex. série, USB), a classe do

dispositivo (por exemplo áudio, vídeo, entre outros), o modelo, o fabricante, bem como outras propriedades que podem ser definidas. Com base nestas propriedades cada DLS determina se algum dos DrSs acerca dos quais tem conhecimento pode ou não refinar o DS em questão.

A resposta à segunda questão, reside nesse conjunto de propriedades característico a cada categoria de Device Service: quando o DM interroga cada um dos DrSs acerca da sua capacidade para refinar o DS, cada um destes licita um valor numérico com base no número de propriedades cujo o valor coincide com o valor da mesma propriedade do DS a refinar. O DrS que licite o maior valor é eleito para registar o DS correspondente, sendo que no caso de dois ou mais licitarem um mesmo valor um desempate tem de ser efectuado. Para tal é consultado em primeiro lugar o valor de uma propriedade opcional que define a preferência de um dado serviço em relação a outros. Caso esta propriedade não esteja presente ou o seu valor seja igual entre os vários DrSs, é eleito o DrS que estiver à mais tempo registado na framework. Importa referir que este comportamento na escolha do DrS mais adequado, reflecte um comportamento por defeito. A entidade denominada de Driver Selector Service (introduzida apenas na segunda versão da especificação Device Access [111]) permite personalizar este comportamento.