 |
Description  |
|
|
FIELD OF THE INVENTION
This invention relates to client/server computational architectures, and in
particular to methods and apparatus for facilitating optimized, shared
retrieval and storage responsibilities in an interactive, multi-user
distributed environment.
BACKGROUND OF THE INVENTION
Online computer services are large regional or national networks accessible
to consumers by subscription, Providers offer their subscribers a wide
range of services, including on-demand access to electronically
represented newspapers, software and documents that can be "downloaded" at
the user's request; discussion groups in which subscribers can take part
by computer; electronic mail among subscribers and non-subscribers; and
various forms of entertainment, Generally, consumers connect to a service
via telephone, and the service charges its subscribers a recurring fee for
its basic service package and a variable fee for the time they are
actually connected.
Online services have experienced an enormous increase in their customer
bases in the last few years, owing both to the proliferation and growing
sophistication of personal computers as well as to the expansion of
available services. The need to provide a large, widely dispersed user
group with on-demand access to the central online service requires
substantial computational capability. The service must not only control
and monitor user access, but must also maintain a large, constantly
growing reservoir of information to which many users must have
simultaneous access.
One widely accepted computer architecture, developed specifically to
accommodate the "distributed computing" environments that characterize
online services, is the client-server model. In its purest form, a
client-server system consists of a central server (sometimes called the
host), which is a very powerful computer (or cluster of computers that
behaves as a single computer) that services the requests of a large number
of smaller computers, or clients, that connect to it. The client computers
never communicate with one another, instead exchanging data only with the
server, which thereby acts a clearinghouse for client requests and
inter-client communications. A server, therefore, may be a large mainframe
or minicomputer cluster, while the clients may be simple personal
computers.
Although they need not be powerful, it is nonetheless important that
clients possess a basic level of on-board processing capability; unlike
older timeshare systems, which utilized "dumb" terminals that were
essentially driven by the central machine, the client-server model
requires that each client be capable of independent computational
operation. In this way, the central server need only accept and deliver
messages to the clients, which process them for output to the user. This
approach limits the processing burden on the server and facilitates
faster, readily customized responses by the clients.
An exemplary client-server configuration is illustrated in FIG. 1. A
central server 10 communicates with a series of client computers 12.sub.1,
12.sub.2, 12.sub.3, 12.sub.4. . . 12.sub.n over a coextensive series of
physical connections 14.sub.1, 14.sub.2, 14.sub.3, 14.sub.4, . . .
14.sub.n. The terms "server" and "host" are herein used interchangeably to
denote a central facility consisting of a single computer or group of
computers that behave as a single unit with respect to the clients. In
order to ensure proper routing of messages between the server and the
intended client, the messages are first broken up into data packets, each
of which receives a destination address according to a consistent
protocol, and which are reassembled upon receipt by the target computer. A
commonly accepted set of protocols for this purpose are the Internet
Protocol, or IP, which dictates routing information; and the Transmission
Control Protocol, or TCP, according to which messages are actually broken
up into IP packets for transmission for subsequent collection and
reassembly. TCP/IP connections are quite commonly employed to move data
across telephone lines, and have been adopted not only by online services
but throughout the worldwide, integrated network communication web known
as the Internet.
The Internet contains vast stores of technical and academic information,
but much of this is formatted as undifferentiated text, and requires
mastery of a difficult command vocabulary to access effectively. The
information provided by online services, in contrast, is readily
accessible without special training, tailored in content to the interests
of subscribers, and presented in a visually appealing fashion. Online
services typically offer their subscribers access to the Internet as well,
once again in a format designed to promote easier identification and
retrieval of information.
The server executes a variety of applications in response to requests
issued by clients. Most of these requests, however, are for retrieval of
information stored on one of the server's databases. The application
programs executed by the server, therefore, by and large relate to data
management and transfer. In this sense, the term "application" denotes a
body of functionality for obtaining, processing and/or presenting data to
a user. For example, electronic mail (e-mail) facilities allow the user to
send and receive memo-type communications; document browsers display
hierarchically organized collections of document titles, any of which can
be obtained by a user simply by "clicking" on a title with a
position-sensing mouse device or otherwise designating the document.
Applications can be "active," operating only when affirmatively engaged by
a user, or maintain a "background" task mode, which operates even when the
application is not active.
Because the bulk of interaction between the server and clients relates to
data identification and retrieval, the large stores of data moving from
the server to the clients can impose substantial transfer costs and result
in unnecessary redundant storage. If a retrieved item of data is not only
downloaded to a client but also stored permanently on that client, it will
remain accessible to the client user after the user's communication
session with the server is over (and without instituting a new
connection). However, if the client user is unlikely to require convenient
access to the item, its local storage represents a waste of resources. On
the other hand, if requested items are never cached on clients, the need
for repetitive retrievals from the server likewise represent a resource
waste.
Transmission of unnecessary data likewise imposes needless costs. The
communication circuit between a client and the server is often expensive
to maintain, and in any case occupies one of a finite number of channels
that the server can support at any one time. Thus, unnecessary
communication imposes direct costs (in terms of telecommunication expense)
and indirect costs (because the channel capacity of the server must be
greater than what is truly necessary).
SUMMARY OF THE INVENTION
The present invention utilizes an object-oriented approach to storage and
transmission of retrievable items, in conjunction with special processing
modules that manage permanent storage of retrieved items on client
computers, to minimize transmission of unnecessary item components to the
clients and to optimize their storage burdens. In the context of the
present invention, transferable data is represented as information units
referred to as "items." An item is an atomic "object" unit, the smallest
independent unit of information. In an object-oriented system, each object
is associated with a unique identifier, and may or may not be represented
by contiguously stored electronic data. Indeed, an item need not even
reside on a single database; the server's database management software
assembles an item (e.g., an article containing related text and image
data) from its constituent components and transfers the item so that the
user receives it as a single unit. (Because, in the context of the present
invention, the communication protocol is preferably based on TCP/IP, the
item may actually travel from the server as several separate messages that
are integrated by the client's communication module.)
Each item object represents a header containing information about the item;
a set of data (most typically, displayable data that will ultimately
appear on client screens when the object is downloaded); and a set of one
or more associated procedures (including procedures that cause display of
the displayable data on the client machines). This "encapsulation" of
procedures within the objects themselves reduces the programming burden on
applications designed to interact with objects; those applications need
not "know" the details of object management and display, since each object
carries its own structure and effectively orchestrates its own behavior.
Objects also possess the property of heritability, whereby properties or
attributes of hierarchically superior objects are automatically inherited
by hierarchically inferior objects. Heritability is managed by organizing
the objects into classes, each of which represents the template for a set
of similar (in the sense of sharing structure and behavior) objects. Each
object is an instance of some class. Thus, objects in a subclass
automatically acquire the procedures associated with hierarchically
superior objects.
Hierarchical relationships among objects are not limited to inheritance and
class. In addition, objects can be related to one another based on a
hierarchical ranking, with higher-tier "parent" objects having pointers to
lower-tier "children" objects. As a result, higher-tier objects behave as
if they "contain" hierarchically related, lower-tier objects. Thus, in the
context of the present invention, a "folder" item stored on the server may
contain a list of titles of items within the folder, and a procedure for
displaying the list on clients. Each of the listed items represent
"children" of the folder. For example, a folder might list a series of
downloadable newspaper articles; the articles themselves are the folder's
children, and each contains the body, pictures and sidebars of an
individual, displayable article.
Objects can also be linked to one another. A linked object, while not
contained in the linking object in the manner of a lower-tier object, is
nonetheless referenced in the linking object. The procedures associated
with the linking object determine the significance of the reference and
its effect. For example, in the context of the present invention, a
linking item may contain a procedure for causing a client to request
linked items from the server upon selection of the linking item by a user.
Management of object classes, attributes, encapsulated procedures and
inter-object linkages occurs through an object-oriented database ("OODB")
system, design and implementation of which are well-known in the art.
Representation of retrievable items as objects minimizes the need for
specialized software on the client, since the items contain their own
display instructions. However, the cost of this flexibility is greater
transmission overhead, since objects contain more than just the
displayable data. For the same reason, objects also occupy substantial
memory space on the client. The present invention, therefore, utilizes an
interactive structure that provides clients with only enough information
about items to allow the client user to request them and the server to
process the request.
In particular, the invention recognizes that the OODB is only
intermittently connected to the client, and can provide instantaneous
access to server-stored items only when so connected, but that not all
items of possible interest to the client user warrant local storage.
Furthermore, the invention allows client users to specify the degree of
item content that is actually transmitted; for example, unless the user is
certain that he will view the entire contents of a hierarchical tier of
items, he can be provided only with the titles of such items, leaving him
free to select individual ones of these for retrieval and transmission as
desired. By imposing downloading costs on each item (which can vary,
depending on the value of the information), the user is discouraged from
needlessly downloading and storing unnecessary material.
In practice of the invention, the user enters a "subscription" in
connection with items related to (or likely in the future to be related
to) hierarchically inferior items. The subscription specifies the amount
of information the user desires to download and store locally with respect
to a specified hierarchical depth level. For example, the user may desire
the entire contents of higher-tier items, but remain willing to accept
only the titles of lower-tier items since their full contents can be
retrieved from the server upon specific request.
During the course of an online session, the user may retrieve numerous
items each of which is downloaded and stored locally. Accordingly, the
client "object store" on device 19 may contain many more items, at the end
of a session, than are consistent with the subscription restrictions. The
invention therefore allows the user to "tag" items he wishes to retain on
the object store and, at the conclusion of a session, deletes from the
object store untagged items to the extent inconsistent with the
subscription restrictions.
The invention also comprises means for updating items previously stored
locally upon re-establishment of communication with the server. The client
maintains, as part of its object store, a list of the dates and times each
stored item was last retrieved. The server maintains a list of the dates
and times each item was last modified. To update the client item store,
the client sends the server a list of stored items it wishes to update,
along with the dates and times they were last retrieved; the server
responds by furnishing the client with new versions of items that have
been modified since these dates and times, and a list of items that have
not been modified (i.e., for which the client already has the current
versions).
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing discussion will be understood more readily from the following
detailed description of the invention, when taken in conjunction with the
accompanying drawings, in which:
FIG. 1 schematically illustrates a simplified client-server arrangement;
FIG. 2 schematically illustrates the components and operation of a computer
system serving either as host or client;
FIG. 3 schematically illustrates the server-based components of the present
invention; and
FIG. 4 schematically illustrates the client-based components of the present
invention.
DESCRIPTION OF THE PREFERRED EMBODIMENT
1. System Organization
Refer first to FIG. 2, which illustrates generic computer circuitry
representative both of clients and servers. The depicted computer system
includes a central-processing unit 15, which performs operations on and
interacts with a main system memory 17 and components thereof. System
memory 17 typically includes volatile or random-access memory (RAM) for
temporary storage of information, buffers, and portions of the computer's
basic operating system. The system also includes at least one mass storage
device 19, such as a hard disk and/or CD-ROM drive. All components of the
system communicate over a bidirectional system bus 21.
While clients and servers bear similar hardware configurations at this
level of generality, their relative processing and data-storage
capabilities are naturally quite different. A client may be, for example,
a personal computer running the Windows graphical user interface supplied
by Microsoft Corp., while the server is ordinarily some type of mainframe
or minicomputer cluster running several multi-platter hard drives and/or
optical storage components as mass storage device 19.
System memory 17 contains, during operation, a series of applications 25
appropriate to the role the computer 10 is to play in the client-server
system, a communication module 27 (preferably implementing TCP/IP) capable
of transferring data among machines, and an operating system or graphical
user interface 29. Communication module 27 drives a modem 31 or other
data-transmission circuitry to transfer streams of digitally encoded data
over telephone or other communication lines.
The user interacts with the system using at least one input device,
preferably a keyboard 34 and a position-sensing device (e.g., a mouse).
The signal produced by either such device can be employed to designate
information or select particular areas of a video screen display 38 (or
other suitable device, such as a flat-panel display), over which the user
observes the state of the system or, in the case of a subscriber, views
requested information. Ordinarily, interactions between the user and
applications 25 are managed through a suitable graphical user interface
implemented by operating system 29 and appearing on display 34.
In operation, a subscriber (or "client user") employs a client computer as
described above to communicate and interact with the server. The
subscriber's connection to the host is established and maintained by a
dedicated one of the applications 25, which sends and receives messages
via the physical connection to the server sustained by communication
module 27. The client effectively runs its own set of applications 25 as
well as those on the server with which it interacts through message
exchange.
To implement the features of the present invention, the client and server
computers are provided with specialized modules stored in system memory 17
during operation. These modules orchestrate the transfer of items from the
server to clients, and optimal storage of retrieved items on the clients.
Refer to FIG. 3, which shows the key server-based features implementing the
present invention. As indicated earlier, object-oriented storage of items
on the server is facilitated by an OODB and associated management
software. The OODB includes the underlying item data (displayable data,
other item attributes, archival comments of the system designers); the
collection 52 of procedures associated with any one or more items; and a
master table 54, which maintains a list of all item identifiers, a list of
relationships among items, and a list of attributes (including procedures)
associated with each item. All of these components are stored on the
server's mass storage device 19, The attribute list includes pointers to
locations on device 19 where the various data and procedures reside.
An object handler 56, originally stored on device 19 but loaded into main
system memory 17 at the start of server operation, processes item requests
from clients (delivered via communication module 27) and fills these
utilizing the entries in master table 54; the interaction between object
handler 56 and master table 54 is represented by a dashed line, since it
actually occurs over bus 21. Thus, when it receives an item identifier,
object handler 56 engages conventional database management functions to
assemble the requested item from mass storage using the pointers in master
table 54. It then passes the assembled object to communication module 27,
which routes it to the client that issued the request. Object handler 56
also logs any downloading charges associated with a routed item for
billing purposes.
On the client side, illustrated in FIG. 4, a user employs an input device
to articulate item requests (the form and content of which will be
described below) over a suitable interface implemented by operating system
29 and displayed on video monitor 38. The requests are routed to the
server over a communication circuit maintained by communication module 27.
A suitable system for maintaining such circuits, and for facilitating
identification of the client to the server, are described in a copending
application (commonly owned and filed simultaneously herewith) entitled,
METHOD AND APPARATUS FOR FACILITATING SIMPLIFIED DATA INTERCHANGE IN A
DISTRIBUTED COMPUTER ENVIRONMENT. This application is hereby incorporated
by reference in its entirety.
Items transmitted by the server to the client are received by a downloading
and object-management module 60, which is itself stored in the client's
main system memory 17 during operation. Downloading module 60 loads each
item into a separate memory partition, allowing the item's encapsulated
procedures to execute and thereby cause, at a minimum, display of the item
on the client. More specifically, the downloaded item processes its
associated data into a displayable form (e.g., a bitmap or pixelmap), or
into a form easily converted for display by a resident client application
25; the displayable data is stored in a display memory or buffer 62, the
contents of which determine the instantaneous appearance of video display
38.
The downloading module 60 may also store the item in an object store 64,
resident on the client's mass storage device 19, but only if appropriate
in light of the client's need for continuous, instantaneous access to the
item following termination of the session. (As used herein, a "session" is
the duration of the client's interaction with the server over a
communication circuit, and lasts until the circuit is terminated.) A
subscription template 66, described in greater detail below, determines
which received items, and to what extent, are to be cached in the client's
object store 64. The template is only presumptive, however, and a client
can override it by expressly requesting from the server items that would
ordinarily be filtered out by template 66; these items are stored in
object store 64. Therefore, a pruning module 68, preferably actuated at
the conclusion of a session, selectively deletes items from object store
64 so that its contents conform to that dictated by template 66.
2. Object Organization
In accordance with the present invention, each item comprises a header and
contents. An item's header contains the item identifier (which identifies
the item to object handler 56); the title of the item (which is meaningful
to a client user); an identifier of a pictographic symbol, or icon,
associated with the item; any downloading surcharge, which represents an
amount above and beyond the ordinary charge to the user for downloading an
item; a list of encapsulated procedures; and any commentary inserted by
the editor responsible for the item.
The content of an item includes everything needed to display the entire
item on the client's display 38, and preferably in a separate window.
Accordingly, an item's content comprises displayable data, display and any
other procedures encapsulated with the object, and link information. Even
if an item is really no more than a header, it possesses a logically
associated, but empty, contents portion.
Consistent with standard object-oriented programming practice, the
invention supports two types of links: hierarchical links between object
"instances" of upper-tier and lower-tier classes, whereby offspring items
are "contained" within parent items (all the way up the lineage to the
uppermost tier); and forced item links between items that may be (but are
usually not) hierarchically related. Hierarchical links are established by
object handler 56 when an item is created using pointers, Item links, on
the other hand, are not implemented automatically--that is, the linking
item does not behave as if the linked items has been inserted
wholesale--and are instead reflected in a link field present within the
content of the linking item. An item link field contains the item
identifier, item title, icon identifier and download surcharge associated
with the linked item.
One important type of hierarchically arranged item is the folder, the
purpose of which is to manage other items. Besides display instructions,
the contents of a folder are the headers of all children items, any of
which, as described below, can be selected by a client user for retrieval
and viewing. Another hierarchically arranged item is the discussion. A
discussion reflects commentary electronically exchanged by a group of
subscribers in connection with a particular topic. The "root" of a
discussion is the original topic. Each user may post a comment on the root
topic, thereby contributing a primary "branch" to the discussion (which is
denoted by the title the user gives to the comment); or may instead
comment on one of the branches, thereby contributing a secondary (or
deeper) branch. The content of a discussion item includes the content of
all primary branch items and the headers of all lower-tier branches.
As noted above, a linked item ordinarily does not travel with the linking
item; only the information in the link itself is transmitted by the
server. However, a package item contains not only links to one or more
other items, but also an encapsulated procedure that forces downloading of
the linked items along with the package item itself. In this way, the
client overcomes the usual pattern of retaining linked items on the server
(and not allowing them into client object store 64) until selected by the
client user.
It should be noted that the present invention also makes use of class
hierarchies; for example, a package item is a subclass of a folder item,
and therefore inherits all attributes associated with folders in the
present context, however, unless otherwise noted discussions of
hierarchically related items refer to parent/child object relationships
rather than class relationships.
3. Object Presentation
As noted earlier, each item has associated display instructions that
determine the manner in which the item is displayed on the client display
38. However, certain types of items are routinely displayed in
characteristics ways. Folders are displayed in a format called a
"browser", which contains a list of titles of all children items, icons
indicating their types (e.g., an article, a downloadable software file,
another folder, etc.) and, if desired, the downloading charge. The client
user can select (e.g., with mouse 36) any of the items, which are
thereupon retrieved and displayed according to their own display
instructions. (If the item has not been stored in the client's object
store 64, it is retrieved via request to the server and stored in object
store 64; otherwise, downloading module 60 instructs operating system 29
to load the item from object store 64 into display memory 62.) Thus, the
folder appears to contain its children items, although its contents
portion in fact contains only references to them.
Discussions are displayed in a manner that permits the client user to view
the various discussion topics and to post titles; the user can retrieve
the text of any branch item by selecting it with mouse 36.
Folders can contain, in addition to downloadable files, discussions or
other folders. For example, a folder entitled "Downloadable Games" might
contain the subsidiary folder items entitled "Strategy Games,"
"Arcade-Style Games," "Role-Playing Games," and "Educational Games."
Viewing the "Downloadable Games" folder in a browser format, the user
would find the titles of the subsidiary folders preceded by the folder
icon. Upon selecting any of these subsidiary folders, the user would be
presented with a title list of its child items, again preceded by the
appropriate icons. A representative item hierarchy, only one level of
which would ordinarily be presented to the viewer at one time, might be:
(Folder) Downloadable Games
(Folder) Strategy Games
(Downloadable) GNU Chess
(Downloadable) Multi-Player Chess
(Discussion) Who wants to get together to play Multi-Player Checkers
online?
(Folder) Arcade-Style Games
(Downloadable) Doom II
(Article) Computer Gaming World review of Doom II
(Discussion) Is Doom II too violent?
(Folder) Role-Playing Games
(Downloadable) Castle of the Winds
(Folder) Educational Games
where icons are indicated in parenthesis.
Linked items are represented by icons displayed along with the linking
document (e.g., in a bar along the bottom of the screen). The linking
item's display procedure includes instructions for constructing the icons
from icon identifier information and the linked-item titles. When the user
selects an icon, ordinarily by clicking on it with mouse 36, a procedure
encapsulated in the linking item causes downloading module 60 to send a
request for the item (the item identifier for which is contained in the
link) to the server. When the request is fulfilled, downloading module 60
stores the retrieved item in object store 64 and enables the item to
execute its encapsulated display instructions.
A package contains a linking item and at least one linked item that travel
as a group. The client user ordinarily is not informed that an item is a
package. Instead, the icon or the icon-plus-title browser entry
corresponding to the linking (or "key") item is displayed in the usual
manner. Selecting the key item results in retrieval of the entire package
from the server, whereupon downloading module 60 stores the entire series
of linked items in object store 64, and enables its display. The
encapsulated display instructions of a package cause it to display its key
item first; however, all linked items will be resident on the client (in
object store 64 and, ordinarily, in system memory as well).
4. Transfer Restrictions and Pruning
Template database 66 contains restrictions on storage in object store 64
that prevent excessive accumulation of items. Each configuration of
template 66 as it pertains to a particular item is referred to as a
"subscription," since it governs the quantity of information the user will
be able to access when not connected to the server. Preferably,
downloading module 60 is configured to query | | |
