D-BUS是一个大有前途的消息总线和活动系统，正开始深入地渗透到Linux®桌面之中。了解创建它的原因、它的用途以及发展前景。
D-BUS本质上是进程间通信（inter-processcommunication）（IPC）的一个实现。不过，有一些特性使得D-BUS远远不是“只是另一个IPC实现”。有很多不同的IPC实现，因为每一个都定位于解决特定的明确定义的问题。CORBA是用于面向对象编程中复杂的IPC的一个强大的解决方案。DCOP是一个较轻量级的IPC框架，功能较少，但是可以很好地集成到K桌面环境中。SOAP和XML-RPC设计用于Web服务，因而使用HTTP作为其传输协议。D-BUS设计用于桌面应用程序和OS通信。
桌面应用程序通信
典型的桌面都会有多个应用程序在运行，而且，它们经常需要彼此进行通信。DCOP是一个用于KDE的解决方案，但是它依赖于Qt，所以不能用于其他桌面环境之中。类似的，Bonobo是一个用于GNOME的解决方案，但是非常笨重，因为它是基于CORBA的。它还依赖于GObject，所以也不能用于GNOME之外。D-BUS的目标是将DCOP和Bonobo替换为简单的IPC，并集成这两种桌面环境。由于尽可能地减少了D-BUS所需的依赖，所以其他可能会使用D-BUS的应用程序不用担心引入过多依赖。
桌面/操作系统通信
术语“操作系统”在这里不仅包括内核，还包括系统后台进程。例如，通过使用D-BUS的udev（Linux2.6中取代devfs的，提供动态/dev目录），当设备（比如一个USB照相机）插入时会发放出一个信号。这样可以更紧密地将硬件集成到桌面中，从而改善用户体验。
D-BUS特性
D-BUS有一些有趣的特性，使其像是一个非常有前途的选择。
协议是低延迟而且低开销的，设计得小而高效，以便最小化传送的往返时间。另外，协议是二进制的，而不是文本的，这样就排除了费时的序列化过程。由于只面向本地机器处理的使用情形，所以所有的消息都以其自然字节次序发送。字节次序在每个消息中声明，所以如果一个D-BUS消息通过网络传输到远程的主机，它仍可以被正确地识别出来。
从开发者的角度来看，D-BUS是易于使用的。有线协议容易理解，客户机程序库以直观的方式对其进行包装。
程序库还设计用于为其他系统所包装。预期，GNOME将使用GObject创建包装D-BUS的包装器（实际上这些已经部分存在了，将D-BUS集成入它们的事件循环），KDE将使用Qt创建类似的包装器。由于Python具有面向对象特性和灵活的类型，已经有了具备类似接口的Python包装器。
最后，D-BUS正在freedesktop.org的保护下进行开发，在那里，来自GNOME、KDE以及其他组织的对此感兴趣的成员参与了设计与实现。
D-BUS的内部工作方式
典型的D-BUS设置将由几个总线构成。将有一个持久的系统总线（systembus），它在引导时就会启动。这个总线由操作系统和后台进程使用，安全性非常好，以使得任意的应用程序不能欺骗系统事件。还将有很多会话总线（sessionbuses），这些总线当用户登录后启动，属于那个用户私有。它是用户的应用程序用来通信的一个会话总线。当然，如果一个应用程序需要接收来自系统总线的消息，它不如直接连接到系统总线——不过，它可以发送的消息将是受限的。
一旦应用程序连接到了一个总线，它们就必须通过添加匹配器（matchers）来声明它们希望收到哪种消息。匹配器为可以基于接口、对象路径和方法进行接收的消息指定一组规则（见后）。这样就使得应用程序可以集中精力去处理它们想处理的内容，以实现消息的高效路由，并保持总线上消息的预期数量，以使得不会因为这些消息导致所有应用程序的性能下降并变得很慢。
1
2
下一页>>
下载本文示例代码
阅读(261) | 评论(0) | 转发(0) |
