Note: Descriptions are shown in the official language in which they were submitted.
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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
clientlserver) 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
2
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 andlor 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,
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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. lA-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.
4
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 clientlserver 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
6
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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
I S 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
7
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 andlor 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
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 andlor 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 mufti-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
9
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 mufti-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 mufti-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 mufti-tier systems that addressed only
the issue of
"what" (i.e., data) changed. In a present embodiment of the invention a mufti-
tier system is
provided to coordinate, between tiers, "how" that data changed.
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
FIG. 1B 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
Z04b. 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 l Ob) 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. 1B, 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. 1 C 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. 1A
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. 1 C is essentially the same as user
program 204a of the
two-tier environment of FIG. 1B. 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 specif cations but not implementations. The user program therefore does
not have
11
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 andlor 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.
12
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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
effects) are forwarded to
13
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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.
14
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 cliendmiddle 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
recordlrow 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.,
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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.
16
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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.
1?
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 andfor 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.
18
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 l OZb receives communication 204 from middle
tier server
19
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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.
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 caches) 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
21
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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
22
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 cailed. Data changes, exception and events
concerning
23
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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
24
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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 operations) to the middle tier, additional operations
andlor 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
26
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
(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 andlor
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.
27
CA 02401547 2002-08-28
WO 01/67244 PCT/USO1/05399
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
far
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.
28
