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.
- "D-BUS, 1/2"
- "D-BUS, 2/2"