Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
2000-09-13
2004-04-13
Follansbee, John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C717S139000
Reexamination Certificate
active
06721808
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention pertains generally to software applications designed for client-server use. More particularly this invention is directed to an improved system and method for providing automated remote object application support in a client-server object oriented environment.
2. The Prior Art
The client/server model is an approach to providing user-requested services or information. In the traditional client/server environment the client and the server are on the same machine or different physical machines connected by a network. The client asks for and receives services from the server. The client and the server are independent software applications; a client/server system would include those applications plus the operating systems on which each run, networking, and any related applications (such as a database).
The typical client/server model is based on computing as seen from the end user's viewpoint, not that of the system or the application. Thus, the client is the application a user interacts with directly, whereas the server application, responding to requests from the client, is typically invisible to the user. Data presentation is for the benefit of the user, so the client application typically does most of the data-presentation-related computing in addition to some data manipulation. The server application typically does all the work associated with data collection and retrieval; large databases, for example, reside on servers.
The definition of client/server highlights the fundamental tasks each component in the client/server architecture must perform. Understanding required functionality gives insight into the software complexity of the client/server components.
Looking at the client component again, the client acts as the user entry point into the client/server environment. The client must have a user interface component, either GUI or CLUI. The user interface component must include the ability to parse input commands, represent data in whatever form the interface makes available to a user, keep any needed context for the duration of this session, and keep and use context-sensitive history data of interface usage. Thus, the client application must include full UI support.
In addition, client applications carry out some data manipulation locally. The minimal amount of local data manipulation may be restricted to managing a cache so that recently retrieved information can be reused or recalled without needing to go to the server again. Local data manipulation increases in complexity from there, and often includes generating reports or user-interface representations of data retrieved from one or more servers. If the data is scientific or business modeling data, local data manipulation can be extremely intensive requiring powerful workstations.
Finally, client applications must be able to interact with at least one server. Interacting with any server, whether the server is local or accessible via a network, minimally means the client application program must be able to understand and use the communications protocol being used between the two. Often this is implemented at the session layer of the OSI layered network model, but any particular implementation in a client may require interacting at a lower layer depending on the specific application. If a single client is interacting with more than one server, it is entirely possible the client application will need to access different servers using different protocols, meaning the client application must have been programmed with the protocol knowledge built-in.
In general, the client application manages all of the user interactions which effectively hides the server and the network from the user. This creates the illusion that the entire application is executing without the use of servers or networks. The client application must make this interconnectivity and dependency work seamlessly at the user level.
Briefly, the server is a reactive process which is activated by requests from clients. A server is designed to service requests from any number of clients, so must keep client request context. The server provides requested information, computations, or services other requests from clients. A server does not interact with other servers as a server. If it is determined that a server itself needs information from another server, and this service is to be performed by other than the client, the server then takes on the role of a client and requests information from another server. At that point, the server is now a client. Since the “user” is a machine, the client application will not need to the human user interface portions of a typical client application. It will need all the other components, however. In a traditional setting, a server typically needs a more powerful hardware base than a client, and usually has far more support for secondary storage, multiple network connections, etc.
A very well known example of a client/server implementation is an internet client, or browser, such as Microsoft's Explorer or Netscape's Navigator, interacting over the internet with sites. A server is handling the interactions with the user at any site a user accesses with a browser (client).
In addition to the traditional kinds of data and services available from servers, the advent of object oriented programming has introduced new ones. As is well known in the art, object oriented programming entails defining a set or class of objects, including the objects' content and the operations that may be performed on the object, called functions or methods. In a local application, the objects created and instanced are made visible to, and can be used by, the program itself and other local programs. Objects may also be accessed remotely, that is, objects created and instanced on one machine may be accessing by a program on another machine. Objects accessible on one machine by programs running on another machine became an additional set of services available via client/server applications.
To access remote objects, clients need to make use of the remote object's functions and/or methods. To do this, the client program must have complete and detailed knowledge of both how to access the remote system over a network using some programming methodology, plus the details of how to use each remote object's specific functions and methods, including details on how to pass required arguments to them in the chosen programming paradigm. This creates a significant additional burden to the users of the server; they must learn the minutia of the programming methodology that allows access to server and be able to write client applications. In addition to what must be done for client programs in general, accessing remote objects adds the requirement that a detailed understanding of each remote object's interfaces be known. Note that this detailed knowledge must be known by the client programmer for each and every remote object type the client program may ever access—in a large networked environment this can be an overwhelming task. In addition, if even one remote object changes its interface in any way, even a “small” change, the client application would have to be reprogrammed to match, recompiled and re-installed.
Thus, although it is very desirable for client programs to access remote objects, the overall job is daunting. In addition to requiring the time of a skilled programmer to write the client application initially, there is a continuing maintenance problem with coordinating and tracking changes between every remote object type and every client application that accesses them. With multiple client applications wanting access to multiple remote object types, coordinating changes becomes logistically difficult.
Accordingly, there is need to simply the complexity associated with both the initial implementation of applications who access remote objects, and the maintenance of those applications when changes occur to the remote object's methods and/or functions. The pr
Follansbee John
Hoang Phuong
Sierra Patent Group Ltd.
LandOfFree
Real-time creation of distributed object shell commands does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Real-time creation of distributed object shell commands, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Real-time creation of distributed object shell commands will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3187519