Caché Technology Guide

Chapter Four:
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 what is 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 can be easily incorporated through inheritance. Data is also typically referenced through objects with all of the benefits of object-oriented programming.
• XML – XML provides a powerful alternative to HTML for building Web pages. 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.
• 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 further 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, programmers 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 programmer 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:

%request.Data(”FilmID”,1)	// the 1 indicates we want the
	// 1st value for this name
	// in case multiple values are
	// present for this name

THE CACHÉ ADVANTAGE By automatically preserving state information on the server, there's less network traffic and less overhead on the server, as the application doesn't have to keep filing and accessing data on every page request. And programming the application is simpler. The use of Dynamic Server Pages and the Caché Application Server results in greater flexibility to respond to requests, faster execution without the risk of application errors bringing down the Web server, and a richer programming environment.

 

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 additional 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 interfaces 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 several ways to build page classes, and most applications use more than one:

• 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.

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 procedural 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.

---

InterSystems Corporation
World Headquarters
One Memorial Drive
Cambridge, MA 02142-1356

Tel: +1.617.621.0600
Fax: +1.617.494.1631

www.InterSystems.com

InterSystems Caché is a registered trademark of InterSystems Corporation. Other product names are trademarks of their respective vendors.
Copyright © 2006 InterSystems Corporation. All rights reserved. 07-06

Caché Technology Guide

Previous Page Chapter 3

Table of Contents

Next Page