WO2001067244A2

WO2001067244A2 - Tier-independent data access framework

Info

Publication number: WO2001067244A2
Application number: PCT/US2001/005399
Authority: WO
Inventors: Sung Bin Im
Original assignee: Oracle Corporation
Priority date: 2000-03-03
Filing date: 2001-02-16
Publication date: 2001-09-13
Also published as: CA2401547A1; WO2001067244A3; AU2001245300A1; JP2004507801A; EP1307815A2

Abstract

A framework is provided for developing a data access application for use in various environments. When a data operation is performed on a middle tier server in a two-tier environment, the operation and its effects are communicated to the client so that the operation and effects may be recreated there. In a three-tier environment an event manager operating on a middle tier server captures the effects of operations for transmission to a client. A client cache stores a limited amount of data for a data operation and receives the effects of middle tier operations. The granularity of communications between a client and a server may be at the database row or record level rather than at the level of individual fields or attributes. Lightweight proxies allow a client to call a method implemented on a middle tier server without the client including all the programming logic needed to replicate the effects of the call.

Description

TIER-INDEPENDENT DATA ACCESS FRAMEWORK

BACKGROUND

This invention relates to the fields of computer systems and data access application programs. More particularly, a system and methods are provided for developing and operating a tier- independent data access application.

Today's application development tools generally allow an application (e.g., a program for accessing and/or manipulating data) to be developed and operate only within a computing environment having a specified form. For example, one development tool may be of use in designing an application for a two-tier environment (e.g., a client/server architecture) while a different tool is used for an application that will run on a stand-alone computer system. Typically, an application developed for one type of environment (e.g., two-tier) cannot operate in a different environment (e.g., three-tier) without significant modification, including re-compilation. Just as database applications evolved from stand-alone applications to two-tier (e.g., client/server) environments, three-tier environments are now becoming more and more popular. An illustrative three-tier environment for database operations may consist of a user's computer system (e.g., a client), a middle-tier computer server and a database server containing a database or other collection of data. Present application development tools for developing a data access application for a two-tier environment or a three-tier environment yield applications that are generally limited to the target environment. An application developed and operated in a two-tier environment cannot, without substantial alteration, operate in a three-tier environment, and vice versa.

One problem with existing application development systems is their inability to efficiently partition data processing among multiple tiers while maximizing performance and scalability. One ineffective manner in which this was attempted was by using remote procedures and/or methods. In particular, CORBA (Common Object Request Brokering Architecture), RPC (Remote Procedure Call), EJB (Enterprise Java Beans) and RMI (Remote Method Invocation) each implement some form of remote procedure or method calls. These systems allow, for example, a client operating on one tier to make a transparent call to another tier. However, the effect of this is to merely shift the processing burden to the other tier. These systems do nothing to allow processing to be shared between tiers or to promote programming uniformity and/or transportability. In particular, these systems do not ensure that the effect of a data operation on one tier is replicated or reflected on another tier.

A related problem in an environment having multiple tiers is that an application or portion of an application must typically be developed and tested on the tier on which it will ultimately operate. Otherwise, it must be substantially altered when transported to the final operating tier. Again, this problem is due to the inability of existing application environments to make the effects of data operations and related events uniform between participating tiers (e.g., a client and a middle tier server).

Existing application tools for multi-tier computing systems and environments also tend to suffer from inefficient communication schemes. In particular, the granularity of inter-tier communications tend to be quite low, thus requiring multiple communications in order to transfer even a small portion of data or perform a minor data access operation. Thus, in a multi-tier system having a high degree of programming uniformity among tiers, network performance is very low. Conversely, in order to maintain a high level of network or communication performance, programming uniformity must be sacrificed.

Another method of attempting to promote programming uniformity among multiple- tier environments is to simply synchronize data between inter-connected computer systems. In particular, some of the data maintained or cached by a server may be replicated on a client system. This, however, simply copies data states and does little to make an application transportable or uniform between tiers. In particular, synchronizing data states on multiple tiers does not maintain the information necessary to re-create or audit a particular transaction that caused data to change states. For example, although a data change effected in one tier may be copied to another, side effects or events related to the data change are not, thereby limiting the uniformity of the application between tiers. Thus, present application development environments hinder one from creating an application or programming model that can be operated in different multi-tier environments while promoting high performance (particularly network performance), uniformity and scalability. Therefore, an application development framework is desired in which an application may be developed and implemented for one environment (e.g., two-tier or client/server) and yet be readily usable in another environment (e.g., three-tier) and vice- versa. In particular, such a system may ensure that the operation or behavior of a particular data access application is highly uniform between different tiers. In other words, in a two- or three-tier environment such as those described above, a data operation requested by a user may be effected on a first tier and the effects or results of the operation are applied to a second tier as if the operation were native to the second tier.

In addition, the programming model will work within the resource constraints of a particular tier (e.g., such as a "thin" client) and communication (e.g., network) performance between tiers is maintained at an acceptable level.

SUMMARY

In one embodiment of the invention a system and methods are provided for developing and/or operating a data access application in either a two-tier or three-tier computing environment without modification. In particular, an application developed within an application development framework described below functions in either environment simply by specifying an appropriate switch or parameter when the application is executed. In this application development framework and computing environment, a cache is implemented on a client system (e.g., a user's computer system), which may be a "thin" client. The "thin" cache is populated with data provided by a server (e.g., a middle tier server or database server). Illustratively, the amount of data provided by the server to the client depends on the size of the cache and/or the amount of data needed by the client to execute a user's requested operation. The client cache may be kept small, thereby avoiding the need for extensive resources on the client. Communications between tiers (e.g., between a client and a server) are made efficient by focusing on a higher level than individual data values, as was done in previous application development environments. In particular, inter-tier communications may be performed at the level of database rows or records rather than individual fields or attributes in a row. Thus, instead of requiring multiple communications to update or transfer one database record, the entire record may be transferred in one communication. The number of inter-tier communications are further limited in one embodiment of the invention by using only one round-trip communication to effect a single data operation. For example, if a client system requires data from a server in order to meet a user's request, the request is passed to the appropriate server, which locates and loads all of the requested data (or as much as the client can store in its cache or display for the user at one time) along with any related events into a return communication. The client receives the return communication and its contents are used to recreate the actions/events that occurred on the server to satisfy the request. Thus, the effects of the data operation are uniformly applied to both the server and client, even while keeping the effectiveness or efficiency of inter-tier communications at a high level.

An event manager operates in one or more tiers (e.g., on a middle tier server and/or a client) in order to capture, recognize and report to another tier those events (e.g., data operations, exceptions) that occur on the host system. Thus, when a data operation is effected on a system in one tier, its effects are captured and forwarded to another tier so that a cooperating system can recreate or apply the same effects or results.

In order to avoid the need for a robust client (e.g., with a high level of resources), methods implemented on a server may be represented on a client by a lightweight proxy. Using the efficient communication scheme of a present embodiment of the invention, a lightweight proxy may call the corresponding method on the server. As a result, the event manager operating on the server captures the results of implementing the method and reports all of the effects of the call to the client in one communication, which is received and "replayed" or recreated on the client.

DESCRIPTION OF THE FIGURES FIGs. 1 A-C are block diagrams depicting illustrative multi-tier computing environments in accordance with an embodiment of the present invention.

FIG. 2 illustrates one set of communications between a client and a middle tier server for effecting one data operation in accordance with an embodiment of the invention. FIGs. 3A-B comprise a flow chart demonstrating a method of executing a data operation within a data access framework according to a present embodiment of the invention.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of particular applications of the invention and their requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein. The program environment in which a present embodiment of the invention is executed illustratively incorporates a general -purpose computer or a special purpose device such as a hand-held computer. Details of such devices (e.g., processor, memory, data storage, display) are well known and are omitted for the sake of clarity. It should also be understood that the techniques of the present invention might be implemented using a variety of technologies. For example, the methods described herein may be implemented in software executing on a computer system, or implemented in hardware utilizing either a combination of microprocessors or other specially designed application specific integrated circuits, programmable logic devices, or various combinations thereof. In particular, the methods described herein may be implemented by a series of computer-executable instructions residing on a storage medium such as a carrier wave, disk drive, or computer-readable medium. Exemplary forms of carrier waves may take the form of electrical, electromagnetic or optical signals conveying digital data streams along a local network or a publicly accessible network such as the Internet. An embodiment of the present invention is particularly suited for use with Oracle

Corporation's Business Component for Java framework. In particular, a data access application may be designed and developed using the design-time module of Business Component for Java, hosted by Oracle Corporation's JDeveloper. JDeveloper is an interactive Java development environment that allows the developer to develop Java applications quickly and interactively. Alternatively, other programming tools or IDEs

(Interactive Development Environments) may be employed in place of JDeveloper, as will be apparent to one of ordinary skill in the art. The resulting data access application may then be operated in a computing environment that includes the run-time module of Business Component of Java. In embodiments of the invention described below, programming objects, controls and other tools are provided to interface with database management systems in order to access, manipulate and display data for users. Thus, employing such an embodiment of the invention allows a data access application to be developed and/or operate on virtually any type of computer system (e.g., desktop, workstation, a "thin" client, a server). In a computing environment such as that described below, the data access application promotes data uniformity (e.g., uniformity of data states and computing events) between tiers. The APIs (Application Programming Interfaces) provided to application developers in embodiments of the present invention may be constructed and implemented using an object- oriented programming language such as Java.

Introduction Database applications and other applications for accessing data have evolved from centralized systems (e.g., a mainframe and dumb terminals) to today's client/server, two-tier and three-tier computing environments. For example, in client/server architectures both the client and server computers may possess sufficient resources for storing and/or manipulating data. Virtually all data access applications used in the centralized systems required extensive modification in order to function in a client/server or three-tier environment.

Although two-tier environments are still popular for data access applications, many organizations are adopting three-tier environments. In a typical two-tier environment a user application runs on a computer system and interacts with a separate database server to retrieve, manipulate or otherwise access stored data. The user application contains most of the business logic in this architecture. In an exemplary three-tier environment, however, a user may initiate data operations on his or her client system (e.g., a laptop, notebook or desktop computer), but a middle tier server is now interposed between the client and the database server. The middle tier server may, for example, comprise an application server operating a data access application that is designed to manage access to the data stored on a database server. Thus, in a three-tier system most business logic is moved to the middle tier server where it becomes available to multiple clients. Among other benefits, this architecture improves data security, auditing and accountability.

Thus, a primary difference between two-tier and three-tier environments may be the location of most of the business logic employed or invoked by an application. In a two-tier system it is in a user program operating on a client computer. In a three-tier system it is in the middle tier server. As a result, an exemplary two-tier system may require each client computer to be relatively robust or rich in resources because it must execute complex business logic. However, in an exemplary three-tier system the burden of executing most of the business logic is placed on the middle tier server, where it can be shared by multiple clients. Thus, among other benefits, three-tier environments may be more suitable for thin clients.

To avoid the difficulties that were encountered in migrating from a centralized system to a two-tier architecture (i.e., extensive software modification), it would be advantageous to develop data access applications so that they may operate in either a two-tier or three-tier environment without alteration (e.g., without requiring re-compilation). One illustrative framework for developing and implementing a data access application in a multi- tier environment is disclosed in the following sections, along with methods of implementing its various components.

By using the disclosed or a similar framework, a data access application may be developed for use, and then operate, in either a two-tier or three-tier environment. Illustratively, the application may be operated in either environment by simply specifying an appropriate parameter at the time the application is executed. For example, one switch or parameter may be specified if the application is to run in a two-tier mode, and another may be specified for a three-tier mode.

In a framework described below a user operates a client computer system, which may be a "thin" client having few or limited resources. The user's computer system need not, however, be a thin client and one or more embodiments of the invention described herein will operate with robust client systems with little or no modification.

One or more databases or other collections of data are maintained on a database server that, in a three-tier environment, is separated from client systems by a middle tier server. The middle tier server operates an application server program to manage access to the data. For example, in one form a three-tier environment may include users operating desktop, notebook or other computing devices and communicating with the middle tier server via a network such as the Internet. A firewall, proxy server, gateway or other security or access system may be interposed between the clients and the middle tier server.

In general, a client computer system in a three-tier environment in a present embodiment of the invention has fewer resources (e.g., lower processor speed, less memory, less storage capacity) than the middle tier server through which it accesses data. The communication link between the client computer and the middle tier server may be relatively slow (e.g., less than 1.544 Mbps) because of the novel and efficient method (described below) with which data and other information is exchanged between these two tiers. As one skilled in the art will appreciate, however, a faster link may be employed to further enhance the operation and efficiency of the framework.

FIG. 1 depicts an illustrative three-tier environment in which a data access application may be developed and/or operate according to a present embodiment of the invention. Environment 100 comprises clients 102a, 102b and 102c, middle tier server 104 and database server 106. Various communication links (e.g., dedicated, dial-up) may be employed to connect database server 106 to middle tier server 104 and middle tier server 104 to clients 102a, 102b, 102c. Illustratively, clients 102b, 102c communicate with middle tier server 104 using network 112, which may be a private network or a public network such as the Internet.

The following are some of the major components that may be incorporated into one or more embodiments of the novel data access framework: a client cache (maintained on a client system), an event manager (e.g., operating on a middle tier server), lightweight proxies (operating on a client computer), and the use of an object-oriented programming language such as Java. These aspects of the invention are described further in the following sections. In addition, a novel method of communicating between client systems and the middle tier server is implemented. In particular, and as described in a following section, communications between these two tiers are clustered or aggregated in order to improve communication (e.g., network) performance levels. The novel form of communications improves data and programming uniformity between tiers by allowing one tier to inform another of data changes, exceptions and other events that may then be implemented or effected on the other tier. In short, whenever a data operation is performed, the side effects or results of the operation and any events triggered by the operation are captured and passed to the other tier, in a single communication, where they may then be recreated or "replayed." Because virtually all data and/or other information concerning a data operation or other event is sent in one communication, fewer communications need to be transmitted - thereby improving the efficiency of inter-tier communications.

For a data operation requested by a user application operating on a client system, data updates, related events, etc., may be accumulated on the client system and then packaged into one communication to the middle tier server. Similarly, any requested data, any exceptions encountered on the middle tier server, any related events and data changes, etc., may be gathered on the middle tier server and returned to the client in one communication.

In particular, when a user initiates a data operation or data request, the operation may be performed first on the middle tier server. In this case the middle tier server receives a message from the client system that includes the operation (and possibly other requests or operations). The middle tier server then performs the necessary processing (e.g., access the database server, locate one or more database rows or records) and returns all the results (e.g., data, exceptions, other events) to the client in one communication. When the client receives the communication, it may replay or apply the contents of the communication in order to update the user's data, fire (i.e., perform) the same events, throw the same exceptions, etc. One skilled in the art will recognize that this scheme is far more efficient than existing methods in which one field, attribute or data value is retrieved at a time, which requires numerous communications to effect one data operation and results in poor network performance.

A user operation may, however, be performed first on the client system, in which case the middle tier receives a message identifying the operation and/or the results of that operation as applied on the client. The middle tier server may then perform the operation or just apply the results. Illustratively, however, the middle tier server performs the operation because it may trigger other events specified in the programming logic residing on the middle tier server (which are not triggered on the client). The results (e.g., side effects, other events) of the operation are then returned to the client as usual.

Illustratively, a client cache is configured on a client system to store multiple data objects or items. In particular, the cache is designed to store enough data to facilitate the execution of a user's specified operation and possibly a limited number of subsequent operations, but is not meant to replicate a large set of data such as may be stored on the middle tier server. Illustratively, the client cache is populated by the data access framework in response to communications received from the middle tier server. In one embodiment of the invention an event manager may be configured to intercept events, exceptions, warnings and messages that occur on the middle tier when a user's data operation/request is received and applied. In particular, the event manager passes these exceptions and messages to a client system so that it may take appropriate action or apply the same side effects that occurred on the middle tier server. The event manager thus helps ensure that individual events, rather than just data states, are propagated between tiers of a multi-tier computing environment. In particular, in previous environments data values may be passed between tiers, but not the circumstances (e.g., an event) associated with the data values. In addition, however, the event manager introduced above may enforce the correct timing or sequencing of events, such as exceptions. A middle-tier event manager may thus propagate an event to a client computer complete with data and in the exact sequence that the event transpired on the middle-tier. The client may then replay the event in the correct order. User interface controls on a client, for example, often rely on a source located on another tier for the data needed to update a display or scroll through a list of items. It is crucial to ensure that the elements of an event are provided to the user interface control in the correct order.

Lightweight proxies operate on client systems and represent objects through which the clients invoke or manipulate corresponding objects on a middle tier server. For example, given an employee object (e.g., residing on the middle tier or in a database), a lightweight proxy for the employee object may reside on a client system. The lightweight proxy allows a user to operate on the employee object in a uniform manner regardless of whether the user is working in a two or three-tier environment. In particular, if the user invokes a "GiveRaise" method for the employee object to give an employee a raise, the proxy may route the call to a corresponding "GiveRaise" method on the middle tier, which then performs the actual implementation. Results or events associated with the GiveRaise call are then returned to, and recreated on, the client.

In previous multi-tier computing environments, proxies might have been used to access objects across tiers, but only by marshalling or exchanging method parameters. In the GiveRaise example above, a call from a client computer to the GiveRase object on the middle tier may include a raise percentage or amount as one parameter. A previous environment would supply this parameter and respond with just a return value (e.g., new salary). However, in one embodiment of the invention all data changes, events and exceptions are sent with the return value so that they may all be played back on the client system. Thus, if the GiveRaise method on the middle tier that is invoked by the lightweight proxy on a client causes other programming logic to execute (e.g., to update a payroll table), those effects are also passed back to the client.

In a present embodiment of the invention an application development and/or operating framework is provided in which data may be accessed and manipulated while promoting uniformity between tiers in a multi-tier computing environment. In particular, all data operations and events associated with operations on the data (e.g., "side effects" of a data operation) are synchronized or replicated between a client computer system and a server through which the data is accessed. Therefore, not only are identical data states maintained among the multiple tiers, but the manner in which data is altered is also known to each tier. This is quite different from previous multi-tier systems that addressed only the issue of

"what" (i.e., data) changed. In a present embodiment of the invention a multi-tier system is provided to coordinate, between tiers, "how" that data changed. FIG. IB is a block diagram of an exemplary two-tier environment in which an embodiment of the invention may be applied. In the illustrated two-tier environment, middle tier 104 acts as a client and the middle tier server. Thus, it contains user program 204a, middle tier objects (e.g., programming objects) 204b and middle tier server cache 204c. The user program accesses data stored on database server 106 through the middle tier objects. User program 204a contains a user's programming logic and works with middle tier objects 204b. In particular, the user program may initiate a call to a middle tier object. When a middle tier object is invoked, it may cause various data to change and events to be fired (i.e., performed), and may cause other side effects determined by the programming logic installed with the middle tier objects.

Data changes (e.g., changes to data stored on database server 106) resulting from execution of a middle tier programming object are stored in middle tier server cache 204c, while fired events are returned to the user program. Thus, in the two-tier environment depicted in FIG. IB, a user program can directly access objects within the data access framework (e.g., middle tier objects 204b) without using proxies, and does not need a separate client cache. Programming calls and call returns need not be packaged into formal inter-tier communications as in a three-tier environment.

FIG. 1C is a block diagram showing additional detail of an exemplary three-tier environment such as environment 100 of FIG. 1A, according to one embodiment of the invention. In FIG. 1C, an illustrative client such as client 102a of FIG. 1 A includes user program 302a, one or more lightweight proxies 302b, coordinator 302c and client cache 302d. Middle tier server 104 in this embodiment includes event manager 304a, middle tier objects 304b (through which data on database server 106 are accessed) and middle tier server cache 304c. One advantage of an embodiment of the present invention is that user program 302a of the three-tier environment of FIG. 1C is essentially the same as user program 204a of the two-tier environment of FIG. IB. When the user program is executed, the user may specify a switch or parameter to indicate whether the program is to run in a two-tier or three-tier mode. Appropriate program modules are then loaded and the program runs in the specified mode. In either operating mode, the user program is developed to use interfaces (e.g., Java interfaces) to access middle tier objects.

In the embodiment of FIG. 1C, the interfaces that user program 302a uses provide method specifications but not implementations. The user program therefore does not have direct access to or knowledge of the middle tier objects. Instead, lightweight proxies are provided. The lightweight proxies route calls for particular middle tier objects to the middle tier, where a corresponding method is called.

When user program 302a calls a lightweight proxy 302b representing one of the middle tier objects 304b, the call is passed to coordinator 302c, which represents the data access framework. Coordinator 302c, as described in following sections, may gather one or more object calls, data operations, results, events, etc., from the client and forward them in a single, efficient, message to event manager 304a of middle tier server 104. For example, client cache 302d may be holding data changes, operations and/or other effects or results that have not yet been sent to the middle tier server. The coordinator packages all of these into the message. CORBA (Common Object Request Brokering Architecture), EJB (Enterprise Java Beans) or some other similar system may be used to exchange communications between coordinator 302c and event manager 304a.

Event manager 304a passes the call to the programming logic represented by middle tier server 304b, at which time an appropriate method is executed. Depending on the configuration of the programming logic, other objects may be invoked or called as a result of the first call. All of the end results, side effects, events, data changes, etc., (collectively termed the "results" for the present discussion) from the call are captured by the event manager. Event manager 304a records or stores the results for inclusion in a single, consolidated, communication to be sent back to the client so that it may apply them, update its cache, fire the same events, etc. Thus, after the event manager has gathered all of the results, it places them in a communication and transmits the communication to the client. Illustratively, the results are arranged so that they may be read, and applied, by the client in the order in which they occurred on the middle tier server.

When coordinator 302c receives the communication from the middle tier server, it plays back its component parts. In particular, data changes are used to update client cache 302d, while events are fired for or returned to user program 302a.

Further details of the various components of a data access framework employed in a three-tier environment are now described in the following sections. Client Cache

In a present embodiment of the invention a client system employs one or more caches, which may be rather small for thin clients, in order to improve performance while performing various data operations. A client cache may be compared to an object cache located on the middle tier server. Just as the middle tier server's object cache improves the efficiency of data operations on the middle tier, a client cache provides a similar benefit for the client computer. Thus, the contents of the client cache may be a subset of the contents of the middle tier server's cache. However, the object cache will typically be much larger than the client cache. For example, whereas a middle tier server's object cache may store thousands of data objects (e.g., database records or rows), the client cache of a client system connected to the middle tier server may store fewer than one hundred, depending on how many objects the application is designed to display for a user at one time, the size of the objects and the resources of the client. By limiting the size of a client cache, fewer resources are required to manage the cache. One aspect of a current embodiment of a data access framework is that the framework is suitable for use with thin clients without sacrificing performance.

Client systems manage the contents of the client cache in an attempt to populate it with data that is relevant to a user's data operations. Thus, a client system may inform a middle tier server of the size or capacity of its cache so that the middle tier server can provide a suitable amount of data to the client and thereby decrease the frequency with which the client requests additional data. Or, if a specific data operation requested by a user requires only a certain amount of data (e.g., the next N records or rows of a database), the client may structure its data request (e.g., to the middle tier server) appropriately. Intelligence may be applied by the client (or the middle tier server) in order to look ahead or guess which data objects should be pre-provided from the middle tier server in order to be prepared for a next data operation performed by the user. Any suitable caching scheme (e.g., least recently used) may be used to manage the client cache and replace existing cache entries with new data.

As one skilled in the art will appreciate, if a data operation requested by a user or user application can be satisfied from data stored on the client (e.g., in a client cache), the performance of the user application is enhanced. In this case the data operation is performed locally (i.e., on the client). However, just as events occurring on the middle tier are recreated or played back on the client, the data operation on the client and its effect(s) are forwarded to the middle tier server so that the operation may be applied there as well. Some simple operations performed first on the client may be collected before sending them to the middle tier server. Other, more complex, operations may be sent on to the middle tier immediately after execution on the client. Other data operations will not be immediately satisfied on the client (e.g., because the necessary data is not in a client cache or the operation is configured to go to the middle tier for execution). In this case the client forwards the operation to the middle tier, which performs it, captures its effects and returns them to the client. The client may then perform the operation, apply its effects and respond to the user or user application appropriately. The use of lightweight proxies helps keep a client cache up to date.

Client/Middle Tier Server Communications

As briefly described above, data and other information exchanged between a client and a middle tier server (in a three-tier environment) in a present embodiment of the invention are clustered or aggregated in order to increase communication (e.g., network) performance.

In previous multi-tier data access applications, inter-tier communication performance was often very inefficient. The granularity, or level of data and information, that was exchanged between tiers could be very low, particularly when object calls were attempted across tiers or one tier tried to inform another of an event occurring on the first tier. As a result, numerous communications were required in order to perform or propagate a single operation, such as updating or retrieving a database table.

Thus, developers of data access applications had to choose between good network/communication performance or good data uniformity across tiers. If, for example, a developer wished to ensure uniformity of data states between tiers, then inter-tier communications had to remain "chatty" in order to exchange the necessary amount of information. This causes a decrease in network performance and may delay data operations.

In contrast, in order to improve network performance, a developer could not maintain high uniformity among a client system and a data server. The manner in which communications are structured between a client and a middle tier server in present embodiments of the novel data access framework, however, allows very good uniformity between tiers without sacrificing network performance. In particular, instead of making a low-level data object (e.g., the value of a single field in one record of a database) the subject of one client/middle tier communication, inter- tier communications in this embodiment focus higher. In one implementation, for example, a database row (or multiple attributes within a row) may be the lowest level object transmitted in a communication. Further, and as described in the following sub-section, if one data update triggers another event to update or refresh other data (e.g., in a master/detail arrangement), all of the data changes and events may be reported in one communication. Interleaving or otherwise combining events, exceptions and data into single inter-tier communications greatly facilitates the ability to maintain uniformity of an application program across tiers.

Illustratively, the level of granularity of items in the client cache matches the granularity of objects contained in a client/middle tier communication. Thus, where individual rows of a database are passed between tiers, and each row corresponds to one order in an order processing application, for example, a client cache may be configured to store some number (e.g., twenty to fifty) of orders that a user has immediate access to at one time.

Thus, instead of requiring separate data requests for each field/attribute in a database record/row as in previous data access applications, now entire rows of the database may be retrieved in a much more efficient manner. Illustratively, when a first data request (e.g., for one or more data objects) is passed from a client system to the middle tier server, the middle tier server learns the size of the client's cache. This value may be included in the client's request or be provided to the middle tier server via a separate communication. The middle tier server then retrieves the requested data (e.g., from its cache or a database server) and enough additional data (e.g., the next N data objects after the requested objects) to fill the client cache. As described in more detail below, the requested data is packed into a communication (e.g., using Java serialization) and forwarded to the client. The client receives the communication, unpacks the contents, populates the client cache and returns to the application.

Alternatively, if the data application is configured to work with a particular number of rows, attributes or other data objects, the middle tier may retrieve and provide the client with just that number of objects that the application can use.

Communications from a client to a middle tier server are also improved by allowing multiple data updates to accumulate in the client before sending the entire collection (e.g., instead of sending each update individually). Updates may be forwarded at regular intervals or upon certain events. Illustratively, the updates are received by the middle tier and applied to its object cache in order to synchronize the data on the client and the middle tier server. By propagating events, exceptions and data across tiers in both directions, programming and data uniformity are promoted.

In one embodiment of the invention data operations submitted to a client (e.g., from a user, a user application, a form) are assigned a mode of execution. A first, or priority, mode may indicate that the operation is to be reported to the middle tier immediately. However, if an operation can be performed without the middle tier's involvement (e.g., with data already in a client cache), then even in priority mode it may not need to be reported to the middle tier. Any data changes, however, must be reported. Of course, if a requested operation requires the involvement of the middle tier server (e.g., a priority operation), and cannot be performed on the client (e.g., necessary data is unavailable) it is immediately passed to the middle tier server for execution. In a second, or delayed, mode of execution, operations may be accumulated on the client and forwarded to the middle tier server after a particular number of operations have been accumulated and/or a priority mode operation is submitted. Illustratively, in the delayed mode of execution an operation is performed locally (e.g., with data in a client cache), if possible, and then later forwarded to the middle tier server. In one alternative embodiment of the invention, the data access framework allows components and objects within the framework to register interest in events and other objects. Thus, the middle tier server may specify to the client that the middle tier server has an interest in a particular data operation (e.g., changes to employee salaries). In such a case the client may be configured to immediately forward such operations to the middle tier server, possibly disregarding any mode that may be otherwise assigned to the operation. The middle tier server may, for example, maintain some specialized or custom logic that is to be executed for certain operations. Advantageously, in this embodiment of the invention whichever tier has more complicated "side effects" to implement for an operation will receive and execute the operation first before communicating the operation and those effects to the other tier. MASTER/DETAIL COORDINATION

As one illustration of an efficient scheme for limiting communications between a client and a middle tier server in an embodiment of the invention, the manner in which a master/detail data arrangement is handled is now described. As one skilled in the art will appreciate, database and data access applications often employ master/detail arrangements in order to manipulate related data. For example, in an organization's employment or human resource database, a master/detail relation may be used to display information concerning departments (master) and employees within a department (detail). Or, more particularly, a master/detail relation allows selection of a master item (e.g., a department) so that detail items (e.g., employees within that department) may be viewed or accessed.

User interface objects (e.g., text boxes, grids) may be associated with each master or detail component. Illustratively, a text box may allow a user to enter a particular piece of master data, such as a department name or number. Upon receiving the specified master element, data may be retrieved concerning the employees within the specified department and displayed (e.g., in a table). Further, the user may select another user interface object (e.g., a "NEXT" or "- " icon or button) in order to select the next master item (e.g., department). The employee detail is then updated or refreshed, and so on.

With multiple tiers, such as the three-tier environment described above, coordination of master/detail arrangements may be performed in either the client or middle tier server. Due to the need for sufficient resources to store and process the necessary data, however, in one embodiment of the invention master/detail coordination is performed on the middle tier server so that thin clients (e.g., systems with limited resources) can operate within the environment. More specifically, in order to implement or manage master/detail arrangements in a client system, it may require additional resources, programming logic, data and so on.

Thus, in this embodiment a user interface object on the client may contain components (e.g., text box, grid) for selecting or displaying master/detail data. These components are hooked to the client cache and may be refreshed automatically as the cache is populated with requested data (e.g., the employees within a next department). However, the master/detail relation is actually managed by the middle tier. Thus, all master/detail operations are forwarded to the middle tier server for execution. The operation and its effects (e.g., a new set of employees for a newly selected department) are then returned to and implemented on the client. Specifically, when a user identifies a particular department or requests a next department, the client calls or sends a communication to the middle tier server. The middle tier server locates the requested department data. An event manager operating on the middle tier (and described in the following section) recognizes that a new set of employees is needed (because of the master/detail arrangement) and ensures that the necessary number of employee records or rows are returned when the middle tier server responds to the client's call. The number of employee records sent to the client may depend on the range size of a client cache, the number of records that can be displayed in the user interface object on the client, the number of records the data access application is configured to manipulate at one time, etc.

FIG. 2 demonstrates a (single) round-trip communication that may be used to update the master/detail data on a client system. One skilled in the art will appreciate that previous data access applications typically required many additional communications in order to perform the same operation. In FIG. 2, communication 202 from client 102b to middle tier server 104 identifies a data operation requested by a user. In this case the user has requested information for the "next" department. In particular, the client may maintain a list of departments, perhaps identified by name and/or number, and possibly with some other information (e.g., number of employees in the department). Middle tier server 104 receives the requested operation. The master (e.g., department) object on the middle tier is set to the specified department, which automatically causes the employee data for the department to be retrieved (e.g., from the middle tier cache or from a database server) and updated on the middle tier server.

The employee data must then be sent back to client 102b so that it may update its employee grid. In the illustrated embodiment of the invention the detail (e.g., employee) object on the middle tier server fires an event that is trapped or handled by an event manager (described further in the following section). The event manager recognizes that the employee object on the middle tier server is reporting a new set of employees in a master/detail relation that the client must be informed of. The event manager thus assembles the employee data for the new department with other information needed to replicate the master/detail update on the client. The amount of employee data sent to the client may be determined by the amount of data (e.g., number of records) that will fit into the client's cache. In this example, the communication sent back to client 102b from middle tier server 104 consists of several items. Illustratively, the format of the communication reflects the order in which data was updated or changed, and in which related events occurred, on the middle tier server. Therefore, communication 204 includes a first part 204a concerning data for the selected, or "next," department (e.g., department number, department name, number of employees). The next department may or may not already be in the client cache. If it is (as is the case in the illustrated embodiment), the middle tier is aware of this fact and, in part 204a simply directs the client to go to the next department (e.g., department 20, named Engineering, having ten employees). The department record is the first part of communication 204 in this example because it is the first item that was changed or affected on the middle tier server.

However, if the next department is not in the client cache then part 204a will include the necessary department data. The department data may be preceded in part 204a by a command from the middle tier server for the client to make room in the cache for the new department. The command may be something like "scroll begin." Following the scroll begin command would be the department data (e.g., "20, Engineering, 10 employees") that is placed in the client cache. Trailing the department data is a complementary command to "scroll begin," such as "scroll end," which tells the client to fire the department event and update the client cache. Second portion 204b of communication 204 comprises a command or directive from the middle tier server to the client to make room in its cache for the requested data (e.g., employee records). Second portion 204b may specify how much room should be made (e.g., by clearing, erasing or moving entries) in the cache. The command used in the illustrated embodiment is "refresh begin." A third portion 204c of communication 204 includes individual employee records

(e.g., consisting of employee number and employee name) that are used to populate or update the employee object on client 102b. Finally, a fourth portion of the communication 204d informs the client that it may complete its refreshing operation. Fourth portion 204d may thus comprise a command such as "refresh end" which, when received by the client, causes the client to fire the refresh event.

Application of the return communication in the illustrated master/detail update, and its effect on user interface controls associated with the master/detail data, may be summarized as follows. Client 102b receives communication 204 from middle tier server 104. The client populates a client cache with the specified department and employee data and fires their events as they are encountered in the communication. The user interface control for the department data (e.g., a text box) receives a "navigate to the next department" or "scroll begin" command, depending on whether the department data is already on the client. The text box is cleared and department 20 is displayed. Then, when the "refresh end" command of portion 204d is encountered, the user interface control (e.g., a grid) for the employee data is cleared and filled with the employee data of portion 204c of communication 204.

Thus, it can be seen that communications passing between a client and a middle tier server may include data changes/updates, new data, events and other information useful in ensuring that a data access application has the same behavior or effects on both the client and the middle tier server. Illustratively, in a present embodiment of the invention one communication relates to one user action, which may, however, involve many system-level events. The events are gathered, clustered, or aggregated in the correct sequence so that when a communication is received it can be "played back" to recreate the event(s).

Because of the manner in which data operations and events occurring in one tier (e.g., a middle tier) are communicated to and applied within another tier (e.g., a client), application developers may easily customize or otherwise alter a data access application developed according to a present embodiment of the invention. For example, consider the master/detail scenario described above in which one user interface object (e.g., a text box) is associated with a department data object and another user interface object (e.g., a grid) is associated with employee data corresponding to a specified department object. One manner was detailed in which an embodiment of the invention may ensure that master and detail data is synchronized between tiers. A programmer or developer may wish to alter this master/detail arrangement to add custom business logic. For example, it may be desired to display project data associated with the selected department and/or employees. The programmer may wish to meet users' requests that active projects within the department be identified every time a new department is selected and the employees for that department are displayed. Thus, the programmer may add another user interface control or object to a user's form.

In one embodiment of the invention, custom business logic may be accommodated by hooking it into the middle tier server. In particular, the programmer may override the department navigation (e.g., to a next department) event described in conjunction with FIG. 2. In this case, when the navigation event is conducted on the middle tier server, the business logic kicks in to display or update the project data. The return communication to the client (e.g., communication 204 of FIG. 2) is modified accordingly to capture the project data and refresh event. Where customized logic is executed on the middle tier server, a communication similar to communication 204 of FIG. 2 is returned to the user's client in order to ensure that the same data is presented to the user. Thus, communication 204 illustratively receives three additional sections added in the following order after section 204d. First, a "refresh begin" or similar command is expressed to clear or make room in the client cache for the project data. Second, the actual project data is added. Finally, a "refresh end" or similar command is added to end the project refresh event. As with the department and employee data, a user interface control (e.g., a grid) for the project data is cleared and then updated when the project refresh event fires.

Because the communications that a client and middle tier server exchange typically deal with one user event at a time in one embodiment of the invention, the size or range of a client cache need only be large enough to fill a user interface object. Thus, in the examples above, the client cache(s) need only be large enough to store the number of departments, employees and projects that can be displayed on one user form. This minimizes the amount of data that must be exchanged between a client and a middle tier and, because of the manner in which information is clustered or aggregated, reduces the network traffic passing between them.

Event Manager

As described above, an event manager operates on a middle tier server to ensure that a data operation or other event that occurs on the middle tier server is captured and reported to a client in order to recreate the operation/event. In particular, the event manager captures events as they occur on the middle tier server, arranges or stores entries in communications to a client so that events can be played back on the client, and forwards the communication at the end of the initiating user event or call. The event manager thus ensures that data modifications first made on the middle tier server are made known to a client.

In one embodiment of the invention an event manager is only needed on a middle tier server operating in a three-tier environment. In a two-tier mode of operation an application program may interact directly (e.g., on the same computer) with middle tier objects to make calls and receive events and data.

In addition to informing a client of data operations executed on the middle tier, such as described in conjunction with FIG. 2 above, the middle tier event manager is also responsible for marshalling exceptions between these tiers. In particular, when an attempted data operation or other event on the middle tier generates an exception, that exception must be reported to the client.

To illustrate how the event manager may communicate an exception from one tier to another in a present embodiment of the invention, consider a data operation in which a user changes the value of a data field (e.g., department name) from X to Y. This may equate to a command such as "set attribute name from X to Y." As one skilled in the art will appreciate, it is desirable to lock the database record containing this field to promote data integrity.

However, a lock conflict may be encountered if, for example, another user may be updating the same record but has not yet committed the transaction. Therefore, an exception is thrown on the system (e.g., middle tier server) that is attempting to lock the record. When a lock conflict is encountered on the middle tier, it must be reported to or applied on the client as well.

Table 1 illustrates how a try/catch block of programming code may be implemented in an object-oriented programming language to carry out the attempted operation to change the name of a department to a name input by a user. while (true)

{

String newName = readline(); try { dept.setAttribute ("Name", newName); break;

} catch (AlreadyLockedException ex); { writeline("Department locked by another user. Try again.");

} }

TABLE 1 This code, or its equivalent, would adequately serve its purpose when executing on a middle tier server in a two-tier or other environment in which no other system (i.e., in another tier) had to be informed of the progress of the operation. In particular, the illustrated code would attempt to lock the specified record; if successful, it would break out of the loop and continue with normal operations. If, however, the record could not be locked, the routine tries again.

In a three-tier environment such as that of FIG. 1, if an exception is thrown on the middle tier it is captured by the event manager and communicated to the client in a return communication such as communication 204 of FIG. 2. When this communication is received and applied at the client, the client throws the same exception.

Lightweight Proxies It should be noted that all or many of the various application development objects that are provided in a present data access framework can be sub-classed. Further, in one embodiment of the invention various programming objects may be available across tiers. In a two-tier mode of operation this may not be necessary, as the client is co-located (e.g., on one computer system) with the programming logic and objects of the middle tier server. However, in one embodiment of a three-tier mode of operation access to middle tier objects is made available through "lightweight" proxies installed on a client. In this embodiment programming logic needed by multiple clients is built on objects installed on the middle tier server. The programming logic is thus uniform among all clients.

Using the example described above in conjunction with FIG. 2, department and employee classes may be resident on the middle tier. They may therefore be considered middle tier objects. A user program developed to use these objects may be installed on a client. In this embodiment of the invention interfaces for the department and employee objects are generated and installed on the client as part of the data accessing framework. The user program may be developed using these interfaces, without concern for how the actual department and employee objects on the middle tier are accessed.

Lightweight proxies for the middle tier objects are also placed on the client. When the user program is run in three-tier mode, the department and employee interfaces, if called, invoke the lightweight proxies. If the user program was run in two-tier mode, since the middle tier objects are co-located with the user program the department and employee objects may be called directly.

In the three-tier mode of operation, however, the task of the lightweight proxies for the department and employee middle tier objects is to route the object calls to the middle tier, where the corresponding methods are called. Data changes, exception and events concerning the object calls are collected on the middle tier and returned in a consolidated communication such as communication 204 of FIG. 2.

The department and employee interfaces and the lightweight proxies, in one embodiment of the invention, are automatically generated by the design-time component of Oracle Corporation's Business Component for Java when the department and employee classes are created for the middle tier.

To extend this example, a GiveRaise method associated with the employee class may be implemented on the middle tier server. A tier-independent interface (e.g., Emp) is generated having a method specification for the GiveRaise method. A lightweight proxy (e.g., Emp_proxy) is also generated for three-tier implementation of Emp. A user then develops an application to use the employee class, in particular, the GiveRaise method. The user incorporates the Emp interface into his program to call the method.

When the user program is executed in a two-tier environment, it calls GiveRaise directly (because they are co-located). When the user program runs in a three-tier environment, Emp.GiveRaise calls Emp_proxy.GiveRaise. Emp_proxy then sends the request/invocation to the middle tier (e.g., the middle tier event manager), where the GiveRaise method is invoked. Any side effects and other events associated with the invocation on the middle tier are captured by the event manager and returned to the client in a consolidated communication. Emp_proxy receives the communication and plays it back to recreate the events, changes and side effects of the GiveRaise method invocation.

One Method of Applying the Data Access Framework

FIGs. 3A-B illustrate one method of employing a data access framework in a multi- tier computing environment (such as that depicted in FIG. 1) according to one embodiment of the invention. In particular, the illustrated procedure allows a user's data operation to be performed even while maintaining high programming model uniformity and a high level of communication efficiency between tiers.

State 300 is a starting state in which necessary data access tools are installed or configured. In particular, client and middle tier systems in the computing environment are configured to operate a run-time module of Oracle Corporation's Business Component for Java (or other object-oriented programming language). The APIs provided by this module facilitate and enable various aspects of the present invention described in the preceding sections (e.g., efficient communications, lightweight proxies). Also, a user application is configured on the client system. In this example, the application is designed and developed using the design-time component of Oracle Corporation's Business Component for Java plus either JDeveloper or another suitable development tool.

In state 302, a data operation (e.g., a data alteration, a request for data for a form) is received at the client system from the user application. The data operation may, for example, be generated automatically by a form on which a user has selected or altered a piece of data, such as a master data item in a master/detail form.

In state 304 it is determined whether the data operation is middle tier sensitive. In particular, it is determined whether the operation should be immediately forwarded to the middle tier server for execution. In one embodiment of the invention the middle tier may register an interest in particular events or operations (e.g., such as when a user navigates to a next master row). The middle tier server may also register interest in events, operations and/or data objects when, for example, custom or object-specific code is installed on the middle tier for execution upon occurrence of the specified event or operation involving a particular data object. Events and operations that are middle tier sensitive are forwarded directly to the middle tier server for execution. As described below, other pending events/operations may be sent at the same time.

In a present embodiment of the invention the client only applies the results of a middle tier sensitive operation from information returned from the middle tier server (i.e., after the operation) rather than performing the operation locally and then forwarding the operation and/or its effects/results to the middle tier server afterwards. If the operation is middle tier sensitive, the illustrated procedure advances to state 316 to immediately forward the operation. Otherwise, if the operation is not middle tier sensitive, the procedure continues at state 306. In state 306 it is determined whether the operation normally requires middle tier involvement. For example, if the operation is merely a request for retrieval of data (e.g., a getAttribute call) and does not change a data value (e.g., a setAttribute call), the middle tier need not be involved if the data is available locally (e.g., in a client cache).

If the operation requires middle tier action, the illustrated procedure advances to state 312. Otherwise, the procedure continues at state 308.

In state 308 the client determines whether the data needed for the operation is available locally (e.g., in a client cache). If not, then the operation must be forwarded to the middle tier for satisfaction (e.g., to retrieve the necessary data). In this event the procedure continues at state 316.

However, if the necessary data is already available on the client, in state 310 the operation is performed locally, without middle tier involvement. The illustrated procedure then advances to state 342 to return or display the operation results to the user, after which the procedure ends.

In state 312 it has been determined that the requested data operation requires middle tier involvement, but not immediate involvement. For example, the user may have added or changed a new attribute, row or other data value that must be communicated to the middle tier at some time, but not immediately. The operation is therefore deferrable. Thus, in state 312 the client attempts to satisfy the operation with data available on the client. Whether or not this can be done, the operation is then appended to a collection of other operations (if any) waiting to be forwarded to the middle tier server. As described previously, communication efficiency is improved by accumulating multiple operations on the client (e.g., which are not middle tier sensitive) before forwarding them all at once.

In state 314 the client waits until a predetermined criterion is satisfied before forwarding the presently discussed data operation and any other waiting operations/events. In different embodiments of the invention, the client may await a particular event or operation or a particular type of event or operation (e.g., a middle tier sensitive operation). In one embodiment the client may wait until a predetermined number of operations or events are waiting. In another embodiment the client may wait until an operation message used to convey the waiting operations to the middle tier reaches a predetermined size. Until it is time to send the waiting operation(s) to the middle tier, additional operations and/or event may be appended. Operation messages (i.e., messages to the middle tier containing one or more operations or events) may be sent from a client to the middle tier server at periodic intervals, when a particular type of operation is requested that, although not middle tier sensitive should nevertheless not be delayed too long, or when some other criteria is satisfied.

In state 316 one or more criteria for sending an operation to the middle tier server are satisfied. For example, a middle tier sensitive operation may be received, which requires immediate transfer to the middle tier. Or, a threshold for determining when one or more waiting operations should be forwarded may be satisfied. Therefore, all waiting operations (and/or the new middle tier sensitive operation) are placed in an operation message and transmitted to the middle tier server.

In state 318 the middle tier server receives the operations message and unpacks the contents. In state 320 the middle tier server retrieves an operation from the operations message and, in state 322, executes that operation. As a consequence of the operation, various data items may be added, changed, retrieved or otherwise manipulated. In addition, side effects such as the execution of custom code (e.g., business logic) may execute. Illustratively, the operations are retrieved and executed in the order they were requested and/or executed on the client. Thus, some of the operations may have been performed first on the client, others will be executed for the first time on the middle tier server.

In state 324 an event manager residing on the middle tier server captures and notes the side effects and events resulting from execution of the operation. Thus, the event manager saves or copies the affected data and any effects of events that were triggered by the operation. Illustratively, the event manager captures all of the results of the operation whether or not the operation was already performed on the client, which will be returned to the client to ensure uniformity. However, in an alternative embodiment the middle tier server need not capture all results for such operations.

In state 326 the middle tier server (e.g., the event manager) determines whether any other operations remain in the operations message. If so, the illustrated procedure returns to state 320. Otherwise, if all operations have been retrieved and applied, the procedure continues at state 328.

In state 328 a return communication is generated sent to the client. The return communication includes the data changes and other events and results of each operation. Illustratively, the return communication is formatted similar to communication 204 of FIG.

2, such that the client may receive the communication and play back the side effects, data changes and any other events or results of the operations.

In state 330 the client receives the return communication and begins parsing it in order to play back the operations. In state 332 a first entry is retrieved from the return communication. In state 334, if the entry is a data change the illustrated procedure continues to state 336. If the entry is an event, then the procedure advances to state 338. In state 336 the data retrieved from the return communication is used to update a client cache, after which the procedure advances to state 340. In state 338 the retrieved event is applied or fired.

In state 340 it is determined whether another entry is in the return communication. If so, the illustrated procedure returns to state 332; otherwise the procedure continues to state 342. In one embodiment of the invention all entries in the return communication are played back on the client, even if they correspond to operations that were already performed on the client (e.g., in state 308). This helps ensure programming and data uniformity between tiers. Alternatively, however, intelligence may be applied to avoid duplication of effort and only apply on the client those data changes that were not already applied.

In state 342 the results or effects of the data operation requested in state 302 are displayed or returned. For example, where the data operation concerned an updated master data element, the corresponding master/detail data may be displayed. The illustrated procedure then ends at end state 350. One skilled in the art will appreciate that the method depicted in FIGs. 3A-B is but one method of employing the data access framework of a present embodiment of the invention. Various other methods may be derived without exceeding the scope of the invention.

The foregoing descriptions of embodiments of the invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the invention to the forms disclosed. Many modifications and variations will be apparent to practitioners skilled in the art. Accordingly, the above disclosure is not intended to limit the invention; the scope of the invention is defined by the appended claims.

Claims

What Is Claimed Is;

1. A system for operating a multi-tier data access application while maintaining a high degree of uniformity between two tiers in a multi-tier computing environment, comprising: a client operating in a first tier of a multi-tier computing environment, comprising: a client cache configured to store a set of data objects; and a lightweight proxy for a programming object, wherein said programming object resides in a second tier of said multi-tier computing environment; and a server operating in said second tier of said multi-tier computing environment, said server comprising: an event manager configured to monitor a first event on said server and capture results of said first event, said results including a first data object; and a communication module configured to transmit said first event, including said results of said first event, to said client in a single communication; wherein said client is configured to receive a data operation from a user and transmit said data operation to said server, wherein said data operation yields said first event; and wherein said client receives said single communication and applies said results of said first event on said client.

2. The system of claim 1, wherein said server further comprises a server cache, wherein said server cache is configured to store a superset of said set of data objects.

3. The system of claim 1, wherein said server is configured to access a database on a data server operating in a third tier of said multi-tier computing environment when said data operation is received at said server.

4. The system of claim 1, wherein said single communication further comprises a second event.

5. The system of claim 1, wherein said client stores said data object in said client cache after receiving said single communication.

6. A method of uniformly applying a data operation on different tiers of a multi- tier computing environment, comprising: receiving a first data operation on a client computer system in a first tier of a multi- tier computing environment; communicating said first data operation from said client computer system to a server in a second tier of said multi-tier computing environment; performing said first data operation on said server to produce a set of effects, wherein said set of effects includes one or more data objects; transmitting said set of effects in a return communication to said client; parsing said return communication to retrieve said one or more data objects; and applying said first data operation on said client.

7. The method of claim 6, wherein said client is a computing device operated by a user and said server is a server computer system through which the user may access a collection of data objects stored on a data server in a third tier of said multi-tier computing environment.

8. The method of claim 6, wherein said client and said server are co-located on a single computing device.

9. The method of claim 6, wherein said communicating comprises communicating a set of data operations to said server, said set of data operations including said first data operation.

10. The method of claim 6, wherein said parsing comprises storing said one or more data objects in a client cache.

11. The method of claim 6, wherein said set of effects includes a first event performed in response to said performing said first data operation on said server.

12. The method of claim 11, wherein said applying comprises firing said first event on said client.

13. The method of claim 6, wherein said applying comprises: recreating said first data operation on said client in order to maintain uniformity between said first computer system and said second computer system; and implementing one or more of said set of effects on said client.

14. The method of claim 6, wherein said set of effects further includes execution of a series of programming instructions associated with one of said one or more data objects.

15. A method of promoting programming uniformity between tiers in a multi-tier data access computing environment, comprising: receiving a data request at a client operating in a first tier of a multi-tier computing environment, said data request requiring a first data object; transmitting said data request to said server; executing said data request on said server, wherein said execution has one or more effects including manipulation of said first data object and a first event associated with said first data object; generating a return communication to said client, said return communication comprising said effects; storing said first data object in a client cache; and implementing said effects on said client to recreate said data request execution and promote programming uniformity between said client and said server.

16. The method of claim 15, wherein said implementing said effects comprises firing said first event on said client.

17. The method of claim 15, further comprising determining whether said data request is a priority request requiring immediate transfer to said server.

18. The method of claim 15, wherein said transmitting comprises transmitting said data request with one or more other requests in a single message to said server.

19. The method of claim 15, further comprising performing said data request on said client prior to said transmitting.

20. The method of claim 19, wherein said transmitting comprises forwarding to said server effects of said data request performed on said client.

21. A multi-tier computing environment, comprising: a client computing device operated by a user to receive a first user data operation, said client computing device comprising: a client cache configured to store a first set of data objects, wherein said first set of data objects is received at said client computing device from another computing device on which said first data operation is first performed; and a lightweight proxy for a programming object residing on said other computing device, wherein said lightweight proxy is configured to call said programming object in response to said first data operation; and a server configured to receive said first data operation from said client computing device, said server comprising: a server cache configured to store a superset of said set of data objects stored in said client cache; a processor configured to perform said first data operation; and an event manager configured to assemble results of performing said first data operation, wherein said results include one or more data objects and a first event associated with said one or more data objects; wherein said server transmits a first communication to said client computing device in response to performing said first data operation, said first communication comprising said first data operation and said results.

22. The multi-tier computing environment of claim 21, wherein in response to said first communication, said client computing device performs said first event and updates said client cache with said one or more data objects.

23. The multi-tier computing environment of claim 21 , wherein said client computing device performs a second data operation to manipulate a subset of said set of data objects stored in said client cache; and wherein said client computing device transmits a second communication to said server, said second communication comprising said second data operation and said subset of data objects.

24. The multi-tier computing environment of claim 23, wherein said server retrieves said second data operation and said subset of data objects from said second communication and recreates said second data operation on said server.

25. The multi-tier computing environment of claim 21 , wherein said first communication includes an exception generated on said server during execution of said programming object; and wherein said exception is thrown on said client computer system after receipt of said first communication.

26. A computer readable storage medium storing instructions that, when executed by a computer, cause the computer to perform a method of promoting programming uniformity between tiers in a multi-tier data access computing environment, the method comprising: receiving a data request at a client operating in a first tier of a multi-tier computing environment, said data request requiring a first data object; transmitting said data request to said server; executing said data request on said server, wherein said execution has one or more effects including manipulation of said first data object and a first event associated with said first data object; generating a return communication to said client, said return communication comprising said effects; storing said first data object in a client cache; and implementing said effects on said client to recreate said data request execution and promote programming uniformity between said client and said server.

27. A computer readable storage medium containing a data structure configured for communicating a first data operation and a result of the first data operation from a first computing device on which the first data operation was performed to a second computing device in a multi-tier computing environment, the data structure comprising: a first set of data objects accessed on the first computing device during the first data operation; a first event associated with said first set of data objects; wherein said data structure is communicated from the first computing device to the second computing device on which the first data operation is to be recreated by updating a memory on the second computing device with said first set of data objects and performing said first event on the second computing device.

28. The computer readable storage medium of claim 27, wherein said data structure further comprises: a second set of data objects accessed on the first computing device; and a second event associated with said second set of data objects.