Modelo de Objetos

A concepc¸˜ao original do D-Bus visava substituir sistemas de comunicac¸˜ao orientados `a componentes. Por essa raz˜ao, o protocolo compartilha com seus predecessores um modelo de objetos para expressar a semˆantica de comunicac¸˜ao entre clientes e servidores. Os termos utili- zados no modelo de objetos do D-Bus imitam os usados em paradigmas de orientac¸˜ao `a objeto, por´em isso n˜ao limita a utilizac¸˜ao do protocolo somente em linguagens orientadas `a objeto. De fato, a implementac¸˜ao mais utilizada do D-Bus ´e descrita em linguagem C procedural.

Objetos (Objects)

O termo ’objeto’ em si adquire um sentido pr´oprio dentro do contexto do protocolo, repre- sentando uma entidade que pode ser exposta, oferecendo m´etodos que podem ser chamados e sinais que podem ser captados.

Um objeto ´e criado por um processo cliente e existe dentro do contexto da conex˜ao deste com o bus, sendo uma maneira do processo cliente oferecer servic¸os ao bus. Um processo cliente pode criar um ou mais objetos e oferecˆe-los.

Objetos no D-Bus s˜ao unicamente identificados por uma combinac¸˜ao de um bus name e um caminho de objeto. O bus name identifica unicamente o objeto dentro da aplicac¸˜ao e cada aplicac¸˜ao automaticamente atribui um bus name ´unico e randˆomico a cada conex˜ao. Aplicac¸˜oes que desejam exportar objetos pelo D-Bus podem requisitar a posse de um bus name adicional ”bem conhecido”, para prover uma localizac¸˜ao simples e consistente para outras aplicac¸˜oes acessarem em tempo de execuc¸˜ao.

O caminho de objeto intencionalmente se parece com um caminho do sistema de arquivos padr˜ao UNIX. A diferenc¸a principal ´e que o caminho pode conter somente n´umeros, letras, un- derscorese o caractere /. De um ponto de vista funcional, o principal prop´osito do caminho de objeto ´e simplesmente ser um identificador ´unico do objeto em quest˜ao. A hierarquia impl´ıcita na estrutura do caminho ´e baseada puramente em convenc¸˜oes, sendo que aplicac¸˜oes que natu- ralmente s˜ao organizadas em hierarquias podem tirar vantagem deste recurso enquanto outras podem ignor´a-la sem quaisquer perdas.

Todo bus tem pelo menos um objeto, que representa o pr´oprio bus (padronizado com a interfaceorg.freedesktop.DBus). Em um n´ıvel maior de abstrac¸˜ao, um bus suporta duas formas de comunicac¸˜ao:

4.2 Protocolo D-Bus 71

sagem para que o servidor exporte o objeto, e o servidor em resposta retorna uma men- sagem ao processo cliente. A mensagem deve conter o caminho do objeto, o nome do m´etodo a ser invocado e os valores dos argumentos. A resposta deve conter os resultados da requisic¸˜ao, incluindo valores de parˆametros retornados pela invocac¸˜ao do m´etodo, ou informac¸˜oes de excec¸˜oes por ocorrˆencia de erro.

• Publish/Subscribe: modo como um objeto anuncia a ocorrˆencia de um sinal pelas partes interessadas. O processo publisher transmite uma mensagem para o bus que por sua vez encaminha a mensagem somente aos subscribers conectados que est˜ao inscritos para a recepc¸˜ao do tipo de sinal transmitido. A comunicac¸˜ao ´e unidirecional, considerando que o publisher n˜ao conhece a identidade nem o n´umero de subscribers.

Mensagens

Toda mensagem consiste de um cabec¸alho e um corpo. O cabec¸alho ´e formado por diversos campos que identificam o tipo da mensagem, o remetente, assim como informac¸˜oes requeridas para entrega da mensagem ao destinat´ario (bus name, caminho de objeto, nome de m´etodo ou sinal, nome de interface, etc). O corpo cont´em o payload de dados a ser interpretado pelo processo, por exemplo os parˆametros ou resultados. Todos os dados s˜ao codificados em um for- mato bin´ario denominado wire format, que suporta a serializac¸˜ao de v´arios tipos como inteiros, ponto-flutuantes, strings, tipos compostos, dentre outros.

A especificac¸˜ao do D-Bus define o wire protocol, a maneira como as mensagens s˜ao cons- tru´ıdas para serem transportadas entre processos, por´em n˜ao define o m´etodo de transporte para entrega dessas mensagens, deixando em aberto a estrat´egia de transporte como um elemento definido por implementac¸˜ao.

Assinaturas e Tipos

O D-Bus usa um mecanismo de codificac¸˜ao de tipos denominado Assinaturas (Signatures) para descrever o n´umero e os tipos de argumentos necess´arios para m´etodos e sinais. As assi- natures s˜ao usadas para declarar/documentar interfaces, marshalling de dados e validac¸˜ao. A codificac¸˜ao em strings usa um formato simples e essencial para o uso efetivo do protocolo. A Tabela 4.2 adaptada de (MASTERS; BLUM, 2007) apresenta os tipos fundamentais e suas respectivas representac¸˜oes. Al´em dos citados, ainda ´e poss´ıvel codificar arrays, structs e di- cion´arios.

4.2 Protocolo D-Bus 72

Caractere Tipo de Dados

y Inteiro n˜ao-sinalizado de 8-bits

b Booleano

n Inteiro sinalizado de 16-bits

q Inteiro n˜ao-sinalizado de 16-bits

i Inteiro sinalizado de 32-bits

u Inteiro n˜ao-sinalizado de 32-bits

x Inteiro sinalizado de 64-bits

t Inteiro n˜ao-sinalizado de 64-bits

d Ponto-flutuante de precis˜ao dupla (IEEE 754)

s String em formato UTF-8

h Descritor de Arquivo UNIX

Tabela 4.2: Codificac¸˜ao de Assinaturas do D-Bus

M´etodos (Methods)

M´etodos s˜ao o principal modo de implementac¸˜ao do mecanismo de Request/Reply. M´etodos podem aceitar qualquer n´umero de argumentos e podem retornar zero ou mais valores. Quando chamadas de m´etodo n˜ao especificam valores de retorno, uma mensagem ”method return”´e en- viada para o processo requisitante. Isso permite que processos detectem que o m´etodo invocado remotamente foi conclu´ıdo, mesmo que nenhum resultado efetivamente seja retornado.

O ´unico caso no qual a mensagem de retorno n˜ao ´e enviada por uma chamada de m´etodo ´e na ocasi˜ao onde o parˆametro ”no reply expected”´e enviado como parte da invocac¸˜ao do m´etodo, suprimindo a mensagem de retorno.

As assinaturas para a lista de argumentos e para o retorno do m´etodo podem conter m´ultiplos tipos. Para cada argumento aceito e cada valor de retorno, o tipo do valor de argumento ou re- torno ´e simplesmente anexado, em ordem, `a assinatura da mensagem. Se o m´etodo n˜ao aceita argumentos ou n˜ao retorna valores, as assinaturas para tais atributos s˜ao vazias.

Sinais (Signals)

Sinais s˜ao a base para o mecanismo de Publish/Subscribe, fornecendo capacidade de envio de mensagens de um-para-muitos. Similar ao retorno de valores de m´etodos, os sinais podem conter uma quantidade arbitr´aria de dados, por´em s˜ao inteiramente ass´ıncronos e podem ser emitidos por objetos do D-Bus a qualquer momento. Por padr˜ao, sinais emitidos por objetos n˜ao ser˜ao enviados para nenhum cliente. Para receber os sinais, os processos devem explicitamente registrar o interesse em receber determinados sinais emitidos.

4.2 Protocolo D-Bus 73

Interfaces

As interfaces definem m´etodos e sinais suportados por objetos. Para usar uma interface, a mesma deve ser conhecida pelos processos remotos. A definic¸˜ao da interface pode ser hard co- dedna aplicac¸˜ao ou pode ser consultada em tempo de execuc¸˜ao pelo mecanismo de introspecc¸˜ao do D-Bus - apesar de opcional, o suporte `a introspecc¸˜ao ´e geralmente autom´atico nas diferentes implementac¸˜oes do protocolo. A convenc¸˜ao de nomes para interfaces ´e similar a dos bus names.

Proxies

Um objeto proxy ´e um objeto criado para representar um objeto remoto em outro processo. Ao utilizar a biblioteca de baixo n´ıvel o processo de criac¸˜ao, envio e gerenciamento de uma chamada de m´etodo ´e completamente manual. Bindings de alto n´ıvel fornecem proxies como uma alternativa ao processo manual, sendo objetos nativos que quando chamados s˜ao converti- dos em uma chamada de m´etodo que aguarda a mensagem e trata os valores de retorno de forma transparente.