Electrical computers and digital processing systems: multicomput – Distributed data processing – Client/server
Reexamination Certificate
1999-04-02
2004-11-02
Vu, Thong H. (Department: 2142)
Electrical computers and digital processing systems: multicomput
Distributed data processing
Client/server
C709S241000
Reexamination Certificate
active
06813629
ABSTRACT:
FIELD OF THE INVENTION
This invention relates generally to computer systems, and more particularly to a method and apparatus for facilitating communication by objects across a network.
BACKGROUND OF THE INVENTION
For a number of years now, the computing model that has been used predominantly in large companies has been the client-server model. According to this model, a plurality of clients are connected to one or more data servers via a network to form an overall centralized system. In a client-server system, each of the clients is responsible for storing and executing whatever applications are to be run on that client, while the servers are primarily used as central repositories for storing and managing data generated and used by the applications. The main advantage of a client-server system is that it allows data to be stored in a centralized location, thereby making it possible for multiple clients to access the same data. The major disadvantage of this type of system is high cost. Because each client is required to have sufficient capability to store and to execute applications (many of which can be resource intensive), each client is typically required to be a high power, and hence, relatively high cost machine (i.e. a “fat” client). Also, because each client maintains its own set of applications, the cost of maintaining the system can be quite high. Each application on each client must be set up and configured individually, and each client, in the event of a software upgrade, must be upgraded individually. For a large company with a large number of client machines, the cost of maintaining the system can be exorbitant.
Because of the high cost associated with client-server systems, there has been a trend in recent years towards a “thin client” model of computing. According to this model, much of the processing burden is moved off of the clients onto a centralized application server. The application server is coupled to a plurality of clients via a network, and is responsible for storing and executing the applications requested by those clients. In a thin client system, the application server may also serve as the central data repository, or it may be coupled to a data server which serves as the central data repository, thereby giving rise to a three-tier architecture. Whatever form the overall system takes, the clients in a thin client system are relieved of most of the application execution burden. Primarily, the clients are responsible for rendering the user interface (UI) and performing other relatively simple functions. Because the clients are required to perform only relatively simple tasks, they may take the form of simple, low cost machines having minimal processing and storage capabilities. This gives rise to one of the main advantages of a thin client system, which is that of reduced cost. Because each client may be a low cost machine, the overall equipment cost of the system is significantly reduced. Also, because the applications are stored and executed in a centralized application server, the system is much simpler to maintain. Only the application server needs to be configured for each application, and only the application server needs to be upgraded. As a result, a thin client system is much more economical to implement and to maintain than a client-server system.
A thin client system provides significant cost advantages; however, these advantages come at the expense of increased network traffic. Because most of the application logic processing is performed by the application server, but all of the user input/output is received/rendered by the client, a significant amount of communication is conducted between the client and the application server. This communication is conducted across a network, which is a limited and scarce resource. In any computer implementation involving a network, one of the utmost concerns is that of minimization of network traffic. With excessive traffic, a network can quickly become the bottleneck of the entire system. Hence, for any application that is designed to run in a thin client environment, it is necessary for the application to manage communications across the network efficiently so that the network is not overly burdened.
One approach that has been taken to limit network traffic involves the implementation of a specific protocol between the client and the server using two separate processes, one process executing on the client and the other process executing on the server. These processes, which are specifically designed to understand messages from the other process, perform two main functions. First, each process interprets messages received from the other process to carry out functions indicated by those messages. For example, the client process receives messages from the server process indicating which items to render on the display. In response, the client process interprets the messages and renders the appropriate items. Because the processes are specifically developed to understand each other's messages, a very streamlined protocol can be implemented to minimize the amount of information that needs to travel across the network. A second function performed by the processes is the minimization of the number of messages that are sent across the network. This is typically achieved by bundling a plurality of sets of information into a single message. By putting multiple sets of information into a single message, the number of messages that need to be sent across the network is minimized. This approach has been implemented both in applications and in tools for facilitating the development of applications to minimize network traffic.
The above approach is effective for controlling network traffic; however, it achieves network performance at the expense of flexibility. One of the major drawbacks of this approach is that it does not allow users to freely define their own UI items. They may utilize only the items that the two processes have been designed and hard coded to recognize. For example, if the client and server processes know how to render a certain UI button, but the user needs to render a new customized UI button, the user will not be able to render the customized button unless the code for the client and server processes are altered. If the user has access to the source code, this may not be an overly burdensome process. However, if the user does not have access to the source code, which is often the case, especially in the tools arena, then the user would have to submit a request to the tools vendor to change the code. If the vendor agrees to make the change, then the vendor would have to go through the design and implementation process to effect the change. Thereafter, the vendor would have to release a new version of the software with the changes incorporated therein. This process could take several months, which is much too long to be practicable. As a result, the above approach is too rigid for many implementations.
A much more flexible and desirable approach to implementing a UI is the object oriented approach. Under this approach, the UI is composed of a plurality of independent objects, each object capable of independent operation and communication with the server, and each object capable of invoking the methods of other objects. In the object oriented paradigm, because each object is an independent entity, it is a relatively simple matter to: (1) replace one object with another; and (2) add new object classes. For example, if the user wishes to render a new type of button in the UI, the user simply defines the new type of button, and then starts using that new button in the UI. There is no need to enlist the aid of a tools vendor. Because it is so flexible and extensible, the object oriented paradigm is the preferred approach for implementing UI's.
One problem with implementing an object oriented paradigm in a networked environment, however, is that it tends to create a high volume of network traffic. As noted above, each object is an independent entity responsible for its own communication. Th
Buzsaki George
Kocherlakota Rama Rao
Stafford Seth
Hickman Palermo & Truong & Becker LLP
Nicholes Christian A.
Oracle International Corporation
Vu Thong H.
LandOfFree
Method and apparatus for facilitating object communication... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for facilitating object communication..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for facilitating object communication... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3361830