Patent Application
20050010577
The systems and methods described herein relate to Web servers and, more particularly, to generating Web content such as Web pages.
There are two approaches to Web application development. One approach, represented by Active Server Pages (ASPs), emphasizes rapid development over performance and is focused on HTML developers. Another approach, represented by Internet Service Application Programming Interface (ISAPI), is targeted to a more sophisticated application developer using system languages such as C and C++. ISAPI emphasizes performance, but development is typically slower. ASP is a Web server technology from Microsoft Corporation of Redmond, Washington. ISAPI is a programming interface on Internet Information Server (IIS), a Web server available from Microsoft Corporation.
The use of high performance application interfaces, such as ISAPI, to create applications typically require the use of the same interface to create associated user interfaces. Using a high performance application interface to create user interfaces is problematic because user interface developers are generally familiar with simpler declarative languages, such as HTML. Development of applications and/or user interface elements are more difficult using, for example, ISAPI. Since user interface elements are typically updated more frequently than the applications themselves, it is not desirable to use a high performance application interface to implement these frequent updates.
Accordingly, it is desirable to provide an architecture that separates development of applications from development of user interfaces.
The systems and methods described herein are used to develop Web-based applications. In one embodiment, a process receives a request for a Web page and identifies an Active Server Page associated with the requested Web page. The Active Server Page includes a compiled user interface template. The Active Server Page is executed to generate the requested Web page. The requested Web page is then provided to a source of the request.
Similar reference numbers are used throughout the figures to reference like components and/or features.
The systems and methods discussed herein use a template system to separate the business logic (e.g., the applications) from the presentation (e.g., the user interface) for developing Web-based applications. The template system is also referred to as Active Server Pages for Hotmail (ASPH). A file format contains a language table, one file index per language and structures the files as multiple code sections. The code sections contain the instructions to display the user interface elements based on the ASPH instruction set. An ASPH compiler converts the user interface templates into an ASPH file. Developers use a language, such as ASPL (Active Server Page Language), to create user interface templates, which the ASPH compiler converts into ASPH files. These ASPH files are executed by the runtime system when the application calls the high performance user interface. Execution of an ASPH file generates an appropriate Web page in, for example, HTML, XML, or WML format. Thus, using the systems and methods discussed herein, the user interface developers can program using a declarative language while the system takes advantage of the more powerful interfaces available for application development.
Although particular examples discussed herein relate to Hotmail, the systems and methods described herein can be used with any email system or any other application, such as other Web-based applications. Additionally, specific examples described herein refer to the ISAPI interface. However, alternate embodiments may utilize any high performance application interface.
Certain examples discussed herein refer to Active Server Pages (ASPs). In one embodiment, an ASP is a Web page that contains HTML as well as embedded programming code. When a Web server receives a request for an ASP page, the Web server executes the embedded programming code. As used herein, a “Web page” may contain any amount of content or information. A “Web page” may be a portion of a larger page or larger collection of information.
User interface templates defined by ASPL file 102 include, for example, an email inbox page, a personalized home page, a new message page, and an old message page.
The ASPH compiler translates the data in the ASPL files into ASPH byte codes and generates a single ASPH file (typically named “i.asph”). The compiler maintains symbol tables and file tables to maintain a mapping of names to indices and to finally put this information into the header and body of the ASPH file. During a setup phase, the compiler loads the file table and the symbol table with the variables which are known at compile time. A header file (typically defined using the C programming language) specifies the list of files in which the ISAPI code is interested. The compiler extracts the ASPL file names from this header file and loads the file information into the file table. Additionally, the compiler loads the ISAPI variable information.
During a compile phase, the compiler compiles ASPL files for each language supported. During a link phase, the compiler links together the component files and generates the i.asph file with the appropriate file headers. A few examples of the compilation of ASPL code into ASPH byte codes are discussed below to illustrate the compilation process.
Set: A set is translated into one or more Load instructions. If the value that the variable is being set to is text, then only one Load instruction is generated. However, if the value is a concatenation of text and other variables, then a series of Load instructions are generated with appropriate arguments indicating how to concatenate the parts and finally load the resulting value into the destination variable.
Text: A stream of text (e.g., just text or HTML code) is translated into a text instruction with appropriate arguments. The compiler buffers text until it sees something that is not text. At that point, the compiler generates the text instruction. Although the compiler typically processes the file line-by-line, the compiler generates a single text instruction for a stream of text.
If/Else: This is translated into a combination of Compare-Jump or Expression-Jump instructions, depending on the type of expression being tested in the if condition. If the expression is a simple expression (e.g., not involving logical operators AND and OR), it will be translated into Compare-Jump. The Compare instruction tests the expression and the jump will take care of jumping to the right location on the Boolean value of the expression. If the expression is a compound expression, then the compiler will generate an expression tree, which is a type of binary tree. The compiler then generates the Expression instruction (followed by the arguments), one of which is an array of nodes in the expression tree.
The structure of an example i.asph file is illustrated below in Table 1. In this example, each field is four bytes, unless otherwise stated. The offsets are from the beginning of the i.asph file, unless otherwise stated.
WC (WebCourier) and SO (Special Offer) are some special types of variables which need a reverse lookup (i.e., name to internal variable index) that are used at Hotmail. In particular embodiments, a certain amount of reverse lookup is needed, such as when an external party needs to input values for internal variables through HTTP. In other embodiments, it may not be necessary to provide this reverse lookup functionality.
In one embodiment, user interface templates are created using ASPL (also referred to as ASPL pages). ASPL pages contain the HTML, XML, or WML code that renders the user interface along with the presentation logic. To generate dynamic Web pages, the ASPL pages contain ASPH code segments, which are executed at runtime to dynamically generate the resulting HTML code that is finally sent to the client requesting the Web page.
The HTML code is any valid HTML instructions—it is text from the ASPH compiler's perspective. The ASPH code is enclosed within the <% and %> delimiters. The constructs supported are similar the constructs in actual Microsoft ASPL code. The following is a list of some example constructs allowed in ASPH code.
ASPH uses indices instead of names so that each lookup is an array indexing. Since there are many classes of variables, the following types of indices are identified. The basic idea is that the ISAPI code can use these indices to set and get values for the specific variable. The ASPH compiler uses the indices table declared as enumerations in the C header files as data and derives the names out of them by removing the prefix. Thus, cAsphCabc is equivalent to the variable name “abc” to the ASPH compiler.
Where a particular variable is entirely internal to ASPL, there is no need for an explicit index that is exposed to the C code. These variables are assigned indices in the order in which they are encountered by the ASPH compiler. Where a given variable is used in the ASPL code before they are set, unless they are built-in or Site configuration variables (in which case they have a default value), the value is derived from the URL parameters.
The following table identifies various types of indices.
As discussed above, the execution engine, which is the ISAPI runtime code that deals with response page generation, executes a single ASPH file that contains, among other things, the byte code based instructions for the various ASPL files. The ASPL files are compiled by the ASPL compiler into byte codes, each of which is a byte long and is followed by zero or more arguments. The execution engine also offers several “registers.” For example, the program counter register tracks the offset of the next instruction. The file start register keeps track of the file start locations so that relative offsets can be used. A stack is used—the value from the program counter and file start are pushed into the stack and popped from the stack when files are included from other files. The CompareResult register stores the result of the most recent comparison operation. The definition of the flag bits are:
The various byte codes and their meanings are discussed in the table below.
The bits of each value are defined by the following table.
There are many special situations that are encountered by the ASPH system. These situations are generally dealt with by using built-in callbacks. These callbacks are described in the following sections. In addition to the callbacks below, internal built-in variables are dealt with using the switch statement. In ASPL, AsplInclude files such as hotmail.asp were printed before any ASPL file was printed once per each ISAPI in the ASPL constructor, whether needed or not. Also, these files contain a large number of set statements, some of which are for variables that are used in one or two places and others that are unused. So, in ASPH, these variables are classified as internal built-in, meaning, these variables derive their built-in default value from one of the Asplinclude files. So, hotmail.asp is compiled with a switch statement at the beginning. Based on which variable is being used in the ASPL page, if the variable is an internal built-in variable, the runtime executes the appropriate AsplInclude file, such as hotmail.asp after loading the index of the variable being loaded into cAsphBInternalBuiltInVariableToSwitchOn. The switch statement switches on this variable and in each case takes to the offset where the load statement for the variable whose default value is being looked up resides. The ASPL compiler inserts a quit after every load statement so that the file execution of hotmail.asp ends after the loading of the default value into the internal built in variable. Note that once loaded, the file doesn't have to be executed again for the same variable, as the value is loaded into the internal variable tables of the ASPH runtime.
The following table identifies multiple callbacks that can be used by the systems and methods described herein.
Computer environment 500 includes a general-purpose computing device in the form of a computer 502. The components of computer 502 can include, but are not limited to, one or more processors or processing units 504, a system memory 506, and a system bus 508 that couples various system components including the processor 504 to the system memory 506.
The system bus 508 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus also known as a Mezzanine bus.
Computer 502 typically includes a variety of computer readable media. Such media can be any available media that is accessible by computer 502 and includes both volatile and non-volatile media, removable and non-removable media.
The system memory 506 includes computer readable media in the form of volatile memory, such as random access memory (RAM) 510, and/or non-volatile memory, such as read only memory (ROM) 512. A basic input/output system (BIOS) 514, containing the basic routines that help to transfer information between elements within computer 502, such as during start-up, is stored in ROM 512. RAM 510 typically contains data and/or program modules that are immediately accessible to and/or presently operated on by the processing unit 504.
Computer 502 may also include other removable/non-removable, volatile/non-volatile computer storage media. By way of example,
The disk drives and their associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, program modules, and other data for computer 502. Although the example illustrates a hard disk 516, a removable magnetic disk 520, and a removable optical disk 524, it is to be appreciated that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes or other magnetic storage devices, flash memory cards, CD-ROM, digital versatile disks (DVD) or other optical storage, random access memories (RAM), read only memories (ROM), electrically erasable programmable read-only memory (EEPROM), and the like, can also be utilized to implement the example computing system and environment.
Any number of program modules can be stored on the hard disk 516, magnetic disk 520, optical disk 524, ROM 512, and/or RAM 510, including by way of example, an operating system 526, one or more application programs 528, other program modules 530, and program data 532. Each of such operating system 526, one or more application programs 528, other program modules 530, and program data 532 (or some combination thereof) may implement all or part of the resident components that support the distributed file system.
A user can enter commands and information into computer 502 via input devices such as a keyboard 534 and a pointing device 536 (e.g., a “mouse”). Other input devices 538 (not shown specifically) may include a microphone, joystick, game pad, satellite dish, serial port, scanner, and/or the like. These and other input devices are connected to the processing unit 504 via input/output interfaces 540 that are coupled to the system bus 508, but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (USB).
A monitor 542 or other type of display device can also be connected to the system bus 508 via an interface, such as a video adapter 544. In addition to the monitor 542, other output peripheral devices can include components such as speakers (not shown) and a printer 546 which can be connected to computer 502 via the input/output interfaces 540.
Computer 502 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computing device 548. By way of example, the remote computing device 548 can be a personal computer, portable computer, a server, a router, a network computer, a peer device or other common network node, game console, and the like. The remote computing device 548 is illustrated as a portable computer that can include many or all of the elements and features described herein relative to computer 502.
Logical connections between computer 502 and the remote computer 548 are depicted as a local area network (LAN) 550 and a general wide area network (WAN) 552. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.
When implemented in a LAN networking environment, the computer 502 is connected to a local network 550 via a network interface or adapter 554. When implemented in a WAN networking environment, the computer 502 typically includes a modem 556 or other means for establishing communications over the wide network 552. The modem 556, which can be internal or external to computer 502, can be connected to the system bus 508 via the input/output interfaces 540 or other appropriate mechanisms. It is to be appreciated that the illustrated network connections are exemplary and that other means of establishing communication link(s) between the computers 502 and 548 can be employed.
In a networked environment, such as that illustrated with computing environment 500, program modules depicted relative to the computer 502, or portions thereof, may be stored in a remote memory storage device. By way of example, remote application programs 558 reside on a memory device of remote computer 548. For purposes of illustration, application programs and other executable program components such as the operating system are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computing device 502, and are executed by the data processor(s) of the computer.
Various modules and techniques may be described herein in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
An implementation of these modules and techniques may be stored on or transmitted across some form of computer readable media. Computer readable media can be any available media that can be accessed by a computer. By way of example, and not limitation, computer readable media may comprise “computer storage media” and “communications media.”
“Computer storage media” includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer.
“Communication media” typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as carrier wave or other transport mechanism. Communication media also includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.
Although the description above uses language that is specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the invention.
