The ICT-Business is known for strategic terms. One of those terms, which was used quite a lot over this year, is services. The term is interpretable; however, the focus was on technical concepts implemented to serve for a sharply rendered use case, like managing user data and authentication. Services in that sense are served over a type of network. Despite the first impression, they are not served to a user but to a calling application. This client utilizes one or more services for internal purposes. Though, the user may be expected to provide data (the password, for example) or to wait and receive a gathered result.
From a distant viewpoint, services in the above sense are developed for technical reasons. They are expected to enhance the sharing of (mainly server or system) resources. Further, they shall control the process of sharing to protect vulnerable resources. Taking a closer look, they shall substitute the old paradigm of an open system with a paradigm of a closed and controlled system. The term services in the above sense also implies locking in customers and positioning on the global ICT-playground that is drifting unstoppable to a fully mobile and networked playground with frequently changing or cross-utilized products, providers, and carriers.
All global players have introduced such lock-in services and will go further in that direction. Here is where D-BUS comes in. D-BUS is a free, lightweight and efficient substitute for aging and/or hard to utilize Inter-Process-Communication solutions like CORBA or COM. D-BUS concentrates on the messaging part; it does not restrict the possible services in any way. The documentation loosely specifies services as callable applications that must follow some technically necessary communication rules (like on Internet). Though this is, at the first look, common for IPC, vendors tend to restrict (if not cut off) this openness by entangling their implementations with the distributed environment, which is settled on multifold protocols and other regulations that reduce the environment to a type of sandbox (At least, the vendors throw lots of working hours at the development. See Eclipse(TM) or the recently illuminated Singularity(TM) project.) It is quite visible that service and contract-based environments, in combination with trusted platforms, are ought to guarantee the future lock-in strategies.
D-BUS is not intended for being strategically entangled with services. However, I fear that this rhetorical difference, in which I find a real advantage over proprietary strategies, will not play out well. D-BUS is very popular in the free-source community; and its lack of dependencies is seen as an advantage. That it does not even settle on a well-discussed service framework seems like a disadvantage to me, though. Without clear terms and rules incompatibilities will come up at every node of the network. There will be multiple concurring services available on a D-BUS network, but a client will not be capable of utilizing just two of them. The open network will only manage virtual lock-ins and feel like the proprietary cousins.
D-BUS draws complexities that can not be mastered without a shift to a well-discussed D-BUS paradigm. The problem is that, up to today, the resources of a computer are discussed in terms of applications and frameworks. Services instead provide individual solutions for the case. To successfully establish a service network (even locally), the network must provide nodes with clearly distinctable and reliable names and addresses (paths). Every such node manages a pool of only one class of services. Services can be combined and updated at runtime. The first pool provides dialogs for every case.
Such a service network differs fully from how today’s environments are designed. This is why I fear that the potential of D-BUS will be left unused. D-BUS will become subordinated to the needs of the applications, which will remain the monolithic frontends they are today and serve virtual lock-ins to selected resources.
Discussing a service network is not an easy task. For example, multimedia frameworks obviously must implement more than one service to expose their capabilities over D-BUS (a simple player-service, a mixer-service, a filter-service, etc.). To generate an advantage for the clients, just serving the established interfaces is not enough. The frameworks would have to assimilate into one generalized multimedia resource on the D-BUS network. Only a well-discussed D-BUS framework can guide this process successfully.
Not only backends generate resources. For example, I use totem with gstreamer for playing audio but xine-player for watching digital tv. Sometimes I would like to have both running in parallel (one in standby-mode). In those cases I wished I had a mixer application that displays faders for the running media applications instead of for the audio channels. But how can such a mixer application ever instruct multiple (possibly unknown) media-players if they wait at individually chosen D-BUS addresses and provide individual interfaces? Should instead all media-players support this (one of possibly many) mixer application(s)?
The above shows that the implementation of a message bus alone can not guarantee any advantage over the current situation. It may even worsen it. Keeping the problem at the service or the client-side is not a solution either. This is why I want to discuss a mediating D-BUS framework at this place in the hope that it is interesting and useful to developers in general.
The question is: How shall independently developed services and clients find and work with each other if the network is open and the services are not part of a lock-in strategy like in the proprietary world? The only answer I know is that general service daemons must mediate between the clients and the services. These daemons have well-known addresses; and they focus on only one specific subject. This implies that a service daemon of this type is not developed to expose a full media framework to the network. Its intend is as simple and easy to grasp as its name (players, recorders, mixers, alerts, …).
A service daemon is mainly a small manager that provides a generalized interface to be used by both the supportive framework and the potential client. The interface is reduced to the job-dependent semantics. It communicates only event-dependent changes of attribute values. The object that provides the relevant attributes is implemented in the service daemon. For example, the mixer daemon implements an object that is used to remember the D-BUS address, the current state, and some other necessary values to control a single fader on the D-BUS network. The object is maintained in an object array (the resource list).
Both client and service can send events to the daemon. An event can target at one or multiple registered objects and attributes. Typical events are new, read, write, or signal. The service daemon manages an alert service (event handler) to inform about changes (like when a service sends a delete event to unregister an object). That’s it, mainly. The most important aspects are the specialization of the daemon and the well-discussed interface. It should be a very simple interface, best is similar if not identical in most parts to the interfaces of the other service daemons. At least the codebase should be reusable.
There are lots of aspects not discussed here. For example, service daemons must manage concurrent services in a sane way. At least some informative flags (like UN/STABLE, BACKEND_NAME, and BACKEND_VERSION) must be gathered. A service daemon should always run locally to be detectable without having to know the host. Service daemons of the same type may bridge hosts to share resources. Service daemons should be runtime-configurable. Daemons may map other daemons to provide service-bundles (profiles).
The idea has not fully settled down yet. However, I’ve invited the freedesktop.org people to read the article because I think that some semantic network is necessary if free platforms shall survive the next generation of proprietary paradigms.
About the author:
Dennis Heuer is a social scientist and specialized in system theory. His professional focus is on the use of ICT in education and development. Privately, he is developing a new environment targeting at non-governmental and educational institutions to provide a real-time (live) platform for communication, education, simulation, and easy prototyping.
1) No idea how Eclipse is related to DBUS
2) Wouldn’t it be easier if both xine and totem would register with a well known org.gnome.mixer service?
On the otherhand, some kind of store could be needed, both DCOM (registry), CORBA and Internet(DNS) have one (for good reasons).
There could be service org.freedesktop.dns, with a known interface that could answer questions like: “give me all printer spoolers”, etc.
So let’s talk:)
Who said D-BUS was going to provide a services network?
All well and good. But, from the standpoint of getting stuff done, we need to figure out how to integrate a Gnumeric spreadsheet and an Abiword document, possibly querying something in an RDBMS, just because.
DBus sounds like great infrastructure–I’ll follow anything Robert Love is working on based on his reputation alone. But the endpoints are as important as the line connecting them.
What about bonobo of GNOME ?