【正文】 application service provider. An Active Server Page (ASP) is an HTML page that includes one or more scripts (small embedded programs) that are processed on a Microsoft Web server before the page is sent to the user. An ASP is somewhat similar to a serverside include or a mon gateway interface (CGI) application in that all involve programs that run on the server, usually tailoring a page for the user. Typically, the script in the Web page at the server uses input received as the result of the user39。s request for the page to access data from a database and then builds or customizes the page on the fly before sending it to the requestor. ASP is a feature of the Microsoft Inter Information Server (IIS), but, since the serverside script is just building a regular HTML page, it can be delivered to almost any browser. You can create an ASP file by including a script written in VBScript or JavaScript in an HTML file or by using ActiveX Data Objects (ADO) program statements in the HTML file. You name the HTML file with the .asp file suffix. Microsoft remends the use of the serverside ASP rather than a clientside script, where there is actually a choice, because the serverside script will result in an easily displayable HTML page. Clientside scripts (for example, with JavaScript) may not work as intended on older browsers. For Web service applications, Microsoft provides a new version of ASP support called . 4. Browser/Server is a trademark for the new paradigm of corporate puting that is now possible using technology developed for the World Wide Web. At the present time the Web is used by the many corporations to distribute marketing materials. The corporate Web Server is usually just a Brochure Server for the Marketing department. The potential exists for using Web Browsers and Severs for much more, especially behind the corporate firewall. Browser/Server technology can be used to enhance most corporate puting systems, not just the system used for marketing. To understand the important new role that Browser/Server technology can play within a pany it is useful to examine the previous paradigms that have paved the way for Browser/Server puting. Computers were first used in Batch mode. End users had little interaction with the corporate puting systems. Inputs would be gathered in a batch and keyed into punch cards, which were fed by operators into the mainframe puter when the puter was done running previous batch jobs. When the mainframe processed the job it usually produced printed output which eventually made its way to the end user. The batch process included no user interaction, and the only recourse a user had after discovering errors in the batch run was to go through the cycle, which often took hours or even days, again and again. The addition of dumb terminals to the mainframe gave the users direct, handson, connections to the corporate puter. Users no longer had to wait for a puter operator to run their jobs, they could enter the data and initiate processing themselves. There were still delays involved. Dumb terminals were useful for inputting and displaying information, but because they had no processing ability it was necessary for the user to interact with the mainframe in order to interact with their data. Batch jobs previously could be run onebyone if necessary, but mainframes had to deal with all attached terminals seemingly at once. This lead to delays as users waited for the mainframe to turn around their terminal messages while they interacted with their data. Still, the delays were now down to seconds or minutes, instead of hours or days. Client/Server puting has brought about a whole new standard of corporate puting productivity, but at the same time it has introduced many new problems for corporate IT anizations. The advent of lowcost desktop puters makes Client/Server possible. No longer is it necessary for users to wait even seconds to interact with their corporate data. With their own puter on their desktop they do not need to wait for the mainframe to respond. All of this cheap puter power has also made it possible to support putation intensive graphical interfaces, which are much easier for users to understand. In order for Client/Server to work, the application program which used to reside entirely on the mainframe has been split into two pieces, the client piece and the server piece. The portion of the application that resides in the Client personal puter includes logic for the presentation of information to the user and mechanisms for accepting user input. It also includes logic for data interaction at the Client, such as changing the appearance of the graphical interface as the user make various choices. The Client software often includes corporate business rules that allow data to be validated before it is sent to the server. The portion of the application that remains on the Server is usually just the portion that stores data at a central location, accessible to other users. The once mighty mainframes have been reduced to database servers, while the rest of the application has migrated out to the clients. This migration has caused many problems. The Client machines have bee fat. As the plexity of applications has risen it has bee necessary to supply users with more and more powerful puters with faster processors, more disk storage, and more RAM. It is true that personal puter manufacturers have been able to deliver better and better puters for the same amount of money, but the constant upgrades required are costly for corporations. It takes more people and time to upgrade hundreds or thousands of personal puters than it used to take to just upgrade the mainframes. Setting aside the cost of Client equipment, the proliferation of corporate applications, including busines