US 20050021698 A1
A system and method for a downladable just-in-time middleware called VEM that provides access to network services, including system services such as printing and local storage, to applications that run on Network Computers. The VEM configures the default client services and stores information about these services. When an application executing on the Network Computer wishes to use one of the services, it communicates with its local VEM. The VEM returns a hanlde to the appropriate service to complete the service request.
19. A method for providing on-demand access to and interaction with system services to applications executing on a network computer, comprising the steps of:
a) in response to a demand from a user, downloading executable code comprising a virtual environment manager for providing access to remote network system and application services;
b) identifying a set of system and application services;
c) configuring the set of system and application services by contacting a plurality of appropriate remote service providers for each particular one of the system and application services and downloading one of client stubs and a handle for each one of the service providers;
d) maintaining a list of configured services; and
e) providing access to the configured services.
20. The method of
a. Field of the Invention
This invention relates to network computing. More specifically, this invention relates to methods and means for providing access to network services (for example, system services such as printing and local storage) to applications executing on network connected computers.
b. Related Art
As the network computing paradigm becomes ubiquitous, simplified inexpensive desktop computers, known as the Network Computers, that have no means of independent existence will become common place. Such devices may run a low function operating system (for simplicity) and rely on servers for basic system services including local storage, printing, and monitoring. While traditional clients, such as PCs, provide their own basic system services they are also likely to seek additional services from the network.
Existing approaches used to provide these basic system services to applications include the existence of a full-feature operating environment on the Network Computer and/or the requirment that each application provide its own set of needed services. The former approach is not feasible for network clients because these computers are not necessarily equipped with adequate physical resources such as physical memory and attached peripheral devices (e.g., disk drives) to support a full-feature operating environment (e.g., in the case of a Network Computer). The latter approach has the drawback of making each application aware of the platform and environment it can be run under so that it can provide support for necessary basic system services. Further, the former approach adds to the cost of the network clients, while the latter approach adds to the complexity in the design of applications.
It is an object of the present invention to provide a flexible, powerful, and portable means for enabling network based services for clients.
In a preferred embodiment, a downloadable middleware called the Virtual Environment Manager (VEM) is provided. The VEM allows applications to be developed completely independently of the architecture and environment of a client computer and the servers it connects to. For a client (i.e., a network computer) to access a service, the VEM queries a Service Directory Table available on one or more connected servers. The access to the Service Directory Table returns a handle, which is used to connect to the indicated service provider.
The present invention will be understood by reference to the drawing, wherein:
A loosely coupled system suitable for use with the present invention is illustrated in
The Network Computers 106 can be embodied, for example, on a JAVA terminal, a personal digital assistant (PDA) or an internet terminal. The communication protocol is HTTP and TCP/IP. The network 112 can be, for example, a token ring. The service systems 102, 104(1), 104(2), 104(3) can be embodied, for example, on IBM RISC System/6000 machines using AIX 4.2.
A logical organization can be placed on the physical system desrcibed above. This organization can be described by a three tier client/server strategy. In this strategy, tier 1 represents the client function, tier 2 represents the service provider and tier 3 represents the data object server (i.e., information storage). The system described in the present embodiment relates to tiers 1 and 2 and the interface in between. The interface in between tiers 2 and 3 is unrestricted, so users can rely on conventional, tried and true data information access systems. Note that a service provider can be designed to either reside completely on a tier 2 server or to allocate its function between tiers 1 and 2 by providing a special service stub.
Each Network Computer includes a Virtual Environment Manager (VEM) 108(1), 108(2) that is downloaded from a Service Provider by way of the communication network 112. The VEM is embodied as program code instantiated in the random access memory (not shown) of the Network Computer. In particular, the VEM provides a base class called VEMCLASS (defined in Appendix A) that it relies on for defining a collection of objects (in the sense of “object oriented programming”). One of the objects included in each VEM is an active entity called the Virtual Environment Superviser (VES) 109(1), 109(2) that is responsible for maintaining the VEM state. In a preferred embodiment, the VES is an active JAVA object and is directly instantiated from the VEMCLASS. The VEM state includes a table of configured services 110(1), 110(2) and a table of active applications 112(2), 112(2). Both the table of configured services and the table of active applications are also instantiated in the random access memory of each Network Computer. Applications inherit from the VEMCLASS in order to interact with the VES. The object class is compiled with the application and bound to the name space of the application.
According to an embodiment of the present invention, when a network computer is switched on, it goes through a boot process in which it readies itself for use. At the end of the boot process, the network computer prompts the user for identification. The identification process can be, for example, typing in the user name and a password. After user identity verification, the network computer presents the user with a desktop environment.
The desktop environment is preferably a JAVA container. The JAVA container runs on top of a JAVA virtual machine. Both the container and the JAVA virtual machine are provided by a program such as a Web Browser 114(1), 114(2) (e.g. Netscape Navigator) which executes on the Network Computer. The browser can be downloaded during the Network Computer's boot sequence or provided as an integral part of the Network Computer.
As part of the initialization process, the browser downloads the VES and a configuration file for the user from a Service Provider. The VES uses the configuration file to set up the user's desktop environment (desktop). An example desktop (which can be in the form of a home page) is shown in
The initial logging and download of the home page is described in
When a VES is downloaded for a user, it initiates configuration of all services that are in the configuration file. The configuration file can be of a conventional flat file format. For example, the configuration file can be in the form of a Bookmarks file of the type used by Netscape Navigator 3.0. This configuration is performed by contacting the appropriate service providers and initializing the client's table of services 110 with the server information. Stubs are also downloaded for those services that reside on both tiers 1 and 2.
In addition to the currently configured services, the VES has access to all services available on the network. This enables a user to add any available service to the desktop and as a result to the user's configuration file.
Service access is provided by a Service Directory Manager (SDM) that maintains a table of services referred to as the Service Directory Table (SDT) 114 (shown in
When a Service Provider is connected to the network, it announces the set of services it offers to the SDM. The steps taken by each Service Provider in announcing the set of services it offers are shown in
An instance of the system state in which various client stubs are located at the Network Computers is shown in
The VEM will now be discussed in more detail. For reference, code definitions for the VEM include the VEMCLASS and the client and server interfaces. These are is shown in appendices A and B respectively.
Once the VEM has been downloaded and initialized, applications (APs) can be downloaded. (Note that APs are assumed to be applets in this discussion. The VEM supports applications, though applets are preferred for improved manageability.) In it's init( ) method, an AP should call the registerAFE( ) method. This call sets the AP's instance variable, VEM_id, to the class variable num_AFE, and increments num_AFE. Since nu_AFE is never decremented, the AP now has a unique id. The VES is then called to create an entry for the AP in the registry (the Table of Applications 112). At this time, the entry contains only the applet object reference, id and name, but it can be expanded later as needed. The registerAFE( ) method returns a unique key, called a “cookie”, to the AP to ensure that access to the AP information in the registry is controlled. The AP is now fully integrated into the VEM environment and is now capable of VEM function.
When the AP needs a service, it first requests the VEM to register the service using one of the registerService( ) methods. On service registration the VES checks the directory service (the SDM) using the LookupService( ) method to get the handle to the service and to see if the service has a stub. If it does, the stub is downloaded. The VEM then adds a service entry to the registry (the Configured Services Table 112) that includes the service's handle and, if appropriate, a reference to the stub. A cookie is passed back to the AP. Once the service is in the registry, both the AP and the VES can access it as needed.
The choice of which registerservice( ) method is called depends on: (1) whether a generic service is needed (i.e. one identifiable with just a name), or whether a more custom service is needed (e.g. one that is identified with a list of attributes as well as a name); and (2) whether the service shared. If the service is not shared, then the AP registering the service is the only one that gets access to the cookie. Otherwise, if the service is present, a cookie is passed back that is the same as those given to other APs for the service. If a shared service is not yet available in the VEM, the shared_service variable is updated to reflect the availability of a new, shared service, and a new cookie is passed back to the AP.
Access to shared services can be controlled using an access control list. Alternatively, shared services can be globally available, i.e. any AP can receive the cookie for the service just by asking for the service. Shared services are useful for minimizing the number, of server stubs resident on a client. They can also be useful if service behavior changes caused by one AP are used by another interactively.
Shared services can be removed from the VEM in various ways. According to a first embodiment, a reference count is kept for each service. The reference indicates how many APs currently have access to the service. When the reference count reaches zero, the service is removed by the VES. According to an alternative embodiment, only the AP that originally brought in the service is allowed to remove it.
Once the VEM state has been updated to include the service, the AP can get the handle by issuing the getServiceHandle( ) method, or get the stub by using the getServiceInstance( ) method. The AP is then free to make a connection of any sort and use the service. The VEM can be embodied to restrict how an AP and service communicate. When the service is no longer needed, the AP calls the RevokeService( ) method that updates the VEM state as follows: if the service is unique to the AP then the service is removed; if the service is a shared service then it is removed in accordance with the rules discussed above.
Now that the invention has been described by way of the preferred embodiment, various modifications and improvements will occur to those of skill in the art. Thus, it should be understood that the preferred embodiment has been provided as an example and not as a limitation. The scope of the invention is defined by the appended claims.