Chapter 4:
Building Fast Web Apps Fast with Caché Server Pages

“Building fast Web apps fast” uses the word fast two times. That’s because it is possible to build sophisticated database-oriented Web applications with CSP more rapidly than with traditional approaches, and also because the built-in Caché database is the world’s fastest, capable of running systems with tens of thousands of simultaneous users.

There are many ways to write Web applications with Caché – including all of the traditional ways that use SQL to access the database. In this chapter we’re going to discuss another, more direct approach called Caché Server Pages (CSP).

CSP is a technology that is provided as part of the Caché Application Server. It is the fastest way for Caché applications to interact with the Web, providing:

• An advanced object-oriented development approach.

• Ultra-high performance and scalability at run time.

CSP supports HTML, XML, and other Web-oriented mark-up languages.

CSP is not a Web design tool, although it can be used with them. While Web design tools often concentrate solely on the production of static HTML, CSP goes beyond the appearance of pages to aid in the development of application logic. It also provides the run-time environment that enables rapid execution of code within the Caché Application Server.

CSP supports a strong procedural programming environment, so applications can be written with a level of sophistication and exactness that exceeds that possible with pure application generation technologies. It also supports rapid development through its class architecture, which produces “building blocks” of code that can be combined, and through the use of wizards, which can quickly produce simple versions of customizable code. The result is the ability to quickly develop very sophisticated Web applications.

The Caché Advantage Object-oriented procedural programming plus Caché Wizards result in rapid development of sophisticated browser based database applications.

Some of the characteristics of Caché Server Pages are:

• Dynamic Server Pages – Because pages are created dynamically on the application server by application code, rather than having a Web server simply return static HTML, applications can respond rapidly to a variety of different requests and tailor the resulting pages that get sent back to the browser.

• Session Model – All of the processing related to pages from a single browser are considered part of a session – from the first browser request until either the application is completed or a programmable timeout occurs.

• Server State Preservation – Within a session, application data on the server – and even the entire application context – can be automatically retained across browser requests, making it much easier to develop and run complex applications.

• Object Architecture – Because every page corresponds to a class, code and other characteristics common to many pages they can be easily incorporated through inheritance. Data is also typically referenced through objects with all of the benefits of object-oriented programming.

• XML – Caché fully embraces XML, both as a powerful alternative to HTML for building Web pages and as a universal format for moving data between applications and systems.

• Caché Application Tags for Automatic Generation of Server Application Code – These extended HTML tags are as easy to use as traditional HTML tags. When added to an HTML document, they generate sophisticated application code providing a variety of functionality, such as opening objects, running queries, and controlling program flow. These tags are extensible – developers can create their own to suit their specific needs.

• Integration with Popular Web Design Tools – CSP works with a variety of tools that make it easy to visually lay out a page. With Dreamweaver, CSP goes a step farther with the ability to add Caché Application Tags through simple point-and-click interaction. CSP also includes a Wizard that makes it easy to create forms that display or edit data in a Caché database.

• Server Methods Callable from the Browser – To facilitate development of more dynamic interactive applications, CSP makes it easy to invoke server-side methods. When an event occurs in the browser – typically because the user took some action – application code on the server can be invoked and a response to the event generated, all without the overhead of transmitting and displaying a whole new page.

• Encryption – Caché automatically encrypts data in the URL, to help authenticate requests and prevent tampering. The encryption key is kept only on the server, and it is only good for the life of the single session.

That’s a lot of technology – but it does not have to be hard to use. We’ve focused on making CSP simple to use, with most of these capabilities working automatically for you. Our philosophy is power through simplicity – the complexity should be in our implementation, not in your programming.

The Caché Server Page Model

Traditional Web Technologies

With traditional Web technology, a request is sent to the Web server, and the Web server retrieves a sequential file of HTML that it sends back to the browser. When applications involve variable data, development gets more complicated, with programmers typically using CGI (with languages such as Perl or tcl) on the Web server and sending SQL queries and stored procedure requests to the database. As a programming environment, this leaves much to be desired, and execution – particularly with a large number of users – can be quite inefficient as the Web server gets heavily overloaded.

With CGI, each browser request typically creates a new process. To avoid this overhead, program-mers sometimes link application code directly to the Web server, with the unfortunate side-effect that an error in such code can crash the entire Web server.

Dynamic Server Pages

CSP uses a different programming and execution approach: Dynamic Server Page Technology. Content (HTML, XML, style sheets, images, and other types) is generated programmatically at run time on the Caché Application Server, rather than coming from sequential files, allowing much greater flexibility in responding to page requests.

Most of the application code executes on the Caché Application Server, which may or may not be on the same computer as the Web server. Some code – typically JavaScript or Java – may run on the browser, usually to support operations such as data validation, reformatting, or invoking server-side code.

With this approach, processes don’t have to be created for each browser request (as they do with the traditional CGI approach), boosting performance. And since the application code isn’t linked to the Web server, an application error cannot crash the Web server.

Sessions – The Processing Model

All of the processing related to pages from a single browser are considered part of a session – from the first browser request until either the application is completed or a programmable timeout occurs. When the Web server receives a page request (URL) with the file extension “.csp”, that request is sent (by a thin layer of Caché code attached to the Web server) to the appropriate Caché Application Server, which may be on a different computer.

When the Caché Application Server receives the request, it determines whether a session is already in progress for that browser. If not, one is started automatically. Caché then executes application code associated with that particular page – performing the actions requested by the user and programmatically creating HTML, XML, image, or other content that is sent back to the browser.

A session ends when a property is set in the Session object terminating the session. Applications that run stateless may elect to terminate the session on each page.

State Preservation One of the challenges facing developers is the inherently stateless nature of the Web – there’s usually no simple way to retain information on the server from one request to the next. Applications typically send all of the state information they need to retain out to the browser in URLs or hidden form fields. That’s not an effective technique for more complex applications, which may resort to saving data temporarily in files or databases. Unfortunately this imposes significant overhead on the server, and it makes programming considerably more difficult.

Caché’s Session model enables Caché to automatically and efficiently preserve data between calls from a browser. CSP provides a Session object that contains general session information plus properties that enable the programmer to control various session characteristics. The application can store its own data in the Session object, which is automatically retained from one request to the next.

The application determines how much state to preserve by setting the Preserve property of the Session object to 0 or 1. (The default is 0, and it can be dynamically modified at run time.)

• 0 – Data stored in the Session object is retained. (Data is simply set into a multidimensional property that accepts data of any type and allows any number of subscripts – including string valued subscripts – without any declarations.)

• 1 – Caché dedicates a process to the session so that all of the state of the process is retained, including all variables (not just those in the Session object), I/O devices, and locks.

A setting of 0 allows a logical partitioning of all preserved data and permits multiple sessions to share a single process, but it preserves less state. A setting of 1 is easier for the programmer and provides a wider range of capabilities, at a cost of increased server resources.

The Request Object
CSP automatically provides several objects in addition to the Session object to help the program-mer process the page. One of these is the Request object. When a page is received, the URL is decoded and its contents are placed into the request object. The request object contains all name/ value pairs and any form data along with other useful information. For example, the value of the name “FilmID” could be obtained by the code:

Class Architecture of Web Pages

For each Web page, there is a corresponding page class that contains methods (code) to generate the page contents. When a request is received, its URL is used to identify the corresponding page class, and the “Page()” method of that class is called. Usually page classes are derived from a standard Web page class “%CSP.Page” that provides every page with various built-in capabilities, such as the generation of headers and encryption. Those standard capabilities can be overridden through a variety of means – deriving from another superclass, using multiple inheritance, or simply overriding specific methods.

This class architecture makes it easy to change behavior for an entire application and to enforce a common style. It also brings all of the other programming advantages of object programming to Web development.

The page class contains code to perform the requested action and generate and send a response to the browser, but not all of the application code that is executed is in that page class. In fact, most of the executed code is typically in methods of various database classes and perhaps addi-tional business logic classes. Thus the development process consists of developing both page classes and database classes (plus perhaps additional business logic classes).

In general, we recommend that page classes contain only user interface logic. Business logic and database logic should be put into different classes, so that there is a clean separation of user interface code from the business and database logic, and it is easier to add additional user inter-faces later.

Multiple Development Strategies
A page class is created for each Web page and contains the code to be executed for that page. There are two ways to build page classes, and most applications use both of them:

• CSP File – An HTML file with embedded Caché Application Tags is written using a simple text editor or Web design tool. That sequential file (a “CSP File”) is not sent directly to the browser – it is compiled to generate a page class.

• Direct Programming – Programmers write the entire page class by coding the appropriate methods.

Simple pages are often quicker to develop with CSP files and wizards, but it may be easier to directly program more complex pages.

CSP Files

CSP Files are sequential HTML files with embedded Caché Application Tags that are compiled into page classes – the same sort of page classes that a programmer might write directly. Those page classes are then compiled to generate code that runs on the Caché Application Server in response to browser requests.

Caché Studio includes a Form Wizard that automatically generates a CSP file to edit or view a database class. The user simply clicks on the database class of interest and then clicks on the set of properties to be displayed. The Caché wizard does the rest – adding HTML and Caché Application Tags to the page. Since the wizard outputs HTML, if the result is not exactly what you want, it is easy to edit it.

The CSP File approach is powerful because:

• Web artists can design the visual layout while programmers concentrate on the code.

• Much of the user interface can be programmed non-procedurally in a visual environment and kept isolated from the business and database logic.

• It is often easier to customize an application for a particular user by allowing non - programmers to modify the visual presentation and add simple capabilities.

Since the visual specifications of the application are kept separate from most of the programming logic, it is relatively easy to change the appearance without reprogramming. Simply edit the HTML or XML file and recompile the page.

Although a complete simple application can be created this way, more commonly a programmer supplies additional code. This additional code is provided though application tags that either include the procedural code or invoke code in other classes. However, complex pages with a lot of proce-dural code are often easier to write using the direct programming approach rather than a CSP file.

Caché also includes an add-in for Dreamweaver, the popular Web page design tool. It provides point-and-click support for adding Caché Application Tags as well as a Caché Form Wizard that automatically generates the code needed to view or edit a database object.

Caché Application Tags
Caché Application Tags can be added to CSP Files. They are used just like standard HTML tags, but they are really instructions to the Caché Web Compiler to generate application code that provides a variety of functionality – such as accessing database objects, running queries, program flow control, and executing code on the Caché Application Server. Caché Application Tags are extensible – developers can create their own to suit their specific needs.

Caché Application Tags are not embedded in HTML that is sent to a browser – they are only in the CSP file read by the Caché Web Compiler. That compiler automatically transforms them into standard HTML, which can be processed by any browser.

Hyper-events

CSP hyper-events allow events occurring on a browser (such as mouse clicks, field value changes, or timeouts) to invoke server-side methods and to update the current page without repainting it. After taking the appropriate action, that server method can return code – typically JavaScript – for execution by the browser. Using hyper-events, Web applications can become more interactive and responsive.

Within a CSP page, a server-side method is invoked simply with the syntax “#server(...)#”. For example, suppose that when the user clicks on a shopping cart image we want to call a server method called AddToCart(). Then the HTML definition for the image might include:

onClick=”#server(..AddToCart())#”

The Web compiler will replace this syntax with JavaScript code that, when run on the browser, will invoke the Caché server method.

HTML or XML?

HTML is the traditional “language” of the Web, and it is one of the most widely known program-ming languages in the world. This makes HTML a natural choice for many.

An increasingly popular alternate to HTML is using XML. Caché is particularly well suited to XML since Caché can automatically produce XML documents. XML supports an object structure and maps well to an object representation of data.

With XML, instead of sending a complete description of the page to the browser, just the data is sent to the browser in a structured form. The browser is also instructed to use a particular “Style Sheet” for that page that contains a description of what to do with that data. Once the browser has that style sheet, it can remember it and use it again later if the page (or another page with the same style sheet) uses it.

XML is particularly effective for transaction-based applications that repetitively use the same pages with different data. Only the data needs to be transmitted to the browser, not an entire HTML description. Another attraction of XML is that it provides a clean separation between the data contents (encoded in XML) and the behavior to display and edit it (encoded in the Style Sheets).

CSP works the same way with XML as it does with HTML. Instead of the programmer supplying HTML in the Page() method, XML is provided. That XML is easily derived from the database classes by running the XML Wizard in Studio – simply specify the names of the properties to be included and the wizard generates a method to provide the XML document.

With XML the programmer also has to provide a Style Sheet. That could either be provided as a separate page class whose Page() method simply writes the Style Sheet to the browser, or, more commonly, it is a simple sequential file that is transmitted to the browser by the Web server like any other file.

World Headquarters
InterSystems Corporation
One Memorial Drive
Cambridge, MA 02142
USA

Phone: 1.617.621.0600
Fax: 1.617.494.1631

InterSystems.com

InterSystems Caché is a trademark of InterSystems Corporation. Other product names are trademarks of their respective vendors.
Copyright © 2003 InterSystems Corporation. All rights reserved.

Caché Technology Guide