What is Desktop-based Management ?

A desktop is a (graphical) environment that allows users to interact with the operating system by means of icons, windows and mouse. Popular desktop environments include the Macintosh Finder®, Linux KDE and Microsoft Windows®. Desktop-based management is the activity to manage networks and systems using standard desktop tools (for instance a text editor), methods (drag and drop) and paradigms (trashcan).

Why do we need Desktop-based Management ?

Network and system management are complicated tasks. In the past years several organisations have attempted to define new tools and paradigm for simplifying management. Probably the most popular activity is web-based management that is the application of World Wide Web (WWW) tools for the management of systems and networks. Many management applications and systems today offer a web interface (the author has released one of the early web-based management systems named Webbin). Although the web is slowly becoming integrated inside modern desktops, the web-based management paradigm has shown some limitations:

• Limited Operating System Integration
  Contrary to a common belief, the desktop has been web-ised and not the other way round. The consequence is that in desktop environments such as KDE every resource has a unique URL accessible using the browser. Instead it is not possible to access the same resources using a non-web application such as the shell or a text editor. The consequence is that users are now pushed to use to the web for daily activities whereas the contrary is not true. For instance, it is not possible to type on a shell more http://www.kde.org/ or date > file:///tmp/actualDate.

• No Scriptability and Task Automation
  One of the advantages of shell-based operating systems is the ability to write short programs using a script language such as the shell script, Perl and TCL. With the use of the web, every activity must be performed graphically by filling in forms and navigating through hyperlinks. In other words it is not possible to easily write an application that, exploiting a web-based management system, notifies the user when something bad happened. This because the output of those systems (HTML) is meant for display and not for program processing.

• Resource Integration vs. Resource Composition
  The web allows people to easily integrate different pages or (Java) applications by creating HTML pages that contains several frames each containing a different page/application (resource). Languages such as JavaScript can integrate different resources in a very limited fashion. Resource composition (software composition) instead, allows developers to compose different resources such as software applications and documents, and produce yet another composable resource. Composition methods range from simple scripting languages to complex ones such those offered by OpenDoc and OLE/ActiveX.

How does a Desktop-based Management System Look ?

The image below shows a Windows® user who has is browsing a SNMP agent running on a remote host. [Disclaimer: desktop-based management is definitively NOT specific to the Windows® operating system that has been used here just as example.]

The SNMP agent has been mapped to a network disc that has then been mapped as the E: disk. So what's the answer to the initial question How does a Desktop-based Management System Look?? Well, the answer is quite simple: it's invisible because it's completely integrated into the operating system.

What are the ideas behind Desktop-based Management ?

• Every management resource/information must be accessible operating system wide.

• The composition of management information (for instance weekly router usage) should be accessible from the desktop.

• Every management resource should be sharable in a general way (for instance in a file system like fashion but not like a RPC service that's not accessible from the desktop) similar to how desktops deal with files and printers.

What's new with Desktop-based Management ?

Desktop-based management offers several advantages with respect to other management paradigms:

• Ease of Use
  Every management detail is hidden by the desktop that shows management resources in a user friendly way. The value of a CMIP object instance can be represented as a file, a SNMP trap can be sent by dropping a file containing the trap information into a shared folder pointing to a remote host where is running a SNMP trap daemon.

• Operating System Integration
  Every management resource is integrated into the operating system. This allows virtually every application to be management-enabled. For instance, a user wants to draw a graph that shows the network utilisation there is no need to write/purchase a specialised application. People can use their favourite spreadsheet and write a simple macro that draws a graph.

• No Specialised Software Needed
  Suppose an istitution every night needs to save the state of the network (SNMP RMON agent for instance) or that a company needs to create a persistent CMIP agent. So far, the solution to those two problems was the devlopment of a new application or the modification of an existing one (the CMIP agent in the second case). If users would be able to access both CMIP and SNMP from a file system or the desktop, they may schedule a backup every night using the system backup tool, or duplicate the folder (that point to the agents) contents with a mouse click or a keystroke.

What's still missing in (most) modern desktops ?

These are some facilities I would like to find in modern desktops:

• Active Desktop
  Icons used to represent files are dead. If the file changes the used is not notified. A simple way of doing this is by changing the icon color or showing the name using a bold font. In general it should be possible to associate an action whenever resources change state.

• Output-Execute Files
  Today files have usually 3 (or 4) types of permissions: read, write, execute (and look). It would be usefull to add a new kind of permission named output-execute. In order to clarify this, suppose to have a shell script that prints some output when executed. When such file is edited/printed, instead of seeing the source code, the output of the execution should be seen and the code should be encapsulated -for instance- as description. This facility would allow people to create simple living applications. For instance imagine having an output-execute file named NetworkTraffic.gif containing an application/script that creates a graph of the current network traffic.

• Desktop-to-Desktop Communication
  Hosts working in a networked environment have limited ways to communicate. In general the most advanced facilities are offered by Unix® systems that allow to run applications remotely and to export displays to remote hosts. It would be nice not only to share a disk or a print but virtually everything such as processing power. Imagine for instance a computer that hosts processes different

• Operating System/Application Introspection
  Every resource/application should offer some facilities to introspect it. For instance it would be nice to create a dummy file (a sort of super-alias) that points to information such as number of times a specific application has been launched, memory used by a process, free disk space, or current network traffic. Combining this with an active desktop would be helpful to create simple management applications in a matter of mouse clicks. Another example is the following: if network ports would be accessible from the desktop, users could create symbolic links between ports just like with plain files. This allows -for instance- people to execute the following commands:
  1. ln -s /dev/ip/tcp/80 /dev/ip/tcp/80@server.company.com: every request received in the local port 80 (WWW) should be redirected to the port 80 of server.company.com (this is a simple web proxy).

  2. ln -s /dev/ip/tcp/13@timeserver.company.com /tmp/WhatTimeIsIt: everytime users print the content of the file, the localtime is shown.

© Luca Deri - April 1998