U.S. patent application number 09/835936 was filed with the patent office on 2002-01-03 for system and method for web serving.
Invention is credited to Vange, Mark.
Application Number | 20020002603 09/835936 |
Document ID | / |
Family ID | 22729619 |
Filed Date | 2002-01-03 |
United States Patent
Application |
20020002603 |
Kind Code |
A1 |
Vange, Mark |
January 3, 2002 |
System and method for web serving
Abstract
A method for serving web-based content over a communication
network. Requests for web content are generated using a plurality
of client applications coupled to the network. An intermediary
server is coupled to the network to receive the requests for web
content from client applications. A data server is coupled to the
network and having an interface for communicating with the
intermediary server. The intermediary server accesses the data
server in response to receiving a request from a client
application. Using the intermediary server, a web page is generated
using the database content obtained from the data server. The web
page is delivered to the client application that generated the
request for database content.
Inventors: |
Vange, Mark; (Toronto,
CA) |
Correspondence
Address: |
Stuart T. Langley, Esq.
Hogan & Hartson, LLP
Suite 1500
1200 17th Street
Denver
CO
80202
US
|
Family ID: |
22729619 |
Appl. No.: |
09/835936 |
Filed: |
April 16, 2001 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60197490 |
Apr 17, 2000 |
|
|
|
Current U.S.
Class: |
709/219 ;
707/E17.117 |
Current CPC
Class: |
H04L 69/329 20130101;
H04W 8/04 20130101; Y10S 707/99944 20130101; H04L 45/14 20130101;
H04L 67/565 20220501; H04L 67/1031 20130101; G06F 9/5027 20130101;
H04L 61/4511 20220501; H04L 67/1001 20220501; H04L 67/01 20220501;
H04L 67/564 20220501; H04L 69/16 20130101; H04L 67/1021 20130101;
G06F 9/5055 20130101; H04L 67/5682 20220501; G06F 9/5088 20130101;
H04L 63/0272 20130101; H04L 63/1458 20130101; G06F 9/505 20130101;
H04L 47/24 20130101; H04L 63/1408 20130101; H04L 67/1008 20130101;
H04L 67/61 20220501; H04L 47/10 20130101; H04L 63/1416 20130101;
H04L 63/0428 20130101; H04L 9/40 20220501; H04L 67/02 20130101;
H04L 67/303 20130101; H04L 67/5681 20220501; H04L 67/1029 20130101;
Y10S 707/99945 20130101; H04L 67/563 20220501; H04L 47/193
20130101; H04L 67/142 20130101; H04L 67/101 20130101; H04L 67/1034
20130101; H04L 67/561 20220501; G06F 2209/5021 20130101; H04L
67/568 20220501; H04L 67/10015 20220501 |
Class at
Publication: |
709/219 |
International
Class: |
G06F 015/16 |
Claims
We claim:
1. A web server system comprising: a plurality of client
applications coupled to a communication network and generating web
access requests; an intermediary server coupled to the
communication network to receive the web access requests; a data
storage mechanism coupled to the network and having an interface
for communicating with the intermediary server; means within the
intermediary server responsive to a received web access request for
establishing a channel with the data storage mechanism to obtain
data from the data storage mechanism in response to a received
client request; and web server within the intermediary server for
formatting the obtained data into a web page that is responsive to
a particular web access request.
2. The web server system of claim 1 wherein at least one of the
client applications comprises a web browser application and the
data access requests comprise HTTP requests.
3. The web server system of claim 1 wherein the intermediary server
comprises a web server having a first interface for receiving the
database access requests and a second interface operable to
communicate with the data storage mechanism interface.
4. The web server system of claim 3 wherein the intermediary server
is topologically close to the client applications and topologically
distant from the data storage mechanism.
5. The web server system of claim 1 wherein the intermediary server
comprises: a front-end computer located topologically close to the
client application and configured to receive the data access
requests; a back-end computer located topologically close to the
data storage mechanism and configure to communicate with the
interface of the data storage mechanism; and a communication
channel between the front-end and back-end computers.
6. The web server system of claim 5 further comprising a web server
implemented within the front-end computer.
7. The web server system of claim 1 wherein the data storage
mechanism further comprises: a database operative to return
selected database contents in response to queries; an instruction
processor operative to generate queries against the database and
receive data returned by the database.
8. The web server of claim 7 further comprising: means within the
intermediary server for generating a remote procedure call directed
to the data storage mechanism; and means within the instruction
processor for executing the remote procedure call to generate a
query against the database in response to receiving the remote
procedure call.
9. The web server system of claim 7 further comprising: means
within the instruction processor for generating a remote procedure
call directed to the intermediary server; and means within the
intermediary server for executing the remote procedure call to
generate web page responsive to a particular web access
request.
10. The web server system of claim 1 further comprising: a resolver
mechanism for supplying a network address of the intermediary
server to the client applications, wherein the resolver mechanism
dynamically selects a particular intermediary server from amongst a
plurality of intermediary servers.
11. A method for serving web-based content comprising: providing a
communication network; generating requests for web content using a
plurality of client applications coupled to the network; providing
an intermediary server coupled to the network to receive the
requests for web content from client applications; providing a data
server coupled to the network and having an interface for
communicating with the intermediary server; causing the
intermediary server to access the data server in response to
receiving a request from a client application; using the
intermediary server, generating a web page using the database
content obtained from the data server; and delivering the web page
to the client application that generated the request for database
content.
12. The method of claim 11 wherein the act of generating requests
for database content comprises generating an HTTP request.
13. The method of claim 11 wherein the intermediary server is
topologically close to the client applications and topologically
distant from the data storage mechanism.
14. The method of claim 11 wherein the step of providing an
intermediary server comprises: providing a front-end computer
located topologically close to the client application and
configured to receive the database access requests; providing a
back-end computer located topologically close to the data storage
mechanism and configure to communicate with the interface of the
data storage mechanism; and maintaining a communication channel
between the front-end and back-end computers.
15. The method of claim 11 further comprising: causing the
intermediary server to issue a remote procedure call to the data
server over the established channel to initiate the transport of
data.
16. The method of claim 11 further comprising: causing the data
server to issue a remote procedure call to the intermediary server
over the established channel to initiate the formatting and
delivery of the database content using the data obtained from the
data server.
17. The method of claim 11 further comprising: supplying a network
address of the intermediary server to the client applications by
dynamically selecting a particular intermediary server from amongst
a plurality of intermediary servers.
Description
RELATED APPLICATIONS
[0001] The present invention claims priority from U.S. Provisional
Patent Application No. 60/197,490 entitled CONDUCTOR GATEWAY filed
on Apr. 17, 2000.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The present invention relates, in general, to network
information access and, more particularly, to software, systems and
methods for serving web-based content from a plurality of front-end
computers sharing a database.
[0004] 2. Relevant Background
[0005] Increasingly, business data processing systems,
entertainment systems, and personal communications systems are
implemented by computers across networks that are interconnected by
internetworks (e.g., the Internet). The Internet is rapidly
emerging as the preferred system for distributing and exchanging
data. Data exchanges support applications including electronic
commerce, broadcast and multicast messaging, videoconferencing,
gaming, and the like. In electronic commerce (e-commerce)
applications, it is important to provide a satisfying buying
experience that leads to a purchase transaction. To provide this
high level of service, a web site operator must ensure that data is
delivered to the customer in the most usable and efficient
fashion.
[0006] The Internet is a collection of disparate computers and
networks coupled together by a web of interconnections using
standardized communications protocols. While most Internet access
is currently performed using conventional personal computers and
workstations, the variety of devices that access the Internet is
growing quickly and expected to continue to grow. Wireless devices
such as telephones and pagers are increasingly common. It is
expected that a variety of appliances and devices within offices,
businesses, and households will support Internet connectivity in
the coming years. As a result, supporting interfaces to these
devices has become a significant issue in the problems associated
with providing services over the Internet, including database
services. For example, it is desirable to format data returned to a
cellular phone or pager much differently than might be desirable on
a workstation having a high bandwidth connection and advanced
graphics processing capability. Conventional database systems do
not recognize the different demands required by such diverse access
devices.
[0007] The Internet is characterized by its vast reach as a result
of its wide and increasing availability and easy access protocols.
Unfortunately, the ubiquitous nature of the Internet results in
variable bandwidth and quality of service between points. The
latency and reliability of data transport is largely determined by
the total amount of traffic on the Internet and so varies wildly
seasonally and throughout the day. Other factors that affect
quality of service include equipment outages and line degradation
that force packets to be rerouted, damaged and/or dropped. Also,
routing software and hardware limitations within the Internet
infrastructure may create bandwidth bottlenecks even when the
mechanisms are operating within specifications. The variable nature
of the quality of service (QOS) provided by the Internet has made
development and deployment of database system that leverage the
Internet infrastructure difficult.
[0008] Currently, World Wide Web services are implemented as
client-server systems. The client is typically implemented as a web
browser application executing on a network-connected workstation or
personal computer. The server is typically implemented as a web
server at a fixed network address. A client enters a uniform
resource locator (URL) or selects a link pointing to a URL where
the URL identifies the web server and particular content from the
server that is desired. The client request traverses the network to
be received by the server.
[0009] The web server then obtains data necessary to compose a web
page responsive to the client request. In the case of static pages,
the web server may simply retrieve the page from a file system, and
send it in an HTTP response packet using conventional TCP/IP
protocols and interfaces. In the case of dynamically generated
pages, the web server obtains data necessary to generate a
responsive page, typically through one or more database accesses.
The web server then generates a page, typically a markup language
document, that incorporates the retrieved data. Once generated, the
web server sends the dynamic page in a manner similar to a static
page.
[0010] One problem with the existing system is that the web server
activities required to generate a page can be time consuming. Web
servers can become overburdened and fail when their limited
connection and processing resources are exceeded. To ensure
performance, web site operators often build in excess capacity
increasing the cost and complexity of implementing a web site.
[0011] Another limitation lies in the fact that the web server is
typically configured to generate only one type of page for a given
request. Generally, it is left to the browser software to display
the generated page in an expected and useful manner. This, however,
may not be possible in many cases due to the wide variety of
display devices currently used to execute web browser clients. For
example, a personal digital assistant (PDA), telephone, or pager
cannot be expected to display an HTML page in a similar manner to a
workstation or personal computer. Even on a personal computer,
varieties of browser software often cause conflicting goals in page
generation within the web server.
[0012] Some web servers can be programmed to respond to parameters
sent with a client request to generate a page more specifically
tailored to the requester's needs. For example, an HTTP request
parameter may specify the browser version and maker, or may specify
that the browser is operating on a wireless device. Such
implementations require the web server to be specially programmed
for each device type. Maintaining such functionality and creating
new functionality for new devices is a significant maintenance
problem and, in practice, limits a web site's ability to reach new
audiences.
[0013] The web server interface often becomes a critical bottleneck
in database performance. Web servers have limited resources (e.g.,
buffers, ports, etc.) that must be shared amongst the tasks of
maintaining connections, processing requests, accessing data, and
rendering pages. These resources include software and hardware
resources within the web server that create and maintain
connections to clients, as well as resources used to translate
requests into a database recognized format and translate responses
to formats that can be recognized by clients. Multiple web servers
may be required to support even modest activity rates. This becomes
difficult and expensive for the web site owner to establish and
administer.
[0014] A particular need exists in environments that involve
multiple users accessing a shared network resource such as a
database server or database management system. Examples include
broadcast, multicast and videoconferencing as well as most
electronic commerce (e-commerce) applications. These environments
increasingly involve resource-intensive processing at the web
server.
SUMMARY OF THE INVENTION
[0015] Briefly stated, the present invention involves a method and
system for serving web-based content over a communication network.
Requests for web content are generated using a plurality of client
applications coupled to the network. An intermediary server is
coupled to the network to receive the requests for web content from
client applications. A data server is coupled to the network and
having an interface for communicating with the intermediary server.
The intermediary server accesses the data server in response to
receiving a request from a client application. Using the
intermediary server, a web page is generated using the database
content obtained from the data server. The web page is delivered to
the client application that generated the request for database
content.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] FIG. 1 illustrates a general distributed computing
environment in which the present invention is implemented;
[0017] FIG. 2A shows in block-diagram form significant components
of a system in accordance with a first embodiment of the present
invention;
[0018] FIG. 2B shows in block-diagram form an arrangement of
components in accordance with a second embodiment of the present
invention;
[0019] FIG. 3 shows a domain name system used in an implementation
of the present invention;
[0020] FIG. 4A shows intermediary server components of FIG. 2A in
greater detail;
[0021] FIG. 4B shows front-end components of FIG. 2B in greater
detail; and
[0022] FIG. 5 shows back-end components of FIG. 2B in greater
detail.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0023] The present invention is illustrated and described in terms
of a distributed computing environment such as an enterprise
computing system using public communication channels such as the
Internet. However, an important feature of the present invention is
that it is readily scaled upwardly and downwardly to meet the needs
of a particular application. Accordingly, unless specified to the
contrary, the present invention is applicable to significantly
larger, more complex network environments, including wireless
network environments, as well as small network environments such as
conventional LAN systems.
[0024] A web server or web site can be thought of conceptually as a
set of data and a bundle of services that manipulate that data to
generate web pages. Traditionally, the data and program code that
implement the services are housed together on a server. In early
web site implementations this co-location of services and data was
viewed as practical.
[0025] The present invention recognizes that the services used to
manipulate the data can be more efficiently implemented in
distributed servers located throughout a network topology. These
distributed servers access one or more shared databases to generate
web pages in response to requests. Because the computers
implementing the services are separate from the computers
implementing the database, each can be optimized for the
specialized task required. Resources used to generate pages will
not conflict with resources used to perform database queries, for
example.
[0026] Moreover, the "front-end" computers and intermediate
computers used to generate pages can be made more specific to a set
of client applications. For example, a first front-end computer
might serve cell phone clients, while a second front-end server
might serve workstation clients. The first front-end server can
implement special-purpose functionality to improve display and
performance for the wireless clients without special-purpose
programming on the part of the web-site owner.
[0027] FIG. 1 shows an exemplary computing environment 100 in which
the present invention may be implemented. Environment 100 includes
a plurality of local networks such as Ethernet network 102, FDDI
network 103 and Token ring network 104. Essentially, a number of
computing devices and groups of devices are interconnected through
a network 101. For example, local networks 102, 103 and 104 are
each coupled to network 101 through routers 109. LANs 102, 103 and
104 may be implemented using any available topology and may
implement one or more server technologies including, for example
UNIX, Novell, or Windows NT networks, or peer-to-peer type network.
Each network will include distributed storage implemented in each
device and typically includes some mass storage device coupled to
or managed by a server computer. Network 101 comprises, for
example, a public network such as the Internet or another network
mechanism such as a fibre channel fabric or conventional WAN
technologies.
[0028] Local networks 102, 103 and 104 include one or more network
appliances 107. One or more network appliances 107 may be
configured as an application and/or file server. Each local network
102, 103 and 104 may include a number of shared devices (not shown)
such as printers, file servers, mass storage and the like.
Similarly, devices 111 may be shared through network 101 to provide
application and file services, directory services, printing,
storage, and the like. Routers 109 provide a physical connection
between the various devices through network 101. Routers 109 may
implement desired access and security protocols to manage access
through network 101.
[0029] Network appliances 107 may also couple to network 101
through public switched telephone network 108 using copper or
wireless connection technology. In a typical environment, an
Internet service provider 106 supports a connection to network 101
as well as PSTN 108 connections to network appliances 107.
[0030] Network appliances 107 may be implemented as any kind of
network appliance having sufficient computational function to
execute software needed to establish and use a connection to
network 101. Network appliances 107 may comprise workstation and
personal computer hardware executing commercial operating systems
such as Unix variants, Micrsosoft Windows, MacIntosh OS, and the
like. At the same time, some appliances 107 comprise portable or
handheld devices using wireless connections through a wireless
access provider such as personal digital assistants and cell phones
executing operating system software such as PalmOS, WindowsCE, EPOC
and the like. Moreover, the present invention is readily extended
to network devices such as office equipment, vehicles, and personal
communicators that make occasional connection through network
101.
[0031] Each of the devices shown in FIG. 1 may include memory, mass
storage, and a degree of data processing capability sufficient to
manage their connection to network 101. The computer program
devices in accordance with the present invention are implemented in
the memory of the various devices shown in FIG. 1 and enabled by
the data processing capability of the devices shown in FIG. 1. In
addition to local memory and storage associated with each device,
it is often desirable to provide one or more locations of shared
storage such as disk farm (not shown) that provides mass storage
capacity beyond what an individual device can efficiently use and
manage. Selected components of the present invention may be stored
in or implemented in shared mass storage.
[0032] One feature of the present invention is that front-end
servers 201 (shown in FIG. 2B) and/or intermediate servers 206
(shown in FIG. 2A) are implemented as an interchangeable pool of
servers, any one of which may be dynamically configured to provide
the database application services. The embodiments of FIG. 2A and
FIG. 2B are not strictly alternative as they may coexist in a
network environment. A redirection mechanism is enabled to select
from an available pool of front-end servers and direct client
request packets from the originating web server to a selected
front-end server 201 or intermediary server 206.
[0033] In the case of web-based environments, front-end 201,
intermediary server 206, and back-end server 203 are implemented
using custom or off-the-shelf web server software. For purposes of
this document, a web server is a computer or system of computers
running server software coupled to the World Wide Web (i.e., "the
web") that delivers or serves web pages. The web server has a
unique IP address and accepts connections in order to service
requests by sending back responses. A web server differs from a
proxy server or a gateway server in that a web server has resident
a set of resources (i.e., software programs, data storage capacity,
and/or hardware) that enable it to execute programs to provide an
extensible range of functionality such as generating web pages,
accessing remote network resources, analyzing contents of packets,
reformatting request/response traffic and the like using the
resident resources. In contrast, a proxy simply forwards
request/response traffic on behalf of a client to resources that
reside elsewhere, or obtains resources from a local cache if
implemented. A web server in accordance with the present invention
may reference external resources of the same or different type as
the services requested by a user, and reformat and augment what is
provided by the external resources in its response to the user.
Commercially available web server software includes Microsoft
Internet Information Server (IIS), Netscape Netsite, Apache, among
others. Alternatively, a web site may be implemented with custom or
semi-custom software that supports HTTP traffic.
[0034] In the embodiment of FIG. 2A, intermediary servers 206
interact directly with data servers 210, 211 and 212. In the
embodiment of FIG. 2B, the front-end server establishes and
maintains an enhanced communication channel with a back-end server
203. By enhanced, it is meant that the channel offers improved
quality of service, lower latency, prioritization services, higher
security transport, or other features and services that improve
upon the basic transport mechanisms (such as TCP) defined for
Internet data transport.
[0035] In the specific examples herein, client 205 comprises a
network-enabled graphical user interface such as a World Wide Web
browser ("web browser"). However, the present invention is readily
extended to client software other than conventional web browser
software. Any client application that can access a standard or
proprietary user level protocol for network access is a suitable
equivalent. Examples include client applications that act as front
ends for file transfer protocol (FTP) services, voice over Internet
protocol (VOIP) services, network news protocol (NNTP) services,
multi-purpose internet mail extensions (MIME) services, post office
protocol (POP) services, simple mail transfer protocol (SMTP)
services, as well as Telnet services. In addition to network
protocols, the client application may serve as a front-end for a
network application such as a database management system (DBMS) in
which case the client application generates query language (e.g.,
structured query language or "SQL") messages. In wireless
appliances, a client application functions as a front-end to a
wireless application protocol (WAP) service.
[0036] Data storage mechanism 210, virtual database server 211, and
database server 212, collectively referred to as "data servers",
implement connectivity to network devices such as back-end 203
and/or intermediary server 206 to receive and process requests for
data. Data servers can be implemented as a database including
relational, flat, and object oriented databases. Alternatively,
data servers may comprise a virtual database that accesses one or
more other databases. Further, data servers may be a data storage
device or network file system that responds to requests by fetching
data.
[0037] FIG. 2B illustrates an embodiment in which intermediary
server 206 is implemented by cooperative action of a front-end
computer 201 and a back-end computer 203. Front-end mechanism 201
serves as an access point for client-side communications. In one
example, front-end 201 comprises a computer that sits "close" to
clients 205. By "close", "topologically close" and "logically
close", it is meant that the average latency associated with a
connection between a client 205 and a front-end 201 is less than
the average latency associated with a connection between a client
205 and data servers 210-212. Desirably, front-end computers have
as fast a connection as possible to the clients 205. For example,
the fastest available connection may be implemented in the point of
presence (POP) of an Internet service provider (ISP) 106 used by a
particular client 205. However, the placement of the front-ends 201
can limit the number of browsers that can use them. Because of
this, in some applications it may be more practical to place one
front-end computer in such a way that several POPs can connect to
it. Greater distance between front-end 201 and clients 205 may be
desirable in some applications as this distance will allow for
selection amongst a greater number front-ends 201 and thereby
provide significantly different routes to a particular back-end
203. This may offer benefits when particular routes and/or
front-ends become congested or otherwise unavailable.
[0038] Transport mechanism 202 is implemented by cooperative
actions of the front-end 201 and back-end 203. Back-end 203
processes and directs data communication to and from data servers
210-212. Transport mechanism 202 communicates data packets using a
proprietary protocol over the Internet infrastructure in the
particular example. Hence, the present invention does not require
heavy infrastructure investments and automatically benefits from
improvements implemented in the general-purpose network 101. Unlike
the general-purpose Internet, front-end 201 and back-end 203 are
programmably assigned to serve accesses to a particular data server
210-212 at any given time.
[0039] It is contemplated that any number of front-end and back-end
mechanisms may be implemented cooperatively to support the desired
level of service required by the data server owner. The present
invention implements a many-to-many mapping of front-ends to
back-ends. Because the front-end to back-end mappings can by
dynamically changed, a fixed hardware infrastructure can be
logically reconfigured to map more or fewer front-ends to more or
fewer back-ends and web sites or servers as needed.
[0040] Front-end 201 together with back-end 203 function to reduce
traffic across the transport morphing protocol.TM. (TMP.TM.) link
202 and to improve response time for selected browsers. Transport
morphing protocol and TMP are trademarks or registered trademarks
of Circadence Corporation in the United States and other countries.
Traffic across the TMP link 202 is reduced by compressing data and
serving browser requests from cache for fast retrieval. Also, the
blending of request datagrams results in fewer request:acknowledge
pairs across the TMP link 202 as compared to the number required to
send the packets individually between front-end 201 and back-end
203. This action reduces the overhead associated with transporting
a given amount of data, although conventional request:acknowledge
traffic is still performed on the links coupling the front-end 201
to client 205 and backend 203 to a web server. Moreover, resend
traffic is significantly reduced further reducing the traffic.
Response time is further improved for select privileged users and
for specially marked resources by determining the priority for each
HTTP transmission.
[0041] In one embodiment, front-end 201 and back-end 203 are
closely coupled to the Internet backbone. This means they have high
bandwidth connections, can expect fewer hops, and have more
predictable packet transit time than could be expected from a
general-purpose connection. Although it is preferable to have low
latency connections between front-ends 201 and back-ends 203, a
particular strength of the present invention is its ability to deal
with latency by enabling efficient transport and traffic
prioritization. Hence, in other embodiments front-end 201 and/or
back-end 203 may be located farther from the Internet backbone and
closer to clients 205 and/or web servers 210. Such an
implementation reduces the number of hops required to reach a
front-end 201 while increasing the number of hops within the TMP
link 202 thereby yielding control over more of the transport path
to the management mechanisms of the present invention.
[0042] Clients 205 no longer conduct all data transactions directly
with the data servers 210-212. Instead, clients 205 conduct some
and preferably a majority of transactions with front-ends 201,
which simulate, emulate, or actually implement the functions of
data servers 210-212. Client data is then sent, using TMP link 202,
to the back-end 203 and then to the data servers 210-212. Running
multiple clients 205 over one large connection provides several
advantages:
[0043] Since all client data is mixed, each client can be assigned
a priority. Higher priority clients, or clients requesting higher
priority data, can be given preferential access to network
resources so they receive access to the channel sooner while
ensuring low-priority clients receive sufficient service to meet
their needs.
[0044] The large connection between a front-end 201 and backend 203
can be permanently maintained, shortening the many TCP/IP
connection sequences normally required for many clients connecting
and disconnecting.
[0045] A particular advantage of the architectures shown in FIG. 2A
and FIG. 2B is that they are readily scaled. In accordance with the
present invention, not only can the data itself be distributed, but
the functionality and behavior required to generate web pages from
the data is readily and dynamically ported to any of a number of
intermediary computers 206 and/or front-ends 201 and/or back-ends
203. In contrast, conventional web server systems lock the
functionality to a particular server or limited set of servers. In
this manner, any number of client machines 205 may be supported. In
a similar manner, a database owner may choose use multiple data
servers 210-212 that are co-located or distributed throughout
network 101. To avoid congestion, additional front-ends 201 may be
implemented or assigned to particular databases. Each front-end 201
and/or intermediary server 206 is dynamically re-configurable by
updating address parameters to serve particular web sites. Client
traffic is dynamically directed to available front-ends 201 to
provide load balancing and quality of service (QoS) management.
Hence, when quality of service drops because of a large number of
client accesses to a particular data server 210-212, an additional
front-end 201 and/or intermediary server 206 can be assigned to the
data server 210-212 and subsequent client requests directed to the
newly assigned computer to distribute traffic across a broader
base.
[0046] In the examples, dynamic configuration is implemented by a
front-end manager component 207 (shown only in FIG. 2B) that
communicates with multiple front-ends 201 to provide administrative
and configuration information to front-ends 201. Each front-end 201
includes data structures for storing the configuration information,
including information identifying the IP addresses of data servers
210-212 to which they are currently assigned. Other administrative
and configuration information stored in front-end 201 and/or
intermediary servers 206 may include information for prioritizing
particular data from and to particular clients, quality of service
information, and the like.
[0047] Similarly, additional back-ends 203 can be assigned to a
database to handle increased traffic. Back-end manager component
209 couples to one or more back-ends 203 to provide centralized
administration and configuration service. Back-ends 203 include
data structures to hold current configuration state, quality of
service information and the like. In the particular examples
front-end manager 207 and back-end manager 209 serve multiple data
servers 210-212 and so are able to manipulate the number of
front-ends and back-ends assigned to each data server 210-212 by
updating this configuration information. When the congestion for
the data server 210-212 subsides, the front-end 201, back-end 203,
and/or intermediary server 206 can be reassigned to other, busier
databases. These and similar modifications are equivalent to the
specific examples illustrated herein.
[0048] In order for a client 205 to obtain service from a front-end
201, it must first be directed to a front-end 201 that can provide
the desired service. Preferably, client 205 does not need to be
aware of the location of front-end 201, and initiates all
transactions as if it were contacting the originating server
210-212. FIG. 3 illustrates a domain name server (DNS) redirection
mechanism that illustrates how a client 205 is connected to a
front-end 201. The DNS systems is defined in a variety of Internet
Engineering Task Force (IETF) documents such as RFC0883, RFC 1034
and RFC 1035 which are incorporated by reference herein. In a
typical environment, a client 205 executes a browser 301, TCP/IP
stack 303, and a resolver 305. For reasons of performance and
packaging, browser 301, TCP/IP stack 303 and resolver 305 are often
grouped together as routines within a single software product.
[0049] Browser 301 functions as a graphical user interface to
implement user input/output (I/O) through monitor 311 and
associated keyboard, mouse, or other user input device (not shown).
Browser 301 is usually used as an interface for web-based
applications, but may also be used as an interface for other
applications such as email and network news, as well as
special-purpose applications such as database access, telephony,
and the like. Alternatively, a special-purpose user interface may
be substituted for the more general-purpose browser 301 to handle a
particular application.
[0050] TCP/IP stack 303 communicates with browser 301 to convert
data between formats suitable for browser 301 and IP format
suitable for Internet traffic. TCP/IP stack also implements a TCP
protocol that manages transmission of packets between client 205
and an Internet service provider (ISP) or equivalent access point.
IP protocol requires that each data packet include, among other
things, an IP address identifying a destination node. In current
implementations the IP address comprises a 32-bit value that
identifies a particular Internet node. Non-IP networks have similar
node addressing mechanisms. To provide a more user-friendly
addressing system, the Internet implements a system of domain name
servers that map alpha-numeric domain names to specific IP
addresses. This system enables a name space that provides a more
consistent reference between nodes on the Internet and avoids the
need for users to know network identifiers, addresses, routes and
similar information in order to make a connection.
[0051] The domain name service is implemented as a distributed
database managed by domain name servers (DNSs) 307 such as DNS_A,
DNS_B and DNS_C shown in FIG. 3. Each DNS relies on <domain
name:IP> address mapping data stored in master files scattered
through the hosts that use the domain system. These master files
are updated by local system administrators. Master files typically
comprise text files that are read by a local name server, and hence
become available through the name servers 307 to users of the
domain system.
[0052] The user programs (e.g., clients 205) access name servers
through standard programs such as resolver 305. Resolver 305
includes an address of a DNS 307 that serves as a primary name
server. When presented with a reference to a domain name for a data
server 210-212, resolver 305 sends a request to the primary DNS
(e.g., DNS_A in FIG. 3). The primary DNS 307 returns either the IP
address mapped to that domain name, a reference to another DNS 307
which has the mapping information (e.g., DNS_B in FIG. 3), or a
partial IP address together with a reference to another DNS that
has more IP address information. Any number of DNS-to-DNS
references may be required to completely determine the IP address
mapping.
[0053] In this manner, the resolver 305 becomes aware of the IP
address mapping which is supplied to TCP/IP component 303. Client
205 may cache the IP address mapping for future use. TCP/IP
component 303 uses the mapping to supply the correct IP address in
packets directed to a particular domain name so that reference to
the DNS system need only occur once.
[0054] In accordance with the present invention, at least one DNS
server 307 is owned and controlled by system components of the
present invention. When a user accesses a network resource (e.g., a
database), browser 301 contacts the public DNS system to resolve
the requested domain name into its related IP address in a
conventional manner. In a first embodiment, the public DNS performs
a conventional DNS resolution directing the browser to an
originating server 210-212 and server 210-212 performs a
redirection of the browser to the system owned DNS server (i.e.,
DNC_C in FIG. 3). In a second embodiment, domain:address mappings
within the DNS system are modified such that resolution of the of
the originating server's domain automatically return the address of
the system-owned DNS server (DNS_C). Once a browser is redirected
to the system-owned DNS server, it begins a process of further
redirecting the browser 301 to the best available front-end
201.
[0055] Unlike a conventional DNS server, however, the system-owned
DNS_C in FIG. 3 receives domain:address mapping information from a
redirector component 309. Redirector 309 is in communication with
front-end manager 207 and back-end manager 209 to obtain
information on current front-end and back-end assignments to a
particular server 210-212. A conventional DNS is intended to be
updated infrequently by reference to its associated master file. In
contrast, the master file associated with DNS C is dynamically
updated by redirector 309 to reflect current assignment of
front-end 201 and back-end 203. In operation, a reference to data
server 210-212 may result in an IP address returned from DNS_C that
points to any selected front-end 201 that is currently assigned to
data server 210-212. Likewise, data server 210-212 can identify a
currently assigned back-end 203 by direct or indirect reference to
DNS_C.
[0056] Front-end 201 typically receives information directly from
front-end manager 207 about the address of currently assigned
back-ends 203. Similarly, back-end 203 is aware of the address of a
front-end 201 associated with each data packet. Hence, reference to
the domain system is not required to map a front-end 201 to its
appropriate backend 203.
[0057] FIG. 4A illustrates a first embodiment in which a single
intermediary computer 206 is used, whereas FIG. 4B and FIG. 5
illustrate a second embodiment where both front-end 201 and
back-end 203 are used to implement the intermediary server. Because
of their similarities, FIG. 4A and FIG. 4B are described together
with their differences noted.
[0058] Primary functions of the intermediary server 206 (FIG. 4A)
and front-end 201 (FIG. 4B) and in include serving as a proxy for
data server 210-212 from the perspective of client 205,
prioritizing amongst multiple queries, and applying the queries to
data servers in an order based upon the prioritization. It is
contemplated that the various functions described in reference to
the specific examples may be implemented using a variety of data
structures and programs operating at any location in a distributed
network. For example, a front-end 201 or intermediary server 206
may be operated on a network appliance 107 or server within a
particular network 102, 103, or 104 shown in FIG. 1. The present
invention is readily adapted to any application where multiple
clients are coupling to a centralized resource. Moreover, other
transport protocols may be used, including proprietary transport
protocols.
[0059] TCP component 401 includes devices for implementing physical
connection layer and Internet protocol (IP) layer functionality.
Current IP standards are described in IETF documents RFC0791,
RFC0950, RFC0919, RFC0922, RFC792, RFC1112 that are incorporated by
reference herein. For ease of description and understanding, these
mechanisms are not described in great detail herein. Where
protocols other than TCP/IP are used to couple to a client 205, TCP
component 401 is replaced or augmented with an appropriate network
protocol process.
[0060] TCP component 401 communicates TCP packets with one or more
clients 205. Received packets are coupled to parser 402 where the
Internet protocol (or equivalent) information is extracted. TCP is
described in IETF RFC0793 which is incorporated herein by
reference. Each TCP packet includes header information that
indicates addressing and control variables, and a payload portion
that holds the user-level data being transported by the TCP packet.
The user-level data in the payload portion typically comprises a
user-level network protocol datagram.
[0061] Parser 402 analyzes the payload portion of the TCP packet.
In the examples herein, HTTP is employed as the user-level protocol
because of its widespread use and the advantage that currently
available browser software is able to readily use the HTTP
protocol. In this case, parser 402 comprises an HTTP parser. More
generally, parser 402 can be implemented as any parser-type logic
implemented in hardware or software for interpreting the contents
of the payload portion. Parser 402 may implement file transfer
protocol (FTP), mail protocols such as simple mail transport
protocol (SMTP) and the like. Any user-level protocol, including
proprietary protocols, may be implemented within the present
invention using appropriate modification of parser 402.
[0062] To improve performance, front-end 201 optionally includes a
caching mechanism 403. Cache 403 may be implemented as a passive
cache that stores frequently and/or recently accessed database
content or as an active cache that stores database content that is
anticipated to be accessed. In non-web applications, cache 403 may
be used to store any form of data representing database contents,
files, program code, and other information. Upon receipt of a TCP
packet, HTTP parser 402 determines if the packet is making a
request for data within cache 403. If the request can be satisfied
from cache 403 the data is supplied directly without reference to
data server 210-212 (i.e., a cache hit). Cache 403 implements any
of a range of management functions for maintaining fresh content.
For example, cache 403 may invalidate portions of the cached
content after an expiration period specified with the cached data
or by data sever 210-212. Also, cache 403 may proactively update
the cache contents even before a request is received for
particularly important or frequently used data from data server
210-212. Cache 403 evicts information using any desired algorithm
such as least recently used, least frequently used, first in/first
out, or random eviction. When the requested data is not within
cache 403, a request is processed to data server 210-212, and the
returned data may be stored in cache 403.
[0063] Several types of packets will cause parser 404 to forward a
request towards data server 210-212. For example, a request for
data that is not within cache 403 (or if optional cache 403 is not
implemented) will require a reference to data server 210-212. Some
packets may comprise data that may be supplied to data server
210-212 (e.g., customer credit information, form data and the
like). In these instances, HTTP parser 402 couples to data blender
404.
[0064] In the embodiment of FIG. 4A, the intermediary server 206
may be located topologically near the client 205 or data server
210-212--either alternative provides some advantage and the choice
of location is made to meet the needs of a particular application.
Query language processor 408 receives a parsed request and
formulates it into a proper (i.e., syntactically correct) database
query.
[0065] The formulated query is passed to transport component 409
for communication to data server 210-212 over channel 411. Channel
411 is compatible with an interface to data server 210-212 which
may include a TCP/IP interface as well as Ethernet, Fibre channel,
or other available physical and transport layer interfaces. In a
particular example, transport component 409 is implemented using
extensible data server interface such as the Java database
components (JDBC) that enable plug-in extensions to support
particular database formats.
[0066] Data server returns responses to transport component 409 and
supplies them to data filter 406 and/or HTTP format component 407.
Data filter component may filter and/or constrain database contents
returned in the response. Data filter implements these functions
typically implemented in a DBMS. Data filter component 406 is
optionally used to implement data decompression where appropriate,
decryption, and handle caching when the returning data is of a
cacheable type. HTTP format component 407 formats the response into
a format suitable for use by client 205, which in the particular
examples herein comprises a web page transported as an HTTP
packet.
[0067] Where two intermediary computers are used as in the example
of FIG. 4B and FIG. 5, front-end 201 is responsible for translating
transmission control protocol (TCP) packets from client 205 into
transport morphing protocol.TM. (TMP.TM.) packets used in the
system in accordance with the present invention. Transport morphing
protocol and TMP are trademarks or registered trademarks of
Circadence Corporation in the United States and other countries.
Query formation may take place in back-end 203. Query language
processing may require knowledge of the database structure and
schema of the target data server 210-212. This knowledge will take
the form of a mapping table, for example, that maps field
identifications within a data server 210 to fields present in
parsed request packets. Such information may be more readily
applied in a back-end 203. Conversely, HTTP formatting component
407 is more usefully is preferably implemented in front-end 201
where knowledge of a particular client 205 may be more readily
available.
[0068] Optionally, front-end 201, back end 203, and intermediary
computer 206 implement security processes, compression processes,
encryption processes and the like to condition the received data
for improved transport performance and/or provide additional
functionality. These processes may be implemented within any of the
functional components (e.g., data blender 404) or implemented as
separate functional components within front-end 201. Also, parser
402 may identify priority information transmitted with a request.
The prioritization value may be provided by the owners of data
server 210-212, for example, and may be dynamically altered,
statically set, or updated from time to time to meet the needs of a
particular application. Moreover, priority values may be computed
to indicate aggregate priority over time, and/or combine priority
values from different sources to compute an effective priority for
each database request.
[0069] In the embodiment of FIG. 4B and FIG. 5, blender 404 slices
and/or coalesces the data portions of the received packets into a
more desirable "TMP units" that are sized for transport through the
TMP mechanism 202. The data portion of TCP packets may range in
size depending on client 205 and any intervening links coupling
client 205 to TCP component 401. Moreover, where compression is
applied, the compressed data will vary in size depending on the
compressibility of the data. Data blender 404 receives information
from front-end manager 207 that enables selection of a preferable
TMP packet size. Alternatively, a fixed TMP packet size can be set
that yields desirable performance across TMP mechanism 202. Data
blender 404 also marks the TMP units so that they can be
re-assembled at the receiving end.
[0070] Data blender 404 may also serve as a buffer for storing
packets from all appliances 177 that are associated with front-end
201. In accordance with the present invention, data blender 404 may
associate a prioritization value with each packet.
[0071] TMP mechanisms 405 and 505 implement the TMP protocol in
accordance with the present invention. TMP is a TCP-like protocol
adapted to improve performance for multiple channels operating over
a single connection. Front-end TMP mechanism 405 and corresponding
back-end TMP mechanism 505 shown in FIG. 5 are computer processes
that implement the end points of TMP link 202. The TMP mechanism in
accordance with the present invention creates and maintains a
stable connection between two processes for high-speed, reliable,
adaptable communication.
[0072] Another feature of TMP is its ability to channel numerous
TCP connections through a single TMP pipe 202. The environment in
which TMP resides allows multiple TCP connections to occur at one
end of the system. These TCP connections are then combined into a
single TMP connection. The TMP connection is then broken down at
the other end of the TMP pipe 202 in order to traffic the TCP
connections to their appropriate destinations. TMP includes
mechanisms to ensure that each TMP connection gets enough of the
available bandwidth to accommodate the multiple TCP connections
that it is carrying.
[0073] Another advantage of TMP as compared to traditional
protocols is the amount of information about the quality of the
connection that a TMP connection conveys from one end to the other
of a TMP pipe 202. As often happens in a network environment, each
end has a great deal of information about the characteristics of
the connection in one direction, but not the other. By knowing
about the connection as a whole, TMP can better take advantage of
the available bandwidth.
[0074] FIG. 5 illustrates principle functional components of an
exemplary back-end 203 in greater detail. Primary functions of the
back-end 203 include serving as a proxy for client 205 from the
perspective of data server 210, translating transmission control
protocol (TCP) packets from data server 210 into TMP packets as
well as translating TMP packets from FE201 into the one or more
corresponding TCP packets generated by clients 205.
[0075] TMP unit 505 receives TMP packets from TMP pipe 202 and
passes them to HTTP reassemble unit 507 where they are reassembled
into the corresponding TCP packets. Data filter 506 may implement
other functionality such as decompression, decryption, and the like
to meet the needs of a particular application. The reassembled data
is forwarded to TCP component 501 for communication with data
server 210-212.
[0076] TCP data generated by the data server process are
transmitted to TCP component 501 and forwarded to data filter 502.
Data filter 502 operates in a manner analogous to data filter 406
shown in FIG. 4A and FIG. 4B. Data blender 504 operates in a manner
akin to data blender 404 shown in FIG. 4B to buffer and prioritize
packets in a manner that is efficient for TMP transfer. Priority
information is received by, for example, back-end manager 209 based
upon criteria established by the web site owner. TMP data is
streamed into TMP unit 505 for communication on TMP pipe 202.
[0077] The present invention also involves a number of alternative
modes of functioning using the components shown in FIG. 2A and FIG.
2B. In a first alternative, the front-ends 201 and/or intermediate
computers 206 receive requests and generate database-specific
queries to cause the database to retrieve the desired data. The
data is supplied directly to the front-ends 201 and/or intermediate
computers 206 which execute web server processes to generate markup
language documents (e.g., HTML documents). The markup language
documents are sent to requesting client applications.
[0078] In a second alternative, the front-end 201 or intermediary
206 receives requests, and generates a remote procedure call to a
back-end 203 or data server 210-212 having access to a database. In
this alternative, the back-end server 203 or data server 210-212
formulates and executes a query against the database and returns
the data to the front-end computer 201 or intermediary computer
206. This alternative avoids a requirement for the front-end 201
and/or intermediary 206 to have special knowledge of the database
structure needed to formulate valid queries against a particular
database. However, this second alternative also enables the
processing load required to generate pages to be separated from the
database operations.
[0079] In a third alternative, the front-end 201 and/or
intermediary 206 receives a request and notifies an appropriate
data server 210-212. The data server returns the specified data
along with issuing a remote procedure call to the front-end 201 or
intermediary 206. The remote procedure call causes the front-end
201 or intermediary 206 to generate the web page using the returned
data. This implementation has an advantage that the data server
210-212 remains in control of the page generation process, but
off-loads some of the processing load required to generate a page
to the front-end computer 201 or intermediary computer 206.
[0080] In a fourth alternative, a front-end computer receives a
request and notifies an appropriate data server 210-212. The data
server responds to the notification by sending a remote procedure
call to the front-end computer 201 or intermediary computer 206.
The remote procedure call is accompanied by parameters that enable
the front-end computer 201 or intermediary computer 206 to execute
the remote procedure to generate a properly formatted database
query that is applied to a database directly. Like the second
alternative, this avoids need for the front-end 201 or the
intermediary computer 26 to have specialized knowledge of the
database implementation as that knowledge is conveyed as needed by
the remote procedure call.
[0081] In yet a fifth alternative, the data server 210-212 provides
a profile of the target database in the form of parameters to the
front-end server 201 or the intermediary computer 26. The profile
is used by the front-end server 201 or the intermediary computer 26
to generate a properly formed database query. In either the third
or fourth alternative, it is not necessary that the database be
logically coupled or co-located with the data server.
[0082] One application of the methods and systems of the present
invention is to provide alternative content in response to a user
request when the desired content is unavailable. A particular brand
of alternative content provision is Soft Landing.TM. service. Soft
Landing is a trademark of Circadence Corporation in the United
States and other countries. In accordance with the present
invention, in cases where an originating web server cannot respond
to a request, the present invention enables a front-end or
intermediary server to make database requests to obtain content
from alternative sources and construct a response on behalf of the
unavailable originating web server.
[0083] The alternative sources may provide identical content or
varying content. For example, when the originating web server is
unavailable because it lacks resources to generate a web page, the
present invention enables the front-end or intermediary server to
access the same data as the originating web server and generate the
web page without using the originating web server's resources.
Alternatively, the front-end or intermediary server may access a
mirror copy of the originating web server's data, or may access an
entirely separate database to obtain truly alternative content.
[0084] Although the invention has been described and illustrated
with a certain degree of particularity, it is understood that the
present disclosure has been made only by way of example, and that
numerous changes in the combination and arrangement of parts can be
resorted to by those skilled in the art without departing from the
spirit and scope of the invention, as hereinafter claimed. For
example, while devices supporting HTTP data traffic are used in the
examples, the HTTP devices may be replaced or augmented to support
other public and proprietary protocols including FTP, NNTP, SMTP,
SQL and the like. In such implementations the front-end 201 and/or
back end 203 are modified to implement the desired protocol.
Moreover, front-end 201 and back-end 203 may support different
protocols such that the front-end 201 supports, for example, HTTP
traffic with a client and the back-end supports a DBMS protocol
such as SQL. Such implementations not only provide the advantages
of the present invention, but also enable a client to access a rich
set of network resources with minimal client software.
* * * * *