|
|
|
Access augmentation or optimizing |
Techniques for providing off-host storage for a database application6795830
Abstract
Techniques for distributing database functions in a system of database devices includes performing database management tasks for a database on a first device connected to a network. The first device is designated a database host. Data file storage and retrieval tasks for the database are sent to a second device connected to the network. The second device is designated an off-host storage device. The first device may be a database server appliance, which includes a processor; a database server process, a special purpose operating system and non-volatile storage. The database server process persistently stores data files for the database on a second device connected to the database server appliance over a network. The special purpose operating system has features and configuration that are dictated by the database server and supporting components. The non-volatile storage is sufficiently large to store and execute instructions that cause the processor to perform as the database server process and the special purpose operating system and not sufficiently large to store all data files in the database. These techniques increase reliability of the database on the network by insulating database server processes from the storage system. These techniques also allow sharing of a high performance storage system among multiple database server appliances.
Claims
What is claimed is:
1. A system of database devices comprising:
a network;
a first device, connected to the network, for executing a database server for managing a database, wherein said database server is designed to perform operations on data stored in said database in response to commands that conform to a database language; and
a second device configured as a database storage appliance, wherein said second device is separate from and communicatively coupled with said first device through the network;
wherein the database storage appliance is configured for storing data files for the database, the database storage appliance comprising
a mass storage device,
a file system server designed to perform file operations in response to commands received by the database storage appliance, and
a special purpose operating system whose features and configuration are based on the operating system functionality requirements of the file system server and supporting components.
2. The system of claim 1 wherein the first device is a database server appliance comprising a database server and a special purpose operating system whose features and configuration are dictated by the database server and supporting components.
3. The system of claim 2, wherein:
the system further comprises a second database server appliance connected to the network, the second database server appliance for managing a second database; and
the database storage appliance also stores data files for the second database.
4. A method for processing a database operation, comprising:
receiving a request for the database operation at a database server appliance that includes a database server for managing a database, wherein the database server is designed to perform operations on data stored in said database in response to commands that conform to a database language, wherein the database appliance includes a special purpose operating system whose features and configuration are dictated by the database server and supporting components; and
transmitting, from the database server appliance over a network connection to a database storage appliance that is on a device separate from said database server appliance, data file storage and retrieval tasks required by said database operation, wherein the database storage appliance has a file system server and a special purpose operating system whose features and configuration are based on functionality requirements of the file system server and supporting components.
5. The method of claim 4, further comprising the step of:
determining whether the database server appliance is configured for off-host storage before transmitting the requests to perform file system operations from the database the storage appliance.
6. The method of claim 5, wherein said step of determining whether the -database server appliance is configured for off-host storage further comprising the step of detecting an off-host storage device.
7. The method of claim 5, further comprising the step of:
if it is determined that the database server appliance is configured for off-host storage, then migrating database files of an extant database on the database server appliance to the off-host storage device.
8. The method of claim 5, said step of determining whether the database server appliance is configured for off-host storage further comprises the step of determining whether a detected off-host storage device has a storage capacity sufficient to hold the extant database files.
9. A computer-readable medium carrying one or more sequences of instructions which, when executed by one or more processors, causes the one or more processors to perform the method recited in claim 4.
10. A computer-readable medium carrying one or more sequences of instructions which, when executed by one or more processors, causes the one or more processors to perform the method recited in claim 5.
11. A computer-readable medium carrying one or more sequences of instructions which, when executed by one or more processors, causes the one or more processors to perform the method recited in claim 6.
12. A computer-readable medium carrying one or more sequences of instructions which, when executed by one or more processors, causes the one or more processors to perform the method recited in claim 7.
13. A computer-readable medium carrying one or more sequences of instructions which, when executed by one or more processors, causes the one or more processors to perform the method recited in claim 8.
Description
FIELD OF THE INVENTION
The present invention relates to accessing databases over a network such as the Internet, and, in particular, to increasing efficiency by hosting data server functionality and data storage functionality on separate devices.
BACKGROUND OF THE INVENTION
The complexity of a general purpose database system combined with the complexity of a general purpose operating system with which the database system interacts on a general purpose computer is typically sufficient to require employment of a full-time database administrator (DBA). It is the responsibility of the DBA to grapple with the complexity of the database system, the operating system, and the interactions between them, so that the other database users can take advantage of the database system without being exposed to underlying complexity. Unfortunately, employing a full-time DBA makes ownership of a useful database system an expensive option that may be outside the means of the small to medium sized enterprise.
Maintaining an in house computer system to host a database and Website is also an expensive undertaking even when the enterprise can afford a DBA or small team of information services (IS) professionals. Most computer equipment requires special air-conditioning and power supplies that are expensive to construct in a facility. The equipment itself is expensive and prone to become obsolete as new hardware devices are developed. Even if the equipment is leased, the facility costs remain, and the transfer to upgraded equipment may put a database out of service and consume considerable amounts of skilled IS labor.
One of the costs contributing to a network of database devices is the expense and complexity of each device. A conventional database server device includes a database server and a mass storage subsystem for storing the database files. The database server processes interact with the storage system, adding to the complexity of the database server and the database server device. This complexity both adds to the cost of the server device and decreases the reliability of the entire database on the network. In addition, this requirement to support the data files of the database forces the minimum database device configuration to include sufficient mass storage to support typical database applications adding to the cost of the system, also adding to the cost of the server device. Also because the device must support database server processes as well as storage functions, the device hardware and configuration can not be simultaneously optimized for both server functions and storage functions. Furthermore, including mass storage for the data files on the device inhibits utilization and sharing high-performance storage systems that may become available on the market after the database server device is procured.
Based on the foregoing, it is clearly desirable to provide a computer system that employs features that reduce the cost of maintaining the hardware and software of the database system and the Internet presence. It is further desirable to decrease the complexity of computer systems, and to provide management techniques that allow companies to reduce the size and cost of their in-house IS departments.
SUMMARY OF THE INVENTION
The embodiments of the disclosed techniques reduce the costs to small and medium sized enterprises of establishing and maintaining one or more databases using a network, such as the Internet. According to one aspect of the invention, a database server appliance includes a processor; a database server process, a special purpose operating system and non-volatile storage. The database server process persistently stores data files for the database on a second device connected to the database server appliance over a network. The special purpose operating system has features and configuration that are dictated by the database server and supporting components. The non-volatile storage is sufficiently large to store and execute instructions that cause the processor to perform as the database server process and the special purpose operating system and not sufficiently large to store all data files in the database.
According to another aspect of the invention, techniques for distributing database functions in a system of database devices includes performing database management tasks for a database on a first device connected to a network. The first device is designated a database host. Data file storage and retrieval tasks for the database are sent to a second device connected to the network. The second device is designated an off-host storage device.
These techniques increase reliability of the database on the network by insulating database server processes from the storage system. These techniques also allow sharing of a high performance storage system among multiple database server appliances.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
FIG. 1 is a block diagram of a computer system upon which an embodiment of the disclosed techniques may be implemented.
FIG. 2A is a block diagram of a database appliance for a database server upon which an embodiment of the disclosed techniques may be implemented.
FIG. 2B is a block diagram of database appliance using an off-host database storage appliance according to one embodiment of the disclosed techniques.
FIG. 2C is a flowchart depicting some management tasks performed by a database server using off-host storage according to one embodiment of the disclosed techniques.
FIG. 3A is a block diagram of an Internet database service provider according to one embodiment of the disclosed techniques.
FIG. 3B is a block diagram of a community center server connected to the Internet according to one embodiment of the disclosed techniques.
FIG. 4 is a block diagram of the processes available on a platform of an Internet database service provider showing database tools for the owner of the platform and self-service database tools for customers of the owner, according to one embodiment of the disclosed techniques.
FIG. 5A is a flowchart depicting self-registration by a customer according to one embodiment of the disclosed techniques.
FIG. 5B is a diagram of components on a screen presented to a customer for receiving customer profile input during the self-registration process according to one embodiment of the disclosed techniques.
FIG. 5C is a diagram of components on a screen presented to a customer for receiving customer input concerning database service subscriptions during the self-registration process, according to one embodiment of the disclosed techniques.
FIG. 5D is a flowchart showing steps in a process for registration self-maintenance according to an embodiment of the disclosed techniques.
FIG. 6A is a block diagram of a database web site building appliance according to an embodiment of the disclosed techniques.
FIG. 6B is a flowchart of a database web site building wizard according to an embodiment of the disclosed techniques.
FIG. 6C is a flowchart of a customization process for a provider of the database web site building wizard according to an embodiment of the disclosed techniques.
FIG. 6D is a block diagram illustrating an arrangement of input elements on a web page for customizing a web site component by a user of the wizard according to an embodiment.
FIG. 6E is a block diagram illustrating an arrangement of folders and components on a web page for designing a web site by a user of the wizard according to an embodiment.
FIG. 7 is a flowchart for automatically installing and configuring a database application according to an embodiment of the disclosed techniques.
FIG. 8 is a flowchart for automatically supplying content for a database on a database services provider according to an embodiment of the disclosed techniques.
FIG. 9 is a flowchart for developing new database applications on a database services provider according to an embodiment of the disclosed techniques.
FIG. 10 is a flowchart for accessing a database on a database services provider according to an embodiment of the disclosed techniques.
FIG. 11 is a flowchart for integrating external services on a database services provider according to an embodiment of the disclosed techniques.
FIG. 12A is a block diagram of a process for automatic discovery and management of a new database appliance connected to a network according to an embodiment of the disclosed techniques.
FIG. 12B is a flowchart of a process for automatic discovery and management of a new database appliance connected to a network according to an embodiment of the disclosed techniques.
FIG. 13 is a block diagram of database services for a platform owner available to the database services provider according to an embodiment of the disclosed techniques.
FIG. 14 is a block diagram of the backend database services for a platform owner available to the database services provider according to an embodiment of the disclosed techniques.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Techniques for Internet database services are described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
1.0 Functional Overview
A system is provided that incorporates numerous features that reduce the total cost of generating and maintaining an Internet presence with database components. The system preferably includes one or more "database appliances". A database appliance is a machine that includes database software, such as database server software, and non-database software, where the non-database software is specially tailored to the needs of the database software. Such non-database software may include, for example, operating system software from which have been removed services that are typically used in general purpose computers but are not required to support the needs of the database server. According to one embodiment, even the hardware of the machine deviates from a general-purpose computer in order to more efficiently support specific characteristics and requirements of the database server. Database appliances are described in the related application U.S. patent application Ser. No. 09/240,229, filed Jan. 29, 1999 entitled "Pre-Defined Hardware And Software Bundle Ready For Database Applications," incorporated by reference earlier in this application.
The features include integrated tools for forming a database for a first party on the equipment of a second party, and for designing and automatically implementing a web site with components from the database. Maintenance costs are reduced by sharing equipment and IS personnel costs among several customers of the second party.
The maintenance costs of the database system are further reduced by having a community server deliver applications to database appliances and manage the database appliances of numerous companies, including numerous second parties. The community server provides access to the database appliances over the Internet and backup for restoration of database appliances that have gone down, while simultaneously avoiding the need for those companies to each employ their own expert database administrator.
2.0 Hardware Overview
FIG. 1 is a block diagram that illustrates a computer system 100 upon which an embodiment of the invention may be implemented. Computer system 100 includes a bus 102 or other communication mechanism for communicating information, and a processor 104 coupled with bus 102 for processing information. Computer system 100 also includes a main memory 106, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 102 for storing information and instructions to be executed by processor 104. Main memory 106 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 104. Computer system 100 further includes a read only memory (ROM) 108 or other static storage device coupled to bus 102 for storing static information and instructions for processor 104. A storage device 110, such as a magnetic disk or optical disk, is provided and coupled to bus 102 for storing information and instructions.
Computer system 100 may be coupled via bus 102 to a display 112, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 114, including alphanumeric and other keys, is coupled to bus 102 for communicating information and command selections to processor 104. Another type of user input device is cursor control 116, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 104 and for controlling cursor movement on display 112. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
The invention is related to the use of computer system 100 for automatically provisioning a database accessible from a Web browser. According to one embodiment of the invention, a Web page with database components is provided by computer system 100 in response to processor 104 executing one or more sequences of one or more instructions contained in main memory 106. Such instructions may be read into main memory 106 from another computer-readable medium, such as storage device 110. Execution of the sequences of instructions contained in main memory 106 causes processor 104 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 104 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 110. Volatile media includes dynamic memory, such as main memory 106. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 102. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 104 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 100 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 102. Bus 102 carries the data to main memory 106, from which processor 104 retrieves and executes the instructions. The instructions received by main memory 106 may optionally be stored on storage device 110 either before or after execution by processor 104.
Computer system 100 also includes a communication interface 118 coupled to bus 102. Communication interface 118 provides a two-way data communication coupling to a network link 120 that is connected to a local network 122. For example, communication interface 118 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 118 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 118 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 120 typically provides data communication through one or more networks to other data devices. For example, network link 120 may provide a connection through local network 122 to a host computer 124 or to data equipment operated by an Internet Service Provider (ISP) 126. ISP 126 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 128. Local network 122 and Internet 128 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 120 and through communication interface 118, which carry the digital data to and from computer system 100, are exemplary forms of carrier waves transporting the information.
Computer system 100 can send messages and receive data, including program code, through the network(s), network link 120 and communication interface 118. In the Internet example, a server 130 might transmit a requested code for an application program through Internet 128, ISP 126, local network 122 and communication interface 118. In accordance with the invention, one such downloaded application is a database application as described herein.
The received code may be executed by processor 104 as it is received, and/or stored in storage device 110, or other non-volatile storage for later execution. In this manner, computer system 100 may obtain application code in the form of a carrier wave.
3.0 Example System
According to one embodiment, techniques are provided that allow a party to serve the role of an "Internet Database Service Provider" or IDSP. Like an ISP, the IDSP is a second party service provider which maintains the equipment necessary for a subscriber to use the Internet. Unlike the conventional ISP, the IDSP provides the subscriber with database services that are accessible over a network to which the subscriber has access. In certain embodiments, the database services may be part of a larger package that provides the subscriber with an Internet presence that includes automatically generated database components. The IDSP itself may be supported by a third party, such as a database software developer, operating a database community server on the Internet.
The IDSP includes an IDSP platform (item 332 in FIG. 3A) and a plurality of database appliances (item 336 in FIG. 3A). FIG. 2A depicts a database appliance as described in U.S. patent application Ser. No. 09/240,229, referenced above. In that application a database appliance includes a database server process 212, an operating system 214 tailored to support the database server process 212, and hardware 216. The server software, operating system software, database configuration parameters, and the database files themselves are stored on nonvolatile mass storage devices 218.
As used herein, the term database appliance includes any database device with a special purpose operating system tailored to the database process running on the device, including the database server appliance 220 and the database storage appliance 230 described next. The main distinction among database appliances is the function provided by the database process running on the appliance. Other examples of database appliances include an internet appliance which supports a connection with the Internet, a database Web server appliance (for example, an ORACLE 8i appliance) which provides access to a database system through a user's Web browser, and a database web site building appliance which provides a wizard for building a series of Web pages with database components and is described in greater detail later below.
3.1 Off-Host Storage
FIG. 2B shows a database network including two new database appliances. Database storage appliance 230 does not include a database server process, but instead has a file system process 234 operating on hardware 236 and mass storage devices 238. This allows the database storage appliance 230 to comprise high-performance external storage systems available from a number of vendors.
In general, database storage appliance 230 is a computing device including a mass storage device, and a processor configured to run a file system server process and a special purpose operating system whose features and configuration are dictated by the mass storage device, the file system server and supporting components.
A database storage appliance 230 is one component of a system of database appliances including a database server appliance 220. Database server appliance 220 includes a database server 222 and a special-purpose operating system 224 but only sufficient non-volatile storage 228 to use for the server software and operating system and configuration parameters. The database server appliance 220 does not store the data files themselves. The single database storage appliance 230 stores the data files for one or more database server appliances 220. The network may also include one or more other database appliances 240 configured like database appliance 210 in FIG. 2A, as described in the related application. In this case, the database storage appliance 230 stores the data files for the other database appliances 240 as well. In other embodiments multiple storage appliances provide storage for a database managed by a single server.
The database server on a database host performs database management tasks for a database. The management tasks now include determining whether the system is configured for off-host storage. If it is determined that the system is configured for off host storage, then the data files are stored on the off-host storage device. If a database already exists on the database host when it is determined that the system is configured for off-host storage, then the extant database is migrated to the off-host storage device. This process is described in more detail with respect to FIG. 2C.
Management tasks performed by the database server appliance in this embodiment start at step 260 when the database server commences operation (e.g., boots up). In step 262, it is determined whether configuration files maintained for the database server, either at the server or at a separate database directory services device, such as a database directory services appliance, indicate that database files reside on off-host storage devices. A set of off-host storage device types is maintained by the configuration files. For example, an off-host storage device that connects to the database host through a host bus adapter (HBA) is model X of Company A, and an off-host storage device that connects to the database host through a network, called network attached storage (NAS) is model Y of Company B. If any HBA or NAS devices, such as model X and model Y, are found in the database directory, then off-host storage is already being used, and the system is configured for off-host storage.
If off-host storage is already used, as determined in step 262, then control passes to step 282 to determine if any off-host storage devices have joined the system that are not already in the database directories. In one embodiment, HBA based storage uses a fiber optic channel connected to the host via a SCSI connection. Such a device responds to an inquiry command. Thus an inquiry command is issued to determine what HBA based storage devices are connected. In this embodiment, NAS devices use Ethernet connections and respond to a ping command or a remote shell (rsh) command. The devices that respond to the inquiry and ping and rsh commands are compared to the devices already listed in the configuration files to determine whether any of the devices are new to the system. Step 284 represents a branch point based on whether any new off-host storage devices are detected.
If no new off-host storage devices are detected, control passes to step 288 to continue using the off-host storage devices already listed in the configuration files. If a new off-host storage device is detected, then control passes to step 286 to scale up the database using the additional off-host storage devices. The database can be scaled up by increasing the total size of the database, such as by adding additional files, or increasing the allotment to each file.
If, in step 262, it is determined that no off-host storage devices are already being used, then control passes to step 264 to determine whether any off-host storage devices are connected. The HBA devices are found using the inquiry command and the NAS devices are found using a ping or rsh command. Step 266 represents the branch point based on detecting any off-host storage devices. If no off-host storage device is found, then control passes to step 268 to continue using internal storage on the host, such as the database server appliance. If even one off-host storage device is found, then control passes to step 270. In another embodiment, the space available on the newly found off-host storage devices is also checked during step 266. If the off-host storage devices do not have sufficient space to store the database files, then the system is considered not properly configured for off-host storage, and flow passes to step 268 to continue using internal storage.
In step 270 it is determined whether the database server is running for the first time for this database, e.g., whether this is the first boot-up of this database server. If so, then the database is being created and control passes to step 274 to create the database and store the database files initially on the one or more connected off-host storage devices. If not, then a database already exists on internal storage. In this case, control passes to step 272 to migrate the extant database to off-host storage from internal storage.
In step 272 the file systems on the off-host storage devices are mounted and the database files are copied to them--keeping the distribution of files across several disks on each device identical to the distribution across disks on the internal storage, if possible. If not possible, then the database configuration is modified such as by renaming some data files that have been moved to different locations on disk. After the copying, configuration files are modified to indicate the off-host storage devices involved. If any of these migration functions fail, such as due to a lack of space, or due to communication failure, any changes are reversed (un-done) and the database server continues to use the internal storage.
In other embodiments, the steps can be performed in a different sequence. For example, the test for off-host storage devices connected to the host (steps 264 and 282) can be combined and performed first, before checking the configuration files in step 262. If no off-host storage devices are found, control passes to step 268 to use internal storage. If off-host storage devices are found, then it is determined whether any appear in the configuration files for the database in step 262. If none, control passes to step 270. If some are found, then control passes to step 284 to determine if any are new.
With off-host storage, database server processes are insulated from the storage system. This increases the reliability of the database on the network and allows sharing of the high-performance storage system on the database storage appliance 230 among multiple database server appliances 220 and other database appliances 240. This can save costs in establishing a database on a network because the database server appliance 220 may be less expensive than a database appliance 240 that requires extra non-volatile storage to hold the data files themselves. In particular, cost savings are achieved if an off-host storage device is already on the network with unused capacity sufficient for the database.
3.2 The IDSP System Components
FIG. 3A shows the environment and components of an Internet Database Service Provider (IDSP). In the embodiment depicted, a service provider 302 is connected directly to local network 312a, and to the Internet 320. Through the Internet 320, one or more other local networks 312b may be connected to the service provider 302. As used herein, a local network 312 includes one or more workstations or user platforms.
Service provider 302 may be characterized as an IDSP if it allows third parties to use and access, over a network such as the Internet, one or more databases that it controls and manages. An IDSP system 330 that may be used by service provider 302 to provide the database services shall be described in greater detail hereafter.
Service provider 302 may additionally be characterized as an Internet service provider (ISP) if it provides third parties with access to the Internet 320. For example, local network 312a may be owned by a third party that accesses the Internet 320 through service provider 302. When serving as an ISP, the third party that owns local network 312a connects to the service provider 302 network of components through a router 304. This connection may either be direct, as shown, or through one or more modems and a firewall (not shown). A firewall is a device that enforces a login procedure to ensure that a caller is authorized to access a network.
The service provider 302 may also be characterized as an application service provider (ASP) if it allows third parties to use and access, over a network such as the Internet, one or more software applications. Such applications may include, for example, inventory, accounting or billing applications. When the service provider serves as an ASP, the third party that owns local network 312b connects to the service provider 302 through the Internet 320.
The service provider 302 may support a public web site, which requires a platform 308a outside the firewall 306 and accessible via the Internet 320. The service provider 302 may also support one or more applications on private platform 308b, inside the firewall 306, not directly accessible via the Internet 320. To access the private platform 308b via the Internet, a user must engage a login procedure to pass through the firewall 306. A login procedure may be performed through a public Web page, e.g., Web page 340, that will allow the user to pass through the firewall 306. In other embodiments, the firewall 306 may be absent and either the entire system is open to the public or individual processes running on the various platforms 308 and 332 may enforce their own login procedures.
To support database procedures at the service provider 302, an Internet database service provider (IDSP) system 330 is incorporated at the service provider site 302. The IDSP system 330 includes an IDSP platform 332, an IDSP console 334, and one or more database devices. Database devices are any devices used to manage access to a database. The databases devices used by service provider 302 may include, for example, one or more database appliances 336 and/or one or more general-purpose computers 338 executing a database server program.
The IDSP platform 332 performs as a database device manager. It performs many database device management functions automatically. When action by the service provider 302 is required, an agent of the service provider 302, such as a database administrator employed by the service provider, may operate the IDSP system 330 through the IDSP console 334. The IDSP console runs a process, such as the ORACLE Enterprise Manager (OEM), for allowing a human database administrator to interact with the IDSP platform and its processes. Alternatively, the process running on the console can be as simple as a Web browser with most of the screens presented to the administrator being generated on the IDSP platform.
The IDSP system 330 provides database functionality for the service provider 302, and allows the service provider 302 to offer database functionality to customers such as the parties that own local networks 312. The IDSP system 330 is designed to automatically provide greater database functionality than is currently available at service providers on the Internet.
In the illustrated embodiment, the IDSP system 330 has one group of database appliances, e.g., 336a through 336d, configured as a staging area for testing new database applications and upgrades. The IDSP system 330 has a second group of database appliances, e.g., 336e through 336h, configured as a production area for providing database operations to the service provider 302 and its customers. Staging and production areas will be described in more detail below.
In cases where the service provider 302 is offering database functionality to its customers, a registration process, described later, will identify the database resources the customer is willing to pay the service provider to procure. As used herein, database resources include consumable database resources such as storage space, central processing unit (CPU) usage, connection bandwidth, number of users licensed for a database application, and number of transactions.
Database resources also include database applications, such as database development applications, sales database applications, invoice database applications, inventory database application, personnel database applications, document database applications, and many other software applications with database elements available from a variety of vendors.
To provide the consumable resources requested by the customers, the service provider 302 procures and installs database equipment, thus avoiding the need for the service provider's customers to buy and install the equipment. To provide the applications, the service provider procures and installs software, or contracts for downloading software as needed from one or more software vendors, thus avoiding the need for the service provider's customers to procure and install the software.
Depending on the consumable database resources for which customers have registered, the IDSP system 330 will configure a database device as either a dedicated device or a plurality of virtual devices. If the customer requires all the consumable resources provided by a database device, that device will be configured as a dedicated device for that customer. If, however, a customer requires only a portion of the consumable resources available on a database device, then that device can be shared among several customers. In this case, the IDSP system 330 will configure a virtual database device for that customer that comprises only a portion of the consumable resources available on the database device.
The connection between the local network 312 and the service provider 302, can be configured as an open Internet connection or as a virtual private network (VPN). A VPN uses Internet packets in which the payload is encrypted according to a procedure known only to the service provider and the particular local network requiring the private connection. The IDSP system 330 is configured to communicate with customers over either open Internet or VPN connections, at the option of the service provider 302.
According to one of the related applications cited above, database appliances are easily used in a network on which one or more general purpose computers can host certain shared processes, specifically a directory server process, a backup server process, and an integrated management console process. Alternatively, appliances can be obtained that perform each of these functions. In the embodiment depicted in FIG. 3A, the IDSP console 334 performs the presentation and input functions of the integrated management console for the database appliances 336 connected to the IDSP platform 332. At the console the database administrator for the platform owner can perform several functions including starting and shutting down a database, setting up automated tasks such as backups and reports, recognizing automatically when new appliances are added or removed, performing manual backups, running reports, applying patches, and monitoring the system.
In this embodiment, the backup server process, the directory server process and portions of the management services other than the user interface run on the IDSP platform.
3.3 A System of IDSPs
The same database device management software installed on the IDSP platform 332, and the software on the database devices connected to it, can be used by many service providers. As with any software, the database device management software for the DSP system will undergo incremental upgrades and replacements, denoted by different version numbers. FIG. 3B depicts a system for using the Internet to provide database software updates and other database services to one or more service providers.
According to the embodiment depicted in FIG. 3B, two ISPs 352a and 352b and an ASP 354 incorporate IDSP systems 342a, 342b, and 344, respectively. In addition, FIG. 3B illustrates an IDSP 362 that provides database services (without also providing ASP or ISP services) and an ASP 360 that subscribes to IDSP 362 for the database services required to support the application services provided by ASP 360. All of the service providers are connected to the Internet 320.
3.4 Community Server
A community center server 390, also called a community server, is also connected to the Internet 320 in order to distribute to the service providers database software and database software updates over the Internet 320. An update services process 393 runs on the community server 390 to send the updated software to a service provider. The update operation can be automatically triggered by an event (such as the posting of the new update), performed on a pre-defined schedule, and/or triggered by a request from the service providers.
In addition, the community server 390 provides the directory services required for managing a network of database appliances in a directory services process 391. In another embodiment, the community server 390 provides the backup services required for a network of database appliances in a backup services process (not shown). In addition, the community server 390 provides some management services 395 for the database networks on one or more of the service providers.
For example, using the management services process 395 on the community server 390, a database administrator for ASP 354, who happens to be away from the service provider's facility, can connect to the community server 390 from a computer 358 through the Internet 320 and perform some management functions. The database administrator, using computer 358, connects to the management services 395 on the community server 390 to check on the status of database appliances in IDSP 344, or configures them as virtual appliances, or to perform any number of database management tasks. Such powerful database administrative functions are preferably performed by requiring a login process between the user on computer 358 and the management services process 395, such as by establishing a VPN connection. A VPN connection can be established between the computer 358 and the community server 390 even if a VPN connection is not available with ASP 354. In this case, one or more of the management functions involves the database administrator sending to the community server data indicating authorized users and privileged requests related to the database being administered, including adding an authorized user and deleting an authorized user for the database, and changing database resources a user may access.
Other management functions include licensing software from the community: server and changing license terms for using software licensed through the community server.
In another example, a customer of ASP 354 who has a database running in IDSP system 344 may obtain status information, such as a percentage of storage space being utilized by the customer's database, from the management services 395 on the community server 390 over the Internet. By using the community server 390, the customer can obtain this information from computer 358 even if the ASP 354 or its IDSP system 344 is off-line for any reason. The ASP 354 or IDSP system 344 may be off-line due to maintenance, equipment failure, or other failure.
Also shown in FIG. 3B is a local network 356 having its own database appliances 346. The community server 390 can provide the database appliances management required by the database appliances 346, such as directory services 391 and backup services (not shown). In addition, the community server 390 can update the software used by the local network 356 on the database appliances 346. Thus, the community server 390 can support one or more local networks managing their own database appliances even without a third-party services provider.
4.0 IDSP Processes Overview
FIG. 4 is a block diagram of the processes available on a platform of an Internet database service provider showing database tools for the owner of the platform and self-service database tools for customers of the owner, according to one embodiment of the disclosed techniques.
The IDSP platform 332 includes an IDSP provisioning process 480 that makes available several tools for the platform owner (the IDSP). The IDSP platform 332 also includes a self-service database provisioning process 410 that makes available several tools for the customers of the IDSP. Examples of tools that may be made available by these processes to the IDSP and to the customers of the IDSP shall be described in greater detail hereafter.
The customer of an IDSP may be any entity that requires database services but does not want to expend the time and resources to manage their own database system. For example, ASP 360 may provide over the Internet 320 a service, such as accounting, that requires the storage of data in a database. Rather than maintain its own database for its accounting application, ASP 360 can acquire database services over the Internet 320 ,from IDSP 362. In addition to ASPs, the customers of an IDSP may include companies that are running database applications for their own use (as opposed to ASPs that run applications for the use of other parties). A party using, for its own internal applications, the database services provided by IDSP 362 is represented by computer 358 in FIG. 3B.
According to one embodiment, not all the steps of each process are performed on the IDSP platform 332. Many steps of these processes, for example, are performed on one or more database appliances and other database devices connected to the platform. However, all these processes are at least launched from the processes running on the IDSP platform.
4.1 Self-service Database Tools
The self-service database provisioning process 410 provides services to customers. As mentioned above, those customers may be any entities that require a database but that do not want the hassle and expense of maintaining the database themselves. Thus, a single IDSP may provide database services to multiple ASPs, ISPs, and to companies that require databases for their own internal applications (e.g. the inventory program of a warehouse company).
According to one embodiment, the customers use a client, such as a Web browser on a workstation in a local network, to obtain selectable database services from the service provider over a network. According to one embodiment, the services provided by process 410 are made available to customers by allowing the customers to access Web pages that have controls which, when selected, cause process 410 to perform or initiate a corresponding service.
According to one embodiment, the self-service process allows a customer to select a variety of services, including customer initial registration 415 and registration self-maintenance 417. Also included is access to a build wizard 420 for generating a web site of one or more web pages. The self-service process 410 allows a customer to obtain database applications using an automatic installation configuration process 430. A customer can also obtain content for a database created for the customer from a source of content using the database content supply process 440 of the self-service tools 410. The customer can develop a new database application using the database application development tool 450 of the self-service provisioning process 410.
The database access process 460 allows the customer to perform ordinary database functions for databases on the devices controlled by the IDSP platform 332 through the self-service provisioning process 410. The database to which the customer obtains access may be a database belonging to the customer or may be a database to which the customer has subscribed and which belongs to or is maintained by another party.
The integrated external services process 470 of the self-service database tools 410 provides a means for the customer to obtain services from processes outside the IDSP system 330, such as a credit card payment service. Each of these processes of the self-service database provisioning process 410 is described in more detail later below.
4.2 IDSP Management Tools
The IDSP provisioning process 480 provides database management tools for use by the IDSP. According to one embodiment, the process 480 includes a process 485 for the automatic discovery and registration of a new database appliance connected to the network of database devices in the IDSP system 330. The process 490 represents other IDSP management tools. Each of these processes is described in more detail in a later section. As with the tools selectable through the self-service process 410, some of the steps in these selectable processes may be performed on devices other than the IDSP platform. However, in one embodiment the IDSP platform 332 runs the platform-owner process 480 which at least launches the selected process.
5.0 Self-service Registration
5.1 Self-service Initial Registration
FIG. 5A is a flowchart depicting self-registration by a customer according to one embodiment of the disclosed techniques. In this embodiment, the customer registers with the IDSP system online. The registration is consistent with any registration for other services provided by the service provider, so that the customer does not have to register several times to access various services. In case the services provider does not have any registration module, the IDSP registration process will handle the registration. The customer is prompted to provide personal and billing information and select the services that the customer wishes to subscribe to, as described in more detail below. In case the services provider already has a registration service, the IDSP system employs an application program interface (API) so that the existing system can be used. This API transfers to the IDSP system a list of services that the customer has subscribed to, as well as the username and password that have been assigned to the customer.
At the conclusion of the registration process, the IDSP system automatically creates an account for the customer and allocates the storage space and other consumable resources for which the customer has registered, configures the database devices as necessary, and provides data for a costing model described in more detail in a later section. Once the customer has registered, the customer can obtain access to the registered services through a personal Web page presented to the customer's client process by the IDSP system.
In FIG. 5A, a customer of the service provider connects to a home page for the service provider. In step 510 the home page is presented to the customer with a selectable item, such as an icon, a button, or a menu item, for indicating that the customer wants to obtain database services from the service provider. If the customer selects the selectable item, then control passes to step 520 in which the customer is presented with a self registration page to obtain any information not already obtained from the service provider registration process. This registration page includes input items, such as forms and data entry fields, in which the customer may enter required profile information, required database resources information, and selectable data resources information.
After the customer has input information into the input items and chosen to submit the information to the registration process, a customer's inputs are validated in step 530. This validation may be performed on the IDSP platform itself, or may be performed on the customer's client process using routines downloaded to the customer's client process in a manner known in the art, such as with a Common Gateway Interface (CGI) script or a JAVA applet. The validation includes checks on the customer inputs, such as ensuring that every required field is filled. In step 535 the result of the validation is checked. If validation failed, control returns to step 520. If the customer inputs were found to be valid, control passes to step 540.
In step 540, the confirmation page is presented to the customer with an input item requesting payment information. The presentation provides an input item for payment by credit card and an input item for payment by purchase order. In step 545 it is determined whether payment is by credit card. If so, control passes to step 560 where a credit card payment server is contacted to validate that the credit card information provided in step 540 is correct, and the credit card accounts can accommodate the costs of the subscribed database resources. In step 565, it is determined whether the credit card payment server validated the credit card information. If so, control passes to step 570.
In step 570, the IDSP system configures the database devices to allocate the database resources, such as storage space, for which the customer subscribed. The IDSP system then sends a confirmation e-mail to the customer with a validation code, such as a password, and an address of a Web page for subsequently logging onto the IDSP system. The Web page address can be expressed in any way known in the art, such as with a Universal Resource Locator (URL) name. In step 575, the customer's home page is presented to the customer.
If, in step 545, payment is determined to be by purchase order, or in step 565, the credit card information was found to be invalid, control passes to step 550. In step 550, a human sales representative of the service provider contacts the customer. Procedures to use the purchase order or resolve the credit card problem are negotiated by the service provider sales representative and the customer. When these issues are resolved, then the service provider's sales representative returns control to step 570. The registration process is automatic and requires no human interaction except for step 550. Thus, if the customer provides valid credit card information, the entire self-registration process is accomplished without intervention by personnel of the service provider. This reduces the cost to the service provider of registering customers for the database services.
FIG. 5B is a diagram of components on a screen presented to a customer for receiving customer profile input during the self-registration process according to one embodiment of the disclosed techniques. This customer profile screen 522 includes a list of labels 523 indicating information to be input by the customer using the screen. Adjacent to each label 523 is input area 524 where a customer may enter alphabetical or numeric characters that represent the requested information. This screen can be customized by the service provider, for example, with a logo 525 of the service provider. Customization of presentations used throughout the self-service database provisioning process can be performed as a database service selectable by the database administrator while operating the EDSP provisioning process, described later. When the customer is finished putting the information requested into the customer profile screen 522, the customer activates the submit button 521. This screen 522 is an example of forms that can be presented on a customer's platform by a client process, such as a browser executing a CGI script or JAVA applet.
FIG. 5C is a diagram of components on a screen presented to a customer for receiving customer input concerning database service subscriptions during the self-registration process, according to one embodiment of the disclosed techniques. FIG. 5C shows a database services subscriptions screen 526 on which a customer indicates the database resources for which the customer wishes to subscribe. This screen includes a list of labels 527 indicating information the customer may input. Not all the information requested on this page is required. Required information is indicated separately in any way known in the art, such as by highlighting an area 531 of the screen 526. Some of the information requested on this screen relates to consumable database resources, for example, the information indicated by labels 527a through 527d. Other of the information requested on this screen 526 relates to database services to which the customer can subscribe, for example, the information indicated by labels 527e through 527k.
For consumable database resources the customer may enter an amount and a percentage in numeric input fields 528. The amount entered in the first column of numeric input fields 528 indicates a maximum value for the particular consumable database resource for which the customer is subscribing. The number entered in a field in the second column, under the words "alert at" must be less than 100. This number indicates a percentage of the maximum amount that is used as a threshold. When usage of the particular consumable database resource exceeds the threshold, then an alert is sent to the customer. If the customer does not enter a value for its threshold percentage, then the IDSP system will use a default threshold percentage, such as 75 percent (%). For example, with a 75% system default threshold percentage, a customer who has subscribed for 200 megabytes (MB) of storage will be alerted when the customer's databases consume more than 150 MB of storage. The alert is presented on the customer's database home page and a separate alert is sent in an electronic mail message to the mail address in the customer's profile. In another embodiment, the customer's pager is used to carry the alert.
For database services, the customer enters input using input items 529. These input items may be pull-down menus or may be buttons that launch dialog boxes to obtain further information from the customer. If all the database services available for subscription from the IDSP system cannot be listed on a single screen 526, then the additional database services can be listed in following screens. When the customer is finished with the screen and wishes to move to the next screen, the customer presses the continue button 534. If the screen 526 is the last screen or the only screen, when the customer is finished, the customer presses a submit button 534 in lieu of the continue button. Both buttons are represented in FIG. 5C by button 534.
The database services indicated by labels 527e through 527k, and following screens if necessary, are placed on the database services subscriptions screen 526 by the IDSP system based on the services installed by the database administrator, or other agent of the service provider. Installing a service here means installing the various applications directly on the IDSP platform or a database device connected to the IDSP platform, or installing the interfaces supporting the services.
The price a customer will pay for the database resources to which the customer has subscribed, will vary according to a costing model. The database services subscriptions screen 526 presents the customer with a selectable item, such as the "calculate price" button 533, for determining what the price will be. The computed price is displayed in area 532 of the database services screen 526 marked by the label 5271.
5.2 Self-service Maintenance of Registration
FIG. 5D is a flowchart showing steps in a process for registration self-maintenance according to an embodiment of the disclosed techniques. Starting at the customer's home page in step 575, the customer is presented with indications of system status of the database resources to which the customer has subscribed, i.e., the subscribed database resources. The customer is also presented with any alerts corresponding to the subscribed database resources. The customer is also presented with one or more selectable actions, for example, in a list of selectable actions.
Among the selectable actions is an item representing updating the customer's profile information. If this item is selected, control passes to step 580 in which the customer is prompted to provide edits that are used to update the customer's profile information. After the profile is updated, control passes back to step 575 to present the customer's home page.
Also among the selectable actions is an item representing updating the subscribed database resources. If this item is selected, control passes to step 590, which presents to the customer the database resources to which the customer has subscribed, including the maximum amount and threshold percentage for one or more consumable database resources. In step 592, the system receives changes to the subscribed resources from the customer. In response to these changes, the system updates the configuration allocating database resources to the customer. If necessary, the configuration of database devices, as virtual or dedicated and as a staging device or production device, are changed as well. While or after the subscribed resources are changed and the database devices are reconfigured, control returns to step 575 to present the customer's home page to the customer.
6.0 Web Site Building Wizard
According to one embodiment, one of the self-service processes allows a customer who has no programming expertise to build a web site with database components. This process is called a wizard because it prompts for customer inputs in a series of screens that are easy for the customer to respond to.
6.1 Dot Com Appliance
According to one embodiment, the database web site building wizard is not executed entirely within the IDSP platform, but is performed using a database web site building wizard appliance. This appliance is also called a DotCom appliance because the appliance makes it easy for an enterprise to generate a web site, and most enterprise web sites have URL addresses that include ".com."
FIG. 6A is a block diagram of a database web site building wizard appliance according to an embodiment of the disclosed techniques. The DotCom appliance 610 comprises hardware 616 and a special-purpose operating system 614. The appliance also includes a process 628 for generating the wizard interface and presenting it to an agent of the enterprise building the web site. The DotCom appliance need not be installed in an IDSP system 330, but can be plugged into any database appliance network. The DotCom appliance also includes components 624 used in such web sites, including database components. The DotCom appliance also includes templates 626, which are combinations of components 624 that are frequently used in broad categories of web sites. The broad categories of web sites are associated with certain kinds of web site activity, such as those engaged in by corporate headquarters web sites, retailers web sites, and social center web sites. The special-purpose operating system 614 on the DotCom appliance 610 is tailored to the wizard interface process 628. The special-purpose operating system has features and a configuration that are dictated by the database web site wizard and supporting program components.
The DotCom appliance 610 in FIG. 6A also shows processes for an Internet database server 612 and a site building process 622. The wizard interface process 628 converts inputs received from the agent of the enterprise into commands that (1) use the database server to create the database and (2) use the site builder process to build a web site based on the database.
In an alternative embodiment, the Internet database server process 612 and a site building process 622 are not included in the DotCom appliance but reside on other devices. In the alternative embodiment, the DotCom appliance is networked with an Internet database server appliance and a site builder appliance. Then, when the wizard interface process 628 issues commands for the Internet database server or site builder, those commands become requests communicated over the network. Such requests are responded to by an Internet database appliance and site builder appliance, respectively.
In another alternative embodiment, the site builder process and Internet database server process are on a single appliance, which may be called a database site builder appliance.
In the preferred embodiment, the IDSP system includes a DotCom appliance for building a database web site when the customer selects the database web site building wizard among the self-service data provisioning tools. In an alternative embodiment, this wizard is implemented as a process on the IDSP platform itself.
6.2 Overview of Web Site Building Wizard
FIG. 6B is a flowchart including steps performed by a database web site building wizard according to one embodiment. The process begins in step 575 in which the customer's current home page is presented the customer. If the customer is just beginning the process of creating its web site, then the home page presented at this point in the process may have minimal content. Other features on the home page, such as system status, alerts and a list of selectable actions, support other self-service functions as described in other sections. One of the selectable actions is to launch the web site building wizard.
In response to the customer selecting the database web site building wizard, control passes to step 630 which sends a request to the wizard interface process 628 which, as explained previously, may reside on a DotCom appliance. In step 632, the wizard presents, to the customer, selectable items representing selectable templates. Each template corresponds to a category of web sites. For example, one template corresponds to corporate headquarters web sites. Another template corresponds to another category of web site, such as a retailer web site. Templates are described in more detail later.
In step 640, the wizard presents to the customer a series of screens requesting additional inputs. The template and the additional inputs are used by the wizard to determine how to construct a web site with database components and other components associated with the template. The web site components that are assembled into templates are described in more detail later.
At any time of the customer's choosing, the customer is presented, in step 650, with a preview of a selected component or Web page for the web site, showing the effect of any customer inputs into the series of screens.
In step 652, the customer is given the option to save the current arrangement of the web site as a new customer site template. If the customer chooses to save the template, the template is saved in step 654 and control passes to step 656. If the customer chooses not to save the template, then control passes directly to step 656.
In step 656, the customer is given the choice to finalize the web site. If the customer feels the web site is not correct, and does not want to approve the web site in its current room, the customer chooses "No" and control passes to step 658. In step 658, the wizard accepts additional customer inputs to edit, move or modify components from the current arrangement of the web site. At any point of the user's choosing, control passes back to step 650 to preview the web site and its components.
If, in step 656, the customer feels the web site is correct, control passes to step 660. In step 660, a database is created to support the components on the web site. This is done using the Internet database server which may be on a different appliance altogether. In step 670, the web site is built based on contents of the database. This is done with a site builder which may be on another different appliance. Control returns to step 575 in which the customer's home page is presented the customer.
6.3 Customization of the Web Site Building Wizard
Before describing web site components and templates in more detail below, a process is described which allows the DotCom appliance owner to customize the presentations made to the user of the wizard, e.g., a web site designer. FIG. 6C is a flowchart of a customization process for a provider of the database web site building wizard according to an embodiment of the disclosed techniques.
In step 680, a screen is presented to the service provider that includes the selectable actions. The screen is presented as part of the IDSP provisioning process in the embodiment in which the DotCom appliance is part of the IDSP system. In an alternative embodiment, the screen is presented to the appliance owner as a separate customization process. In step 682, in response to selecting the option to customize the DotCom appliance, the process accepts the appliance owner's inputs of graphics to display on the screens of the web site building wizard. In step 684, the customization process presents the appliance owner options affecting the look of web site building wizard, such as the color and fonts on the wizard screens. In one embodiment these customized aspects of the wizard are stores in the templates for the wizard.
In step 686, the customization process accepts the appliance owner's inputs describing the web site components to add to the list of selectable components. In step 687, the customization process accepts the appliance owner's inputs describing new categories of web sites and the associated templates with unique combinations of web site components. These new templates are stored and added to the list of templates a web designer may select when operating the wizard.
In step 689, the customization process allows the appliance owner to associate the look of the wizard screens and the available templates with particular customers who may select the wizard. After step 689, the customization process ends, and the database web site building wizard option is ready to be selected and operated by a customer.
6.4 Web Site Components
Web site components handle specific functional needs of an enterprise operating a web site on the Internet. A web site component that uses the support of a database is called a database component. Information that is fixed and unchanging for all visitors to a site can be handled by components that are not database components. Examples of such components are a site logo, a site name, a legal notice, terms of use, and a privacy statement. Information for the web site that may be updated over time, or information that changes among visitors, usually requires a supporting database and is thus considered a database component. Examples of web site database components include a product or service description, a product/service price, a list of products/services, a component for searching for a product/service among the list of products, a hierarchical list of products/services within categories and subcategories, a component for searching products/services falling within a category or subcategory, support contact information, personnel lists, an item to search a personnel list, a map of the web site, links to related web sites, a calendar of appointments/events, a banner advertisement and a shopping cart. The above list is not comprehensive, or intended to be, as one who visits numerous web sites can attest.
In a preferred embodiment, all the components of the web site are stored in a database and a web page for the site is generated from the information stored in the database when a browser requests the page. This arrangement allows even relatively static information such as a corporate logo to be easily modified in one location in the database and subsequently displayed in its modified form on pages generated thereafter.
The web site building wizard appliance stores a large number of such components so that a novice user does not have to reinvent them. The components can be represented in any manner known in the art. In one embodiment, each component is described by an extensible markup language (XML) document. XML uses user-definable tags to mark sections of text and other resources. Resources that are not text may be identified within an XML document by text that designates their address, such as their URL address. The XML tags are used to define one or more database objects, such as tables, queries, procedures, or indexes, that together comprise a web site database component.
The web site building wizard allows the user to customize and expand the functionality of the predefined components. Using XML, each component is described using defined tags and parameter values. The tags for a particular set of XML documents, such as templates for a site, are defined in a document type definition (DTD) document or file. An XML stylesheet is used to generate code for an HTML document from the XML data, and the resulting HTML document is sent to the user's browser for presentation as a web page to the user. The designer user of the wizard can select a component to include in the web site or modify a component by changing the parameter values or both. More detail on how this is accomplished in an example embodiment is described in a later section.
6.5 Web Site Templates
As indicated above, the web site components can be combined in a huge number of permutations. Only some permutations present the web site components in an orderly way easily understood by a visitor to the web site. Many person-months, even person-years, of experience have gone into developing some of the more successful web sites on the Internet. Few small to medium-size enterprises can afford the expense of duplicating that experience. Thus, the database web site building wizard disclosed here prearranges these large number of web site components into one or more templates.
Each template stores a combination of web site components in an arrangement that is especially appropriate for a given category of activity on the Internet. In one embodiment, the template is constructed in the XML language in a site-template XML file and references the XML documents describing individual components. In one embodiment, the XML statements describing the individual components are copied into the site-template XML file. The reference may take the form of an anchor with a link giving the network address where the XML file for the component is to be found.
Using XML to represent components and templates allows the wizard to easily store the templates, to easily allow the customer to move the components around by changing their description and position in the XML file, and to easily store a description of the web site, including any edits made by the customer. The XML statements are understood by some browsers and are translated using stylesheets to the hypertext markup language (HTML) statements understood by all browsers for presentation to the customer.
According to one embodiment, the wizard represents the customer's web site using an XML file (the "customer site XML file"). When the customer initially selects a template, the components defined in the XML associated with the template are added to the customer site XML file. As the user goes from screen to screen in the wizard, the user specifies changes, deletions or additions to the components in the site. In response to the user input entered through these screens, the wizard changes, deletes or adds XML content in the customer site XML file.
When the customer has completed the wizard process, the wizard uses the customer site XML file to automatically generate the objects and code required to implement the customer site. According to one embodiment, statements within the customer site XML file are used with a translator to convert the statements to commands understood by a database server, as in step 660, described above. The database server responds to the commands by building a database to support those components. A web site is then built with the web site builder based on that database, as in step 670, described above. In one embodiment, the commercial product WebDB of the ORACLE.TM. Corporation is used to both store components and pages in a database and to dynamically generate a page of the web site based on information in the database in response to a visitor request for that page. More detail on how this is accomplished in an example embodiment is described in a later section.
6.5.1 Example Retailer Web Site Template
An example retailer web site template contains the following hierarchy of folders, each folder containing the listed components. A page of the web site includes one or more folders.
1. Site logo and site name.
2. A customizable menu containing a list of services offered.
3. A search window with a text box and a "Go" button.
4. Categories and subcategories of products/services.
5. A product/service description including:
logo
Picture/multimedia
text
Price
reviews from other buyers
button to add product to shopping cart
text box to input visitor review
text box to input e-mail address to direct a copy of the description
6. Shopping cart.
7. Payment server.
8. Text box describing how to order products/service found on the site.
9. A map of the site.
13. A menu for online help.
11. A description of discounts for best buys.
12. A dialog box to input visitor's preferences/interests.
13. Banner advertisement.
6.5.2 Example Corporate Headquarters Web Site Template
An example corporate web site template contains the following hierarchy of folders, each folder containing the listed components. A page of the web site includes one or more folders.
1. Site logo and site name.
2. Site map.
3. Categories of products/services:
products/services:
list of products/services by category
detailed information on individual product/service
news and press releases about products/services
selectable item to search within category
buttons to download free files of products
support
details of support portfolios
technical documents for download
support contact information
selectable item to search within support
4. Customer successes.
top/recent success stories
selectable item to search within success stories
5. Partners/alliances
list of services for partners
detailed information on individual service for partners
dialog box to allow visitor to register as partner
news and press releases about partner/alliance services
selectable item to search within partner/alliance services
6. Developer's forum
information about the developers forum
Chat service
bulletin board
link to Internet magazine for technology updates
visitor e-mail address input item for technology updates
dialog box when role into the forum
7. About the company.
corporate news/annual reports
investor information
publications
biographies of directors/officers
8. News from the company.
public relations contacts
press releases
9. Events involving the company
details of upcoming events
dialog box to register for event
10. Free downloads
description of free software
selectable item indicating software to download and nearest server
11. Online store
components from retailers web site template
12. Employment opportunities
description of position open
dialog box to apply for open position
13. Feedback
form where visitor inputs comments
14. Description of current marketing push
15. Description of current hot topics
16. Recent announcements.
17. A search window with a text box and a "Go" button.
18. A menu for online help.
19. Legal notice and terms of use.
20. Privacy statements.
6.5.3 Example Social Center Web Site Template
An example social center web site template contains the following hierarchy of folders, each folder containing the listed components. A page of the web site includes one or more folders.
1. Site logo and site name.
2. A dialog box for the visitor to sign up to join the social center.
3. Input menus to customize content for future visits to the site.
news categories
top stories
global news
local news
business news
technology news
sports news
travel news
health news
entertainment news
weather
stock quotes
movie schedule
top movies of the week
television show schedule
maps and directions
4. Input menus to customize layouts for future visits to the site.
5. E-mail.
6. Calendar.
7. Address Book.
8. Voicemail facility.
9. Messaging/paging facility.
10. Chat facility.
11. Directory services.
12. Search window to search the Web--input text box and go button/link to search engine.
13. Members grouped by area of interest category.
14. Services provided by area of interest category.
15. Banner advertisement for category chosen.
16. Search window to search the site by area of interest category.
17. News/information specific to area of interest category.
18. Mechanism to edit the content of news stories.
19. Mechanism to customize the location of weather information.
20. Mechanism to customize stock price information.
21. Mechanism to customize the latest scores reported in the sports section.
22. Horoscope and mechanism to customize horoscope sign.
23. Mechanism to build and host personal web site.
24. Section for running classified advertisements.
25. Online shopping categories:
apparel
books
music and video
electronics
health and beauty
26. Banner advertisement.
27. Menu for online help.
6.6 Example XML Components and Template
Table 1A shows several statements of a document type definition (DTD) file defining XML elements used to describe web site components according to an embodiment.
TABLE IA
DTD statements defining XML elements used
to describe web site components
State-
ment
Number DTD Statement
1 <!ELEMENT dca-component (name title layout
description service* custom?)>
2 <!ELEMENT name (#PCDATA)*>
3 <!ELEMENT title (#PCDATA)*>
4 <!ELEMENT layout (#PCDATA)*>
5 <!ELEMENT description (#PCDATA)*>
6 <!ELEMENT service (type url method authuser authpass)*>
7 <!ELEMENT type (#PCDATA)>
8 <!ELEMENT url (#PCDATA)>
9 <!ELEMENT method (#PCDATA)>
10 <!ELEMENT authuser (#PCDATA)*>
11 <!ELEMENT authpass (#PCDATA)*>
12 <!ELEMENT custom (input+)>
13 <!ELEMENT input EMPTY>
14 <!ATTLIST input type ENUMERATED
(text.vertline.checkbox.vertline.radio.vertline.reset.vertline.submit)
#REQUIRED>
15 <!ATTLIST input name CDATA #REQUIRED>
16 <!ATTLIST input value CDATA #REQUIRED>
17 <!ATTLIST input label CDATA #REQUIRED>
18 <!ATTLIST input checked
ENUMERATED(CHECKED.vertline.UNCHECKED)
#IMPLIED>
The DTD statements included in Table 1A define characteristics of elements used to define web site components in XML. As indicated by the statement in line 1 of Table 1A, each component is described using a "dca-component" element that is required to have elements called "name" "title" "layout" and "description" in which such information is placed, as described in more detail below. Lines 2 through 5 indicate that these elements include any amount of parsed character data as indicated by "#PCDATA". The dca-component element may optionally include as many "service" elements as needed, as indicated by the "*." The dca-component may also include zero or one "custom" elements, as indicated by the "?" symbol.
The DTD statement in line 6 indicates that the service element allowed in a dca-component element requires child elements called "type" "url" "method" "authuser" and "authpass" in which additional information is placed, as described in more detail below. Lines 7 through 11 indicate that these elements include parsed character data and that some character data must be included in the "type", "url" and "method" elements. As described below, these elements in the service element are used to define each service provided for a web page component. For each service, the type of user who may request the service is specified in the "type" element, the URL of the procedure that performs the service is specified in the "url" element, and the HTML form method to pass information from the user to the procedure is specified in the "method" element. These elements must include character data to specify this information. The next two elements, "authuser" and "authpass" optionally include data to specify authorized users and authorized user passwords, respectively.
The DTD statement in line 12 indicates that the custom element allowed in a dca-component element requires at least one child element called "input" in which additional information is placed, as described in more detail below. As described below, the custom element is used to define adjustable properties of a component that can be customized by a web designer. Since not every component can be customized, this element is not required by the dca-component element. If present, it is present only once. The actual properties that can be adjusted, and the way that the adjustment information is input by the web site designer, are described by the input elements included in the custom element. The "+" symbol indicates that at least one input element is required if the custom element is used.
The DTD statement in line 13 indicates that the input element in a custom element is empty, i.e., contains no other elements. The information held in the input element is held in the attributes list. One input element is included for each property of a web component that a web designer can adjust. Lines 14 through 18 list the attributes of each input element. As described below in more detail, these attributes describe the way a user inputs each adjustable property of a component. For each input, the type input is specified in the "type" attribute listed in line 14. Line 14 indicates that the type attribute holds character data as indicated by "CDATA," and that the type attribute is required when using the input element. Line 14 also indicates that allowed values for the type attribute are the enumerated values "text," "checkbox," "radio," "reset," and "submit." These correspond to the types of input fields on an HTML form. The input type attribute is used to determine the input field type on an HTML form employed to allow the web designer to specify the adjustable property of the component.
Line 15 indicates that the "name" attribute of the input element is also required and is specified using character data. As explained in more detail below, this attribute provides the name of the adjustable property whose value is to be determined by the web designer. Line 16 indicates that the "value" attribute of the input element is also required and is specified using character data. As explained in more detail below, this attribute provides the value for the adjustable property whose value is to be determined by the web designer. Because the attribute is required, a default value must be included when the element is used before the input is received from the web designer. Line 17 indicates that the "label" attribute of the input element is also required and is specified using character data. As explained in more detail below, the label holds a description of the adjustable property so the web designer can determine whether to change the default value.
Line 18 indicates that the "checked" attribute of the input element is not required and is specified, when present, using one of the two enumerated strings "CHECKED" and "UNCHECKED." As explained in more detail below, this attribute is used when the type of input is a radio button and one of the buttons is initially checked b before receiving input from the web designer.
Table 1B shows several statements of a document type definition (DTD) file defining XML elements used to describe an arrangement of components on the one or more pages of the web site.
TABLE 1B
DTD statements defining XML elements used to arrange
components (items) into pages (folders) for a web site
State-
ment
Number DTD Statement
1 <!ELEMENT site-template (name base category
style? site-map)>
2 <!ELEMENT style(name font* color* navbar)>
3 <!ELEMENT site-map(folders)>
4 <!ELEMENT folders (name title description
banner folders* item* )>
5 <!ELEMENT item (type name category display output-folder
arguments? )>
6 <!ELEMENT arguments(argv+)>
7 <!ELEMENT argv (#PCDATA)*>
8 <!ATTLIST argv pos CDATA #REQUIRED>
9 <!ELEMENT name (#PCDATA)*>
10 <!ELEMENT base (#PCDATA)*>
11 <!ELEMENT category (#PCDATA)*>
12 <!ELEMENT navbar (#PCDATA)*>
13 <!ELEMENT title (#PCDATA)*>
14 <!ELEMENT description (#PCDATA)*>
15 <!ELEMENT banner (#PCDATA)*>
16 <!ELEMENT type (#PCDATA)*>
17 <!ELEMENT display (#PCDATA)*>
18 <!ELEMENT output-folder (#PCDATA)*>
As indicated by the statement in line 1 of Table 1B, each web site is described using a "site-template" element that is required to have one each of elements called "name" "base" and "category" in which such information is placed, as described in more detail below. Lines 9 through 11 indicate that these elements include any amount of parsed character data. When used by the site-template element, the category element describes the category of web site activities described by the template, such as a Corporate category, a Retailer category and a Social Center category, as described above. The category and name element are also used by other elements for holding other content, as described below. The site-template element also includes a "style" element defined in line 2 of Table 1B and a "site-map" element defined in line 3.
The DTD statement in line 2 indicates that the style element allowed in a site-template element requires one each of child elements called "name" described above and "navbar" in which additional information is placed. Lines 9 and 12 indicate these elements include any amount of parsed character data. Line 2 also indicates the style element allows for optional one or more elements called "font" and "color" that are used to define fonts and colors of text in an HTML document derived from the XML document being defined, as described below. The DTD statements further defining the attributes of the font and color elements are omitted from Table 1B to keep the table small and this description simple. The attributes are evident from the example described below.
The DTD statement in line 3 indicates that the site-map element required in a site-template element requires a child element called "folders." As described below, this element describes the home page.
The DTD statement in line 4 indicates that each folders element includes required elements named "name", "title", "description", and "banner" that may include parsed character data to describe the page, as indicated in lines 9, 13, 14, and 15 of Table 1B, respectively. The use of these elements is described in more detail in the example described below.
The DTD statement in line 4 also indicates that each folders element may include additional folders elements to describe child pages that are launched from the current page. Thus, the folders element may be used to describe a hierarchy of folders corresponding to a hierarchy of pages for the web site. The folders element included in the site-map element, e.g., the home page, is the root of the hierarchy.
The DTD statement in line 4 also indicates that each folders element may include item elements corresponding to components on the web page corresponding to the folders element. The DTD statement in line 5 indicates that each item element requires one each of elements named "type", "name", "category", "display", and "output-folder" to provide such information. These elements may include parsed character data as indicated by lines 16, 9, 11, 17 and 18 of Table 1B, respectively. The use of these elements is described in the example described below. In the example, the "name" element of the item element is used to hold the name of the component used in the component XML document, so that the information provided in the XML document describing the web site can be related to the information in the XML document describing the individual component.
The DTD statement in line 5 also indicates that each item element may have one "arguments" element. An arguments element is included in an item element if the corresponding web site component has adjustable properties. As indicated by the DTD statement in line 6 of Table 1B, an arguments element includes one or more "argv" elements used to hold the values for the arguments that specify the adjustable properties of the component for the current page of the web site being designed. As indicated by the DTD statement in line 7, the argv element holds parsed character data that indicates the value to use for a particular adjustable property. As indicated by the DTD statement in line 8, the argv element has a required attribute called "pos" that holds character data. As explained in the example described below, the pos attribute is used to indicate the position of the argument in the call to the procedure that adjusts the properties of the component.
Table 2 shows several lines of XML code describing a discussionforum component for a web site, according to this embodiment, using the tags defined in the DTD statements listed in Table 1A.
TABLE 2
XML file describing a discussion
forum component for a web site.
Line
Number XML Statements
1 <dca-component>
2 <name>discussionforum</name>
3 <title>Discussionforum</title>
4 <layout>discforum_cust.xsl</layout>
5 <description>Read and post messages</description>
6 <service>
7 <type>RUN</type>
8 <url>dca.dca_forum_main.forumQueryPage</url>
9 <method>GET</method>
10 <authuser></authuser>
11 <authpass></authpass>
12 </service>
13 <service>
14 <type>ADMIN</type>
15 <url>dca.dca_forum_main.forumAdminPage</url>
16 <method>GET</method>
17 <authuser></authuser>
18 <authpass></authpass>
19 </service>
20 <custom>
21 <input type="text"
22 name="p_no_of_items"
23 value="5"
24 label="No of items to be displayed
(Enter a number greater than 0 or
enter ALL to view all items)"
25 />
26 <input type="radio"
27 name="p_sort_order"
28 value="createdate"
29 label="Sort by creation date"
30 checked="CHECKED"
31 />
XML file defining XML elements
used to describe web site components.
32 <input type="radio"
33 name="p_sort_order"
34 value="noofthreadst"
35 label="Sort by number of threads"
36 />
37 <input type="radio"
38 name="p_sort_order"
39 value="postdate"
40 label="Sort by last response date"
41 />
42 <input type="submit"
43 name="p_submit"
44 value=" OK "
45 />
46 <input type="reset"
47 name="p_reset"
48 value=" Reset "
49 />
50 </custom>
51 </dca-component>
Not shown in Table 2 are the conventional XML statements that identify a start and an end of particular document as an XML document and specify a file name for an external DTD file associated with the document.
The XML <dca-component> tag in line 1 of Table 2 opens the XML element describing the component; and the </dca-component> tag in line 51 closes this XML element. As described in the DTD of Table 1A, a dca-component element contains a name element, a title element, a layout element, a description element, one or more service elements, and at most one custom element.
In line 2 of Table 2, the name element is included; and the open and close name tags, "<name>" and "</name>," indicate the name for this component is "discussionforum." This name is useful to uniquely identify this kind of component. In line 3 of Table 2, the title element is included; and the open and close tags, "<title>" and "</title>," indicate the title for this component is "Discussionforum." This title is useful for inserting into a web page when information about this component is presented to a web designer in the designer's browser. In line 5 of Table 2, the description element is included; and the open and close tags, "<description>" and "</description>," indicate that this component is used on a web site to "Read and post messages." This description is useful for helping a web designer determine whether to include this component in the web site being designed.
In line 4 of Table 2, the layout element is included; and the open and close tags, "<layout>" and "</layout>," indicate that presentations for the discussionforum component is based on an extensible stylesheet language (XSL) stored in a file having a relative URL address of "discforum_cust.xsl." Since no domain name or directory information is indicated in the URL, the file is located in the same directory as the XML file including the statements of Table 2. Some contents of the stylesheet in this XSL file, and the manner in which those contents are used, are described later with respect to Table 4.
In lines 6 through 12 of Table 2, a service element is included involving the open and close tags, "<service>" and "</service>." As indicated by the DTD shown in Table 1A, a service element includes a service type element, a URL element, a method element, an authorized user element, and a password element. In line 7, the service type element is included; and the open and close tags, "<type>" and "</type>," indicate that this service is of type "RUN" for using at runtime, e.g., after the web site has been built with this component and when the component is called upon by a visitor to the web site.
In line 8, the URL element is included; and the open and close tags, "<url>" and "</url>," indicate that the URL of the procedure that performs the service is "dca.dca_forum_main.forumQueryPage." In this embodiment, a URL of this form indicates an ORACLE.TM. PL/SQL procedure "forumQueryPage" in a package named "dca_forum_main" in a package named "dca" in the same directory as the document having the XML code of Table 2. PL/SQL is an extension to structured query language (SQL) that is proprietary to the ORACLE.TM. Corporation. In the PL/SQL system a package is a collection of procedures that can be called externally; thus the package provides an application program interface (API). In other embodiments the procedure associated with a service can reside on another location on the network. In yet other embodiments, the procedure is not within a PL/SQL package but is any program that can be launched in response to input from a user at a browser. Such programs include a JavaScript script that is downloaded by a browser and executed on the client's machine, and a server side operating system script, and a JAVA servlet of a web server process, and a stand alone server side application.
In line 9, the method element is included; and the open and close tags, "<method>" and "</method>," indicate that the method is "GET." The method element refers to the method for submitting user input on an HTML form to the procedure that provides the service. The two methods currently available on HTML forms are GET and POST. Line 8 indicates that the discussionforum component expects to receive user input using the GET method. According to the GET method, data indicating user input on the HTML form is appended to the URL identifying the procedure and the extended URL is sent to the web server. The web server places this data indicating user input into an environmental variable called "QUERY_STRING" that can be accessed by the procedure.
In line 10, the authorized user element is included; and the open and close tags, "<authuser>" and "</authuser>," indicate that no authorized user is identified for this service of the component. This is expected because the authorized user depends upon the designer who uses the wizard to build the web site. Similarly, in line 11, the authorized user password element is included; and the open and close tags, "<authpass>" and "</authpass>," indicate that no authorized user password is identified for this service.
In lines 13 through 19 of Table 2, a second service element is included involving the open and close tags, "<service>" and "</service>." In line 14, the service type element is included; and the open and close tags, "<type>" and "</type>," indicate that this service is of type "ADMIN" for using by web site administrator, to maintain or re-configure the discussion forum.
In line 15, the URL element is included; and the open and close tags, "<url>" and "</url>," indicate that the URL of the procedure that performs the service is "dca.dca_forum_main.forumAdminPage." In this embodiment, as described above, this URL indicates a PL/SQL procedure "forumAdminPage" in a package named "dca_forum_main" in a package named "dca" in the same directory as the document having the XML code of Table 2. In other embodiments, the package is not in the same directory or the procedure is not within a PL/SQL package but is any program that can be launched in response to input from a user at a browser. This package provides controls that a web page administrator can use to configure and maintain the discussionforum.
In line 16, the method element is included; and the open and close tags, "<method>" and "</method>," indicate that the method is "GET." In line 17, the authorized user element is included; and the open and close tags, "<authuser>" and "</authuser>," indicate that no authorized user is identified for this service of the component. Similarly, in line 18, the authorized user password element is included; and the open and close tags, "<authpass>" and "</authpass>," indicate that no authorized user password is identified for this service.
In lines 20 through 50 of Table 2, a custom element is included for the discussionforum component. The custom element involves the open and close tags, "<custom>" and "</custom>," and the intervening elements. As indicated by the DTD shown in Table 1A, a custom element includes one or more input elements. The input elements have attributes but can contain no other elements. The input elements describe the way a designer of the web site inputs information on HTML forms to customize the particular component, in this case the discussionforum component. Each property corresponding to an input elements is used by at least one of the services associated with the component.
In lines 21 through 25, a first input element is included for the discussionforum component. Attribute "type" is set equal to a value of "text" indicating the first input element is a text input box. In line 22, attribute "name" is set to a value of "p no of items" and provides a unique name for the input element. In line 23, attribute "value" is set to "5" to provide a default entry in the text box of "5." In line 24, attribute "label" contains text that describes what information the web designer should type into the text box. As indicated by the value of "label," this text box is used to input the "[number] of items to be displayed." Further, the value of the "label" attribute instructs the visitor to "(Enter a number greater than 0 or enter ALL to view all items)." This input element is useful for allowing a web designer to determine how much of a discussion occurring in the discussionforum to view at one time. By virtue of its appearance within the custom element, at least one of the attributes of this input element can be modified by the web site designer, for example to display a different number of items.
In lines 26 through 41, three more input elements are included for the discussionforum component. These three input elements are useful for building three radio buttons belonging to a set named "p_sort_order" on an HTML form. A web site designer may select only one radio button of a set in an HTML form. Attribute "type" is set equal to a value of "radio" and attribute "name" is set to "p_sort-order" for all three elements corresponding to the set (lines 26 and 27, 32 and 33, and 37 and 38, respectively). The input element corresponding to the first radio button has an attribute "label" set to a value of "Sort by creation date" in line 29; the input element corresponding to the second radio button has an attribute "label" set to a value of "Sort by number of threads" in line 35; and, the input element corresponding to the third radio button has an attribute "label" set to a value of "Sort by last response date" in line 40. The attribute called "value" is set to "createdate" in line 28, to "noofthreads" in line 34, and to "postdate" in line 39, for the three elements, respectively, indicating the value to assign to the set if the designer activates the corresponding radio button. In addition, the input element corresponding to the first radio button has an attribute "checked" set to a value of "CHECKED." These input elements hold information that allows an HTML form to be constructed with three radio buttons of which the button corresponding to sorting by creation date is checked initially. By virtue of their appearance within the custom element, at least one of the attributes of each of these input elements can be modified by the web site designer, for example by setting the "checked" attribute of the first radio button input element to "UNCHECKED" and setting the "checked" attribute of a different element to "CHECKED."
In lines 42 through 49, two more input elements are included for the discussionforum component. These two input elements are useful for building a submit button and a reset button on an HTML form. When a visitor to a web site selects a submit button on an HTML form, the information on the form is sent from the browser using the GET or POST method specified when the form is built. When a visitor selects a reset button on the HTML form, the values of the input fields in the form are cleared. By virtue of their appearance within the custom element, these two input elements are presented to the web site designer for indicating when the designer is finished changing the values of the adjustable proerpties.
Table 3 shows several lines in a template XML document describing a template for a simple, example social center web site including a news component and a discussion group component.
TABLE 3
Statements in a template XML document.
Line
Number XML Statements
1 <site-template id="1">
2 <name>Community</name>
3 <base>localhost</base>
4 <category>community</category>
5 <style>
6 <name>DEFAULT</name>
7 <font type="HEADING" size="3" style="BOLD">Arial</font>
8 <font type="SUBHEADING" size="2" style=
"PLAIN">Arial</font>
9 <font type="DESCRIPTION" size="2" style=
"PLAIN">Arial</font>
10 <font type="LINK"size="2"style="BOLD">Arial</font>
11 <font type="CONTACT"size="2"style="PLAIN">Arial</font>
12 <color type="BACKGROUND">_FFFFFF<color>
13 <color type="HEADINGBACKGROUND">#CCCCFF
</color>
14 <color type="HEADINGTEXT">#FFFFFF</color>
15 <color type="SUBHEADINGBACKGROUND">#CCCCCC
</color>
16 <color type="SUBHEADINGTEXT">#FFFFFF</color>
17 <color type="LINK">#0000FF</color>
18 <color type="VISITEDLINK">#FF0000</color>
19 <color type="CONTACT">#000000</color>
20 <color type="DESCRIPTION">#000000</color>
21 <navbar>FRAME</navbar>
22 </style>
23 <site-map>
24 <folders>
25 <name>root</name>
26 <title>Site Home Page</title>
27 <description></description>
28 <banner>NONE</banner>
29 <item>
30 <type>CUSTOM</type>
31 <name>news</name>
32 <category>REGULAR</category>
33 <display>INPLACE</display>
34 <output-folder></output-folder>
35 <arguments>
36 <argv pos="1 ">dca</argv>
37 <argv pos="2">us</argv>
38 <argv pos="3">5</argv>
39 <argv pos="4">public</argv>
40 <argv pos="5">Y</argv>
41 <argv pos="6">Y</argv>
42 </arguments>
43 </item>
44 <item>
45 <type>CUSTOM</type>
46 <name>discussionforum</name>
47 <category>REGULAR</category>
48 <display>INPLACE</display>
49 <output-folder></output-folder>
50 <arguments>
51 <argv pos="1">dca</argv>
52 <argv pos="2">us</argv>
53 <argv pos="3">createdate</argv>
54 <argv pos="4">5</argv>
55 </arguments>
56 </item>
57 <folders>
58 <name>admin</name>
59 <title>Manage Components</title>
60 <description>Administration of
Components</description>
61 <banner>NONE</banner>
62 </folders>
63 <folders>
64 <name>news</name>
65 <title>News Page</title>
66 <description></description>
67 <banner>NONE</banner>
68 </folders>
69 <folders>
70 <name>discussionforum</name>
71 <title>Discussionforum Page</title>
72 <description></description>
73 <banner>NONE</banner>
74 <item>
75 <type>CUSTOM</type>
76 <name>discussionforumlong</name>
77 <category>REGULAR</category>
78 <display>INPLACE</display>
79 <output-folder></output-folder>
80 <arguments>
81 <argv pos="1">dca</argv>
82 <argv pos="2">us</argv>
83 <argv pos="3">createdate</argv>
84 <argv pos="4">ALL</argv>
85 </arguments>
86 </item>
87 </folders>
88 </folders>
89 </site-map>
90 </site-template>
In this embodiment, these statements are in a file named "Community.xml". Note that "community" in this context is a category of social activities performed with a web site and is different from the Community Server for one or more database providers described above. The XML <site-template> tag in line 1 of Table 3 opens the XML element describing a template; and the </site-template> tag in line 90 closes this XML element. As described in the DTD of Table 1B, a site-template element contains a name element, a base element, a category element, a style element, a site-map element, and a folders element. The web designer may modify the contents of the community.xml file, as described in later section, using a series of wizard screens to produce a customer site XML file.
In line 2 of Table 3, the name element is included; and the open and close name tags, "<name>" and "</name>," indicate the name for this site-template is "Community." This name is useful to uniquely identify this kind of template. In line 4 of Table 3, the category element is included; and the open and close tags, "<category>" and "</category>," indicate that this template corresponds to the "community" category of web site activities. When a web site designer modifies the site-template to produce the customer site XML file, the designer may replace either the name or category associated with the modified template, or both. For example, the designer may leave the category "community" after modifying the site-template but place the text "MyOwnKindOfCSocialCenter" into the name element of the site-template element.
In line 3 of Table 3, the base element is included; and the open and close tags, "<base>" and "</base>," indicate the base network node from which relative addresses are defined for resources included on the web site. The text "localhost" indicates that resources for the community web site are addressed relative to the local host address. During design, the local host may be one platform, while during run time the web site and resources might be moved to a different platform, which becomes the new local host. That change is accomplished simply by replacing the address associated with the text "localhost."
In lines 5 through 22 of Table 3, a style element is included for the community template. The style element involves the open and close tags, "<style>" and "</style>," and the intervening elements. As indicated by the DTD shown in Table 1, a style element includes a name element, zero or more font elements, zero or more color elements, and a navbar element. These elements are useful for presenting a template to a web designer with the specified fonts and colors and navigation bar. To assist the web site designer, the community template includes data for font and background color and for font type for a variety of HTML tags such as heading, subheading, description, and link. This particular style element is named "DEFAULT" in line 6. The web site designer may modify the data associated with these elements contained in the style element and give a different name, such as "MyOwnFonts," to the style element having the modified data in the modified template that constitutes the customer site XML file.
In lines 23 through 89 a site-map element is included in the community web site template. The site-map element involves the open and close tags, "<site-map>" on line 23 and "</site-map>" on line 89, respectively, and the intervening elements. As indicated by the DTD shown in Table 1, a site-map element includes a folders element; and a folders element includes a name element, a title element, a description element, a banner element, zero or more item elements and zero or more other folders elements. Thus there may be a hierarchy of folders elements within folders elements. The first folders element in the site map element is the root folder for the web site. Each web page of a web site is conveniently represented by a folders element in the site map. The components on a page are conveniently represented by the item elements. A web page associated with a particular folders element that has a child folders element includes a link to the web page associated with the child folders element.
In lines 24 through 88 of the community web site template in Table 3, a single folders element is included in the site-map element. The folders element involves the open and close tags, "<folders>" on line 24 and "</folders>" on line 88, and the intervening elements. This is the folders element for the web page from which branch all the other web pages on the site, if any. This is the root folders element that represents the home page of the web site being designed. In the original template shown in Table 3, this folders element has a name "root" in a name element on line 25, a title "Site Home Page" in a title element on line 26. The description element on line 27 has no initial value, but can be modified by the web designer to include a description in the customer site XML file. The initial community template also has no banner advertisement graphic, as indicated by the text "NONE" in the banner element on line 28. The banner element may be modified by the web site designer to include in the modified template in the customer site XML file a reference to a graphic the fills a banner advertisement location on the web page.
The home page folders element of the Community template of Table 3 includes two item elements and three folders elements representing two components and three links, respectively, on the home page HTML document that is generated from this template, as described in the next section. As indicated by the DTD shown in Table 1B, an item element includes a type element, a name element, a category element, a display element, an output-folder element, and an arguments element. The item element is useful for identifying and customizing the web site component that is intended for the page corresponding to the folders element within which the item element resides.
In lines 29 through 43 the first item element is included in the folders element corresponding to the home page. The first item element involves the open and close tags, "<item>" on line 29 and "</item>" on line 43, respectively, and the intervening elements. This first item element indicates that a news component is intended for the home page by virtue of the "news" text contained in the name element on line 31. This component is customizable by the web site designer as indicated by the "CUSTOM" content of the type element in line 30. In line 32 of Table 3, the item category element is included; and the open and close tags, "<category>" and "</category>," indicate the category is "REGULAR." This category element is used to group components when they are inserted into the web page by the web site building routine, such as by WebDB. By placing this component in a "REGULAR" category it is treated the same way as other components in the that category. This category may be used to distinguish components that are supported by procedures that execute on a DotCom appliance from components that are supported by procedures that execute on another or remote platform. In line 33 of Table 3, the item display element is included; and the open and close tags, "<display>" and "</display>," indicate the display of the news component is "INPLACE," which means that the web page displays the actual component rather then including simply a link to a resource that displays the component if the link is selected. In line 34 of Table 3, the item output-folder element is included; and the open and close tags, "<output-folder>" and "</output-folder>," enclose no data identifying an output folder. The output-folder element may be modified by the web site designer to include a name of a directory and a file where any output generated by the component, such as a message pulled from a discussion group, may be stored temporarily. This is especially useful when the component is provided by an external resource such as a remote database that places results from a query in a file on the remote system.
In lines 35 through 42 the arguments element is included in the first item element corresponding to the news component. The arguments element involves the open and close tags, "<arguments>" on line 35 and "</arguments>" on line 42, respectively, and the intervening elements. As indicated by the DTD shown in Table 1B, an arguments element includes one or more argument value elements; and, an argument value element includes a required position attribute "pos" and contains only text data, i.e., no other elements. The argument value elements are useful for setting the customizable parameters of a particular component on the web page being designed and for passing arguments to procedures called to provide the functionality behind a web site component. The news component has six customizable parameters or arguments passed to one or more underlying procedures. In lines 36 through 41, values for these six parameters or arguments are provided in six argument value elements. Each line contains one argument value element including the opening and closing tags, "<argv>" and "</argv>", respectively, and the data to pass as an argument. Each open tag specifies the position of the argument that is to pass the provided data to the procedure by assigning a value in the range 1 through 6 to the "pos" attribute. |