Electrical computers and digital processing systems: multicomput – Remote data accessing – Accessing a remote server
Reexamination Certificate
1999-04-13
2002-08-20
Wiley, David (Department: 2158)
Electrical computers and digital processing systems: multicomput
Remote data accessing
Accessing a remote server
Reexamination Certificate
active
06438590
ABSTRACT:
FIELD OF THE INVENTION
Embodiments of the present invention relate to computer systems hat accomplish distributed processing with shared objects, and to methods of installing and maintaining distributed processing programs.
BACKGROUND OF THE INVENTION
A distributed application program is a set of member programs written for cooperation on a network of computers. Each computer is a node of the network. Each member generally operates on a physically separate node and communicates with other members of the set to accomplish a distributed processing objective. Examples of such objectives include sharing information, sharing access to a peripheral input or output device, and sharing other services.
The basic unit of information storage is the computer file and, for executable information, the program object. To share information, a conventional service at a minimum employs a naming convention for files, accesses a file by its name, and makes a copy of the contents of the file onto a destination node for efficient use (e.g., reading and writing) by the member at a requesting node. While an application program may exist as a file or group of files, such a program in operation may be better understood as a process involving a collection (or set) of objects, each object being able to communicate with other objects by sending and receiving messages and able to perform requested services (i.e., operations). An object may control access or use of data by, for example, providing a limited number of standard operations on the data. Sharing a service is conventionally accomplished either by copying the requisite program files to the requesting node, or by employing a naming convention (e.g., an application program interface) and communicating messages (i.e., passing parameters and results) with objects of the member programs that make up the service.
As an example of a computer system with multiple services, consider a conventional office computer system for word processing. Each word processing application program may require a discovery service to locate printers it can use. Because the number and types of printers in an office computer system is subject to change, a word processing application program may call the discovery service to obtain current information about printers. When the discovery service searches the network to identify printers, the discovery service uses a significant portion of the computer network capability, perhaps slowing other users' access to files on networked disk drives. To prohibit nonessential network traffic related to each word processor's request for discovery, a system manager may locate the discovery service on only one computer of the network and require each word processing application program to call the same discovery service. This one discovery service is then able to search for printers, perhaps once per day, storing the search results and then respond to all requests for discovery with the result of the daily search; as opposed to performing a search in response to each separate request for discovery.
Communication between objects (e.g., an object of a word processing application program and an object of a discovery service) may be obtained using the industry standard Common Object Request Broker Architecture (CORBA). The structure and operation of CORBA and its components is described in “The Common Object Request Broker:
Architecture and Specification” and references cited therein all of which are incorporated herein by reference. Such an architecture may include a naming service. The naming service includes a database that associates an object name and a corresponding object reference. Each object desiring communication with another object calls the naming service, passing to it a name of the desired object. For example, when a word processor application program having a printer object desires to communicate with a reporting object of a discovery service, the printer object calls the naming service and passes the name of the reporting object. The naming service returns to the printer object an object reference to the reporting object. The object reference may then be used in subsequent communication.
Distributed application programs based on CORBA are conventionally implemented according to design rules that may complicate installation and maintenance. For example, such an application program is expected to be able to contact the CORBA object request broker (ORB) to obtain access to a shared object. The distributed application program must be installed and maintained to account for the cases when the ORB is completely unavailable and when service by the ORB is likely to be inefficient from a system operations standpoint. Information to intelligently handle these cases is generally unavailable to the programmer who develops the application program. Programmers conventionally assume that the ORB is available when the application program is executing; and, that the source code for the application program will be revised if systems efficiency becomes an issue. Application programs built on these assumptions may be impractical for mass marketing.
A distributed application program exhibits an object sharing strategy in the manner in which it was programmed to behave. When developing the application program, a programmer's assumptions regarding object sharing constitute a sharing strategy. For example, the program may be written on the assumption that a particular object is shareable or may (at run time) determine whether a particular object is shareable. For each shareable object, the sharing strategy includes assumptions or determinations concerning: (a) whether the services and objects needed to permit sharing are actually available; (b) whether sharing will be accomplished through a CORBA ORB; (c) whether sharing will be accomplished in some other manner than a CORBA ORB; (d) whether similarly named objects are assumed not to exist, are expected to exist, or are to be discovered or confirmed by testing; (e) where similarly named objects are presently located; and (f) which of several similarly named objects is to be used. When developing a service for multiple computing environments, program complexity increases dramatically as the sharing strategy becomes more sophisticated.
In many cases, placing the intelligence to revise object sharing strategies in each application program wastes system resources. For example, when each application program must contain the logic for determining a sharing strategy for efficient network operation, the network overhead involved in cooperating with the network server to make an efficiency determination may consume the efficiency expected to be gained.
A system manager may not be able to revise the sharing strategy implemented by the programmer. Inconsistent sharing strategies of several application programs may interfere with installation or concurrent use of such application programs. If a system manager determines that network utilization would improve if object sharing were revised, the system manager may be faced with reprogramming each service that uses the particular shared object. In complex systems this approach to improved network efficiency may be cost prohibitive.
Another conventional approach is to expect the user to maintain object sharing strategies. A CORBA based service cannot expect the user to supply or maintain object sharing strategies because the user may be unaware that shareable objects have been installed, relocated, or deleted. The user may be unaware and unable to verify that greater system operating efficiency may result when an object is shared with or without using the CORBA ORB.
When, for example, a new word processor is to be added to the computer system described above, the word processor may fail because objects on remote nodes were not found and used. At the time of installation, it may be impossible to specify in advance an appropriate object sharing strategy. Because neither an application program developer (a programmer), nor a system manager, nor a skilled use
Gartner M. Scott
Simpson Shell S.
Hewlett--Packard Company
Wiley David
LandOfFree
Computer system with preferential naming service does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Computer system with preferential naming service, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Computer system with preferential naming service will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2893610