Check out the new USENIX Web site. next up previous
Next: Application-Specific Services Up: Thin-Client Programming Model Previous: Thin-Client Programming Model

Client Workspace

 

The client workspace provides a combination of functions in Metis. It provides the AFE container function, some of the conventional desktop functions, and a virtual environment of network services. These will be discussed in detail in this section.

Visually, the client workspace has a customizable layout that can be configured on a per-user basis using configuration information stored on a server. When a user logs on, all framework objects are instantiated.

UserProfile: The user profile includes an authorization object that contains user information including name and time of logon. The authorization object is passed with directory and code service requests. These support services recognize the object and restrict the user to only those AFEs and services that allow access by the user. Note that as long as services and AFEs are written to use the authorization object, a single logon procedure is possible.

Application Front Ends: The AFEs are downloaded to the client from a code server either when the workspace is initialized (if they were previously active) or when the user activates one on the workspace. They can be removed from the workspace as needed. Interactions among AFEs, such as data exchange and event notifications, are important especially when the AFEs are implementing sub-applications. Interactions are supported using tex2html_wrap_inline450 technology.

Virtual Environment Manager: A virtual environment manager (VEM) is a fundamental client object provided by Metis. It is the only entity with which an AFE can request Metis services. Prior to accepting an AFE's request, the VEM checks the AFE's signature to ensure that it is allowed access to the Metis system. As long as the AFE is recognized, the request is forwarded to one of the following VEM clients that act as delegates to Metis support services.

  1. Directory Client: The VEM has an internal directory client that communicates with the Metis Directory Service upon request of a service from an AFE or the workspace. The directory client and Metis Directory Service together provide late binding of services. At this time, services can be requested by name and service attributes though clearly, a higher level protocol can be supported. The directory client retrieves service stubs. If the service stub is an object, the directory client instantiates the object and passes a reference back to the caller AFE. If the service stub is a location, the directory client passes the location back to the caller AFE. To reduce the possibility of creating a flurry of messages, called a network storm, that can be caused by a failure of a widely-held service, the directory client retrieves and caches more than one service stub, when multiple providers of the same service are available. Should an active service fail, an alternate stub is fetched, instantiated if necessary, and returned to the AFE.
  2. Service Stub Loader: The VEM has an internal service stub loader that communicates with the service providers to download any stub code that the service might need for providing the service. The service stub loader is only used if the service stub returned by the directory needs to be instantiated.

AFE Loader/Launcher: The Workspace has an internal object that communicates with the Metis Code Server to download code and launch AFEs. The AFE Loader also checks for digital signatures, uncompresses, and decrypts AFEs as needed. Enabling a client to download code from a centrally administered source makes its use attractive for intranet environments where the software distribution and maintenance on traditional PC clients is expensive. The AFE Launcher runs the AFE when it is selected by the user.

System Services: AFEs need a common set of system services such as printing, storage, and error logging. While application services are private to each AFE, Metis allows sharing of system services. When an AFE requests a system service, an associated controller object is returned. If a stub to the requested service does not exist, the controller creates one by accessing the Metis Directory Service to indicate where the stub class is. The class is downloaded, and instantiated. The controller, in turn, manages the stub instances. For example, in Metis a print controller is a single point of access used by all to 1) create access to specific printers and 2) send information to them. Most of the controllers are provided to support the AFEs. However, the data controller is also used by the Metis workspace to access user configuration.


next up previous
Next: Application-Specific Services Up: Thin-Client Programming Model Previous: Thin-Client Programming Model

A. Purakayastha
Mon May 5 15:03:42 EDT 1997