D-Bus
Em computação, D-Bus ou DBus, um barramento de software, é um mecanismo de comunicação entre processos (CIP) e chamada de procedimento remoto que possibilita a comunicação entre vários programas de computador rodando simultaneamente na mesma máquina. O D-Bus foi desenvolvido como parte do projeto freedesktop.org, iniciado por Havoc Pennington da Red Hat para padronizar serviços fornecidos pelos ambientes de desktop do Linux como GNOME e KDE.
Imagem: KAMEERU · BY-NC-SA · Openverse
D-Bus é um mecanismo de comunicação entre processos inicialmente concebido para substituir os sistemas de comunicação de componentes de software usados pelos ambientes de desktop Linux GNOME e KDE (CORBA e DCOP, respectivamente). Os componentes desses ambientes de desktop são normalmente distribuídos em muitos processos, cada um fornecendo apenas alguns - normalmente um - serviços. Esses serviços podem ser usados por aplicativos clientes regulares ou por outros componentes do ambiente de desktop para executar suas tarefas. Devido ao grande número de processos envolvidos - incluindo processos que fornecem os serviços e os clientes acessando-os - o estabelecimento de comunicações CIP um-para-um entre todos torna-se uma abordagem ineficiente e pouco confiável. Em vez disso, o D-Bus fornece uma abstração de barramento de software que reúne todas as comunicações entre um grupo de processos em um único canal virtual compartilhado. Processos conectados a um barramento não sabem como ele é implementado internamente, mas a especificação D-Bus garante que todos os processos conectados ao barramento possam se comunicar entre si através dele.
Imagem: Clive G' · BY-NC-SA · Openverse
Modelo de Barramento
Cada conexão a um barramento é identificada no D-Bus através de um nome de barramento.O nome de barramento consiste de duas ou mais strings separadas por ponto que podem conter letras, dígitos, traços e underscores - um nome de domínio reverso. Um exemplo de nome de barramento válido é org.freedesktop.NetworkManager. Quando um processo se conecta a um barramento, o barramento dá para a conexão um nome de barramento especial chamado nome único de conexão (”unique connection name”, em inglês). Nomes de barramento desse tipo são imutáveis - é garantido que eles não mudarão enquanto a conexão existir - e, mais importante, eles não podem ser reutilizados enquanto o barramento estiver ativo. Isso significa que nenhuma outra conexão àquele barramento terá o mesmo nome único de conexão, mesmo que um mesmo processo feche a conexão ao barramento e a abra de novo. Nomes únicos de conexão são facilmente reconhecíveis porque eles iniciam com o caractere de dois-pontos :, cuja utilização é proibida em outras aplicações. Um exemplo de nome único de conexão é :1.1553 (os caracteres depois dos dois-pontos não possuem nenhum significado especial).
Modelo de objeto
Por causa da sua concepção original como um substituto para diversos componentes orientados a sistemas de comunicação, o D-Bus compartilha com seus antecessores um modelo de objeto no qual se expressa a semântica das comunicações entre clientes e serviços. Os termos utilizados no modelo de objeto D-Bus imitam aqueles utilizados por algumas linguagens de programação orientadas a objetos. Isso não significa que o D-Bus é de alguma forma limitado a linguagens POO - na verdade, a implementação mais utilizada (libdbus) é escrita em C, uma linguagem de programação procedimental. No D-Bus, um processo oferece seus serviços expondo objetos. Esses objetos tem métodos que podem ser invocados, e sinais que um objeto pode emitir. Métodos e sinais são coletivamente referidos como membros do objeto. Qualquer cliente conectado a um barramento pode interagir com um objeto utilizando seus métodos, fazendo pedidos ou comandando que o objeto faça ações. Por exemplo, um objeto representando um serviço de tempo pode ser solicitado por um cliente usando um método que retorna a data e hora atual. Um cliente também pode escutar sinais que um objeto emite quando seu estado muda devido a certos eventos, geralmente devido a um serviço relacionado. Um exemplo seria quando um serviço que administra dispositivos de hardware - como um USB - sinaliza um evento “um novo dispositivo de hardware foi adicionado”. Clientes devem instruir o barramento de que eles tem interesse em receber certos sinais de um objeto particular, já que o D-Bus só passa sinais aos processos que registraram um interesse neles.
Modelo de comunicação
O D-Bus foi concebido para ser um sistema de comunicação genérico e de alto-nível entre processos. Para atingir estas metas, as comunicações D-Bus são baseadas na troca de mensagens entre processos ao invés de “bytes puros”. Mensagens D-Bus são itens discretos de alto-nível que um processo pode enviar através do barramento para outro processo conectado. As mensagens tem uma estrutura bem definida (até mesmo os tipos de dados enviados no payload são definidos), permitindo que o barramento valide ou rejeite quaisquer mensagens malformadas. Neste quesito, o D-Bus se parece mais com um mecanismo RPC do que um mecanismo IPC clássico, com seu próprio sistema de definição de tipos e o seu próprio marshalling.
Imagem: desomurchu archive gallery · BY · Openverse
A maioria das implementações D-Bus segue a arquitetura da implementação de referência. Essa arquitetura consiste de dois componentes principais: A biblioteca libdbus (ou equivalente) internamente utiliza um mecanismo IPC nativo de baixo-nível para transportar as mensagens D-Bus requeridas entre dois processos nas duas pontas da conexão D-Bus. A especificação D-Bus não possui uma definição mandatória de quais mecanismos de transporte IPC específicos devem estar disponíveis para uso, e fica a critério da biblioteca de comunicação definir quais métodos de transporte ela suporta. Por exemplo, em sistemas do tipo Unix, como o Linux libdbus, tipicamente se utiliza soquetes de domínio Unix por trás do método de transporte, mas também dá suporte a soquetes TCP. As bibliotecas de comunicação de ambos processos deve concordar sobre o método de transporte escolhido e também qual canal de comunicação será particularmente usado para sua comunicação. Essa informação está definida dentro do que o D-Bus chama de endereço. Soquetes de domínio Unix são objetos do sistema de arquivos, e então podem ser identificado por um nome de arquivo, assim, um endereço válido seria unix:path=/tmp/.hiddensocket. Ambos processos devem passar o mesmo endereço para suas respectivas bibliotecas de comunicação para estabelecer a conexão D-Bus entre eles. Um endereço também pode fornecer dados adicionais para a biblioteca de comunicação no formato de pares chave=valor separados por vírgula. Dessa forma, por exemplo, pode-se fornecer informações de autenticação para um tipo específico de conexão que tenha suporte para tal.
Imagem: Wade Rockett · BY-ND · Openverse
O D-Bus foi iniciado em 2002 por Havoc Pennington, Alex Larsson (Red Hat) e Anders Carlsson. A versão 1.0 - considerada API estável - foi lançada em Novembro de 2006. Fortemente influenciado pelo sistema DCOP utilizado pelas versões 2 e 3 do KDE, o D-Bus substituiu o DCOP no lançamento do KDE 4. Uma implementação do D-Bus presta suporte principalmente a sistemas operacionais POSIX, e uma porta para Windows existe. É usado pelo Qt 4 e posteriormente pelo GNOME. No GNOME, ele gradualmente substituiu o mecanismo anterior Bonobo. Também é utilizado pelo Xfce. Um de seus pioneiros foi o Hardware Abstraction Layer (atualmente depreciado). O HAL utilizava o D-Bus para exportar informações sobre hardware adicionado ou removido do computador. A utilização do D-Bus tem crescido estavelmente além do escopo inicial de ambientes desktop para incluir uma quantidade cada vez maior de serviços do sistema. Por exemplo, o daemon de rede do NetworkManager, o Stack Bluetooth BlueZ e o servidor de áudio PulseAudio utilizam o D-Bus para fornecer (parcial ou completamente) seus serviços. O systemd utiliza o D-Bus wire protocol para comunicação entre o systemctl e o systemd, e também promove daemons tradicionais do sistema a serviços D-Bus, como o logind. Outro utilitário do D-bus é o Polkit, cujo daemon de autoridade de políticas é implementado como um serviço conectado ao barramento do sistema.==Referências==
