Copyright (c) 1999, 2000 Silicon Graphics, Inc. All Rights Reserved.
| Overview | Basic Concepts | GUI Components | Architecture | How To Write An App |
The Rhino Architecture consists of three different interacting susbsystems. The Communications subsystem handles the transfer of data between client and server. The Services subsystem models the system to clients and provides a mechanism for making changes to the system. The Services subsystem is further divided into client (or service proxy) and server components. The User Interface subsystem provides a framework and components for developing System Administration user interfaces.
Note: The material in this section is provided so that developers can understand how the Rhino architecture works. Rhino developers should never have to interact explicitly with the Communications subsystem; instead, Rhino developers use the services described in the next section.
The Communications subsystem is responsible for transferring data back and forth between the client and the server.
The Rhino server is called sysadmd, and is typically started by the client via inetd. The client connects to port 1 on the server machine, which is serviced by inetd. The client makes a request to inetd that it start the "sgi_sysadm" tcpmux service, and inetd runs sysadmd.
In order for the client to do anything useful, it must first authenticate itself with the server. When sysadmd is started from inetd, the user must provide a valid user name/password combination. sysadmd will not respond to any requests other than authentication requests until a valid user name/password has been supplied.
When sysadmd is started by inetd, it is running as root. Once a valid user name/password is specified, sysadmd sets its user id and its group id so that it is running with the permissions of the user name that was specified. In this way, the system is protected from security problems with sysadmd because the user can't do anything via sysadmd that he or she could not do by logging into the system.
Once the user has been authenticated, communication between the client and the server takes the form of commands from the client to the server and notifications from the server to the client. The basic unit of communication is the Packet, and each Packet contains a type which identifies which service it is associated with and a selector which indicates which command or notification is being sent. Additionally, each Packet contains key/value pairs of information which specify any additional information needed to convey the command or notification.
sysadmd starts the sysadmd service at startup. The sysadmd service has commands that the client uses to load and unload other services. The client specifies in a Packet which service to be loaded, and sysadmd looks in /usr/sysadm/services to find the dynamic shared object (DSO) which implements the requested service. sysadmd dynamically loads the service, and henceforth any packets received by sysadmd having the type for that service get routed to the service's handlePacket method. Additionally, a service may send Packets back to a proxy running on the client. The client matches the type of a Packet from the server to the appropriate proxy and calls its handlePacket method.
The Rhino Architecture provides four services that clients can use to access the server system. All services are available via the HostContext accessor methods getCategory, getAssociation, getTaskRegistry, and getPrivBroker. A HostContext instance is initially available to clients that have implemented RApp or RApplet subclasses, and is typically accessible in other contexts from a UIContext instance. Callers of HostContext methods do not need to be concerned with sending Packets or loading services. The HostContext accessor methods return service proxies which encapsulate all interactions with sysadmd.
The Category service is used by clients to get information about the system. On the server side, a Category monitors some aspect of the system, and maintains an Item for each entity. The client is notified when Items are added, changed, or removed.
The Category Service is described in more detail in Item and Category in Rhino.
The Association service maintains state representing relationships between Items on the system.
The Association Service is described in more detail in Item and Category in Rhino.
The Task Registry Service fetches lists of tasks from the server based on a variety of criteria.
The Privilege Broker Service lets the client run privileged commands on the server. This is the only way in which a Rhino client can make changes to the system.
PrivBroker provides a variety of ways in which the arguments may be specified to a privileged command. The runPriv method which passes arguments in the form of an AttrBundle is very convenient when the privileged command on the server uses libsysadmParam (see /usr/include/sysadm/SaParam.h) to parse its command line arguments. The Privilege Broker service translates the AttrBundle into a format that is compatible with the parsing done by libsysadmParam. Since TaskData (see User Interface section below) is derived from AttrBundle, it is possible that the TaskData containing the parameters that the user has specified for a Task may be passed directly to the PrivBroker service.
See the runpriv(1M) man page for more information on the Irix privilege mechanism.
The user interface subsystem consists of a few high-level framework components, along with many smaller components which can be used to build applications. The high-level framework components are:
The other components include:
The DynamicSize and DynamicSizeLayoutManager interfaces are the basis for Rhino dynamic geometry management. Rhino dynamic geometry management is implemented by Components whose heights depends on their widths, such as RichTextComponent. Dynamically sized Components implement the DynamicSize interface, which DynamicSizeLayoutManagers can use to determine the correct height to allocate for a Component given its width.
See the com.sgi.sysadm.ui, com.sgi.sysadm.ui.richText, com.sgi.sysadm.ui.event, and com.sgi.sysadm.ui.manager packages for complete listings of Rhino UI Components.
A Task provides one or more user interfaces which prompt the user for parameters for making a change to the system, and an ok method that gets called when the user presses the OK button. Since a Task can have more than one user interface (Form and Guide), and since the user can switch back and forth between user interfaces, the TaskData mechanism is provided so that data is not lost when the user switches user interfaces.
The Task's internal representation of what the user has entered is stored as Attributes in the TaskData. Each Component in each of the user interfaces of a task is bound to an Attribute in the TaskData, so that when the Component changes, the TaskData is changed, and when the TaskData changes, the Component is changed. Thus, all input is preserved when the user switches back and forth between Form and Guide, and the ok method can get the parameters to pass to the Privilege Broker Service from the common TaskData rather than querying the user interface Components.
