Electrical computers and digital processing systems: multicomput – Distributed data processing – Client/server
Reexamination Certificate
1998-11-12
2001-08-21
Homere, Jean R. (Department: 2177)
Electrical computers and digital processing systems: multicomput
Distributed data processing
Client/server
C707S793000, C709S241000, C717S152000, C717S152000, C717S152000
Reexamination Certificate
active
06279030
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer-readable code that dynamically selects program components based on current values of one or more changeable attributes, and downloads those components on demand during program execution.
2. Description of the Related Art
Computer programs often provide different access capabilities to different users, based upon a user's role or classification. For example, a payroll application may enable an employee to view his salary, year-to-date tax information, and other relevant payroll data, while a management status is required before a user can change the values of those fields—or before the user can view the same type of information for multiple employees. As another example, a software code library management system may enable users of all classifications to view code modules, but may limit the ability to change the modules to users whose log-on information indicates that they are developers authorized to make such changes. This log-on information may be in the form of a user password, user department number, or other identifying information.
This type of access control is provided by coding appropriate authorization checks into the software, so that only the intended users are allowed to execute certain parts of the code. If an unauthorized user attempts to access that part of the code, an error message may be issued, or the code may simply do nothing until the user selects something for which he is authorized.
In one scenario, the user of this type of software may have the entire application loaded on his workstation, giving him in effect a “private” copy of the software that is not shared with other users. Or, in a second scenario, the application software may physically reside at a server. Each user wishing to execute the application establishes a network connection to the server, so that a single copy of the software is shared by multiple users. Typically, the data that is accessed (e.g. the payroll information, or the stored code modules, discussed above) when using an application that performs authorization checking will be stored remotely from the user's workstation, in a data repository (such as a database) that is accessible to multiple users (again, by making a network connection to a server).
With the advent of programming languages and techniques that allow dynamic location of code modules during program execution, a third scenario is possible. Some portion of the application software is resident on the user's workstation, with additional modules being stored elsewhere. There are a number of reasons why this mode of operation may be desirable. For example, the amount of code stored on the user's workstation can be decreased when modules are stored remotely. In addition, the user can have access to updated versions of code more easily when modules are stored in a centralized remote location, and code maintenance can be simplified, because each user's individual machine does not need to be separately updated. One technique with which this mode of execution is supported is through use of the Remote Procedure Call (“RPC”) protocol. With RPC, a programmer codes a module invocation (i.e. a procedure call) in the normal manner for the programming language in which he is writing, but only a “stub” for that module is generated during program compilation (where a “stub” is a special construct enabling the program to successfully compile without resolving the address of the referenced procedure). If the procedure is actually called during runtime, a request to execute the code will be forwarded to a server where the module is available (hence, the procedure call is a “remote” procedure call). That server will perform the function of the procedure, and return the results to the user's workstation, transparently to the user. (For a detailed description of RPC, refer to international standard ISO/IEC 11578, “Remote Procedure Call (RPC)”, dated 1996.)
Another technique that enables operation in this third scenario, which is usable in object-oriented environments, is known as “DSOM”, or “Distributed System Object Model”. “SOM”, or “System Object Model”, is an International Business Machines Corporation (“IBM”) implementation of the CORBA (Common Object Request Broker Architecture) standard developed by the Object Management Group. (SOM is a registered trademark of IBM, and CORBA is a registered trademark of Object Management Group, Inc.) SOM defines a way to create objects that can be accessed by programs without regard to the programming language in which the program is written, the specific compiler used to compile the programs, etc. DSOM, also from IBM, extends the SOM by defining a way to distribute SOM objects, so that they can be accessed by remotely executing applications. (The details of CORBA, SOM, and DSOM are beyond the scope of this discussion. Reference may be made to “The Common Object Request Broker: Architecture and Specification”, OMG Document Number 91.12.1 Revision 1.1, for more information on CORBA, and to “SOMobjects Publications”, IBM document number S96F-8649, for more information on SOM and DSOM.)
The Java programming language provides yet another technique for operating with only some portion of the executable program being loaded on the user's workstation. (Java is a trademark of Sun Microsystems, Inc.) Whereas RPC and DSOM provide for accessing remotely-stored procedures and objects, Java provides a different approach. When executing a Java applet, code modules are loaded from their remote storage onto the user's workstation if and when they are needed (i.e. if they are actually invoked during execution), so that execution occurs locally. (In addition, Java Remote Method Invocation, or “RMI”, provides for execution of remotely-located Java methods, in a similar manner to that described above for remote execution using RPC and DSOM.)
The three techniques that have been described for operating in the third scenario described above all provide for code sharing—whether by accessing a remotely-stored, shared copy of the code (as described for RPC, DSOM, and RMI), or by downloading a copy to users needing the code (as described for Java applets). However, each of these techniques has in common that a single, predetermined copy of the software will be accessed. If that software contains code that is authorization-protected, as described above, then the software downloaded onto the user's workstation will often contain some amount of code that this user cannot access (because the user likely will not qualify for all the defined access levels). This results in wasted storage space on the user's workstation, and a decrease in execution efficiency. While this may be merely a less-than-optimal working environment for some users, it can be a very serious problem for users of workstations when storage space is at a premium. For example, the user may be using a handheld computer such as the WorkPad from IBM. (“WorkPad” is a registered trademark of IBM.) Storage space on handheld computers is typically limited to several megabytes, in order to keep the device small and lightweight. (Storage constraints may exist on much larger machines as well, at a point in time, as is commonly known.)
In addition to wasting space by storing inaccessible authorization-protected code, space is also wasted if the downloaded software provides for execution in environments that are not supported by the user's workstation. For example, a module that displays the user interface may include code for several different types of display devices, and query the user's hardware at run-time to determine which device type is installed—and accordingly, which portion of the software to execute. Or, a report-generating software routine may contain code to generate the report on the display device as well as by printing it on an attached printer, leaving the final output choice to
Britton Kathryn H.
Graham Stephen
Kaminsky David Louis
Doubet Marcia L.
Homere Jean R.
International Business Machines - Corporation
Ray-Yarletts Jeanine S.
Wassum Luke S
LandOfFree
Dynamic JAVA™ class selection and download based on... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamic JAVA™ class selection and download based on..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic JAVA™ class selection and download based on... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2499292