Chapter 3: The Caché Application Server

The Caché Application Server is a layer of code that offers advanced object programming capabilities, provides sophisticated data caching, and integrates easy access to a variety of technologies. The Caché Application Server makes it possible to develop sophisticated database applications rapidly, operate them with high performance, and easily support them.

More specifically, the Caché Application Server provides:

1. Access to Caché Multidimensional Data Servers on the same and other computers.

2. Access to relational databases, although with lower performance than access to Caché Data Servers.

3. The Caché ObjectScript programming language.

4. Connectivity software with client side caching to permit rapid access to Caché Objects from a variety of technologies, including Java, C++, ActiveX, Visual Basic, Delphi, and CORBA. Caché automatically performs the networking, if any is required.

5. Connectivity software for SQL access using ODBC and JDBC to Caché’s database, including sophisticated caching at the client and application server layers for high performance and the ability to automatically combine data from several Caché Data Servers in a single query.

6. Caché Server Pages for high performance, easy-to-program Web applications.

7. Caché Object Architect, Caché Studio, and Visual Caché development tools to rapidly develop and debug applications with Caché.

8. Caching Caché ObjectScript code so that code does not have to be installed on more than one computer. Code changes automatically propagate to all application servers.

9. Caché automatically performs all networking, so application code can be insensitive to the location of data or even whether the data is on the same or a remote computer.

How the Caché Application Server Accesses the Caché Data Server

The Caché Application Server is closely integrated with the Caché Multidimensional Data Server.

The Caché Application and Data Servers may or may not be on the same computer. If they are on the same computer, each application process directly calls code in the Data Server to access the database using a shared disk buffer cache.

When the Application Server needs to access a remote Caché Data Server, Caché’s Distributed Cache Protocol (DCP) is used. DCP accesses the remote database and caches data on the application server so that future data requests often can be satisfied without using the network.

Caché Object Architect

Caché Object Classes are usually created, edited, and compiled using the Caché Object Architect. Using the Object Architect, developers can specify properties, code object methods, and define specialized data types.

If desired, the Object Architect can also be used to specify the data structure for storage (or Caché will pick one), and special SQL characteristics such as SQL triggers and query optimization information.

Importing/Exporting Data Models

In addition to using the Object Architect, there are several other ways to input and export class definitions to and from the Caché Data Dictionary.

Caché RoseLink allows classes defined using Rational Software’s Rose object modeling tool to be imported into Caché. Similarly, Caché class definitions can be exported to Rose for use within Rose’s modeling environment.

Caché can also create objects from relational DDL files. The resulting object classes will be very simple: their properties will be single-valued system-defined data types that correspond to the relational table’s fields, and their only methods will be those persistence methods required to move the data to and from the disk. However, even these simple classes are immediately available for use with object programming languages, and they may be used as building blocks to create more complex data models.

CDL is InterSystems’ Class Definition Language. A CDL file is a text file containing all the information needed to define a Caché Object class, and provides another way to transport class definitions from one application to another.

Caché Studio

Routines can also be edited and compiled using Caché Studio. Caché Studio is particularly useful during debugging and when editing code that was not created through the Object Architect.

The Caché Advantage

Rapid Application Development

The Caché Object Architect and Caché Studio are highly productive tools for creating Caché Objects and Caché ObjectScript routines. Support for object programming concepts promotes rapid development by allowing developers to model complex data in naturalistic ways.

Application Modeling Options

Caché allows developers to model their applications in whatever way makes the most sense to them. Multidimensional data structures can be created directly in Caché ObjectScript. Class definitions can be created using the Caché Object Architect or by importing from Rational’s Rose object modeling tool. Caché even accepts relational models in the form of DDL files.

Flexibility

Caché ObjectScript gives developers the flexibility of using any and all of Caché’s data access modes: Object, SQL, or Direct Global Access within the same application, the same routine, or even the same line of code. Developers can tailor the data access to fit the needs of the application.

Integrating Caché with Other Object Technologies

Using Caché Objects with Other Technologies

Caché supports a number of programming technologies for creating application logic and the user interface. The Caché Objects Servers render Caché object classes as ActiveX, Java, or C++ classes, depending upon which Object Server is used. Caché Objects can also be used with CORBA.

These object servers include both a layer of software on the client side, including caching for higher performance, and a layer in the Application Server. It is transparent to the programmer as to whether they are on the same or separate computers. Also, it is transparent to the client as to which Caché Data Server contains the data, or even if the object data is stored in a relational database accessed through the Caché Application Server.

Typically a client connects to only one Caché Application Server, and it is that Application Server’s responsibility to obtain the data from the correct Data Server.

ActiveX

The Caché Object server for ActiveX exposes Caché object classes as ActiveX classes for use with tools such as Visual Basic, Inprise’s Delphi, and any software compatible with the COM interface.

Java Support

The Caché ObjectServer for Java exposes Caché Object classes as Java Beans.

C++ Support

The Caché ObjectServer for C++ creates C++ renditions of Caché Object classes. Additionally, after Caché Object classes are defined and compiled, Object Definition Language (ODL) files can be generated, allowing population of the type library for a C++ application.

CORBA Support

Caché Objects can be accessed through CORBA and can access other CORBA compliant objects. The use of CORBA may not give the same level of performance as with other object technologies.

Visual Caché

Supplementing the Caché ObjectServer for ActiveX, Visual Caché provides a rapid development link between Caché Objects and Visual Basic. Visual Caché includes the Caché Object Link Control, which automates the linkage between a Caché class and the user interface controls used to display the class on a VB form. The Control supports the VB data control interface, so a data-aware control can be connected simply by specifying its Data Source (a Caché class) and Data Field (the Caché class attribute). The result: Anyone who knows Visual Basic can use it to create the user interface to an application that employs Caché Objects, even if they know nothing at all about object technology.

To make things even easier, Visual Caché also includes the Caché Form Wizard, which creates Visual Basic forms automatically. Developers simply identify the class and attributes they want to include and the Wizard generates a ready-to-run form that can be used as is, or customized with VB.

Visual Caché is typically used for simple applications. More complex VB applications are typically programmed using the object access capabilities of VB to access Caché Objects.

The Caché Advantage

Freedom of Choice

Caché allows programmers to use any development environment they choose for UI and business logic programming. Special features provide higher-productivity links to some of the most popular tools.

Through the Caché Objects servers and gateways, Caché-based applications can interact with other programs using ActiveX, Java, or C++ objects.

Visual Basic users can use Visual Caché’s Object Link Control and the Form Wizard to be instantly productive. InterSystems has also formed partnerships with other major tools vendors, making it easy to use Caché with tools such as Inprise’s Delphi, and Symantec’s Visual Café.

"We are very impressed with the new reservations system that Innsite [an InterSystems’ VAR] has delivered. To meet our criteria Innsite had to deliver a system that was as quick and simple to implement as it was to use – they did all this and more, all within the ten week period."

— Stephen Thirlwell

Brand Manager

Welcome Lodges

Web Connectivity (see also: Chapter 4)

For Web connectivity, Caché employs the concept of server pages, that is, pages are created and populated with data “on-the-fly” as they are requested by a browser. But unlike other Web architectures, Caché Server Pages execute on the Caché data server, close to the data they use. The connection to the Web server is made via fast standard API’s.

Caché Server Pages consist of standard HTML or XML, so they can be created and modified easily by using any off-the-shelf Web page creation tool or your favorite text editor. Functionality is added by incorporating Caché Application Tags (CATs) or Hyper-Events™.

Caché Application Tags

Caché Applications Tags (CATs) work like HTML tags, except instead of formatting text, they execute functions on the Caché data server and/or the browser. The Application Tags that come with Caché can be used to read and write to the database, perform calculations, looping, act as counters, manage multi-frame coordination, etc. Best of all, CATs are extendable. Developers can create their own to suit the specific needs of their applications.

Server-side Events

Server-side events allow events occurring on a browser (mouse clicks, mouse movements, field value changes, timeouts, etc.) to invoke server-side operations and to update the current page without repainting it. By including Hyper-Events, e-applications become much more interactive and responsive.

Simplified Session Management

One of the challenges facing e-developers is the inherently stateless nature of the Web. Developers generally have to do a great deal of system-level coding to take care of the session management issues that arise when applications need to maintain state between Web pages. Caché makes state management easy by providing special session management objects. All of the system-level code is encapsulated inside, completely transparent to developers. Session management objects work with both HTTP and HTTPS (for secure transactions). Caché also allows dedicated session processes for applications that require multipage database locks.

The Caché Advantage

Fast and Scalable e-Applications

Caché’s Web technology brings the superior performance and massive scalability of the Caché database to Intranets and the world’s largest network: the Internet. Caché Server Pages provide a high-performance connection between Caché’s post-relational database and a Web server, using standard interfaces. Caché Server Pages run on the Caché data server, and interact with the database via fast inter-process communications, so performance is improved. And scalability is enhanced because the Web server is no longer bogged down with lots of resource-intensive processing.

Rapid and Simplified Web Development

Developers can use any text editor or their favorite off-the-shelf Web page creation tools to create Caché Server pages. Caché Applications Tags promote code reuse and collaborative development – some developers will create the Caché Applications Tags needed by applications, and others will use those CATs to build sophisticated Web applications. Caché also reduces development time by simplifying session management.

“In the area of Web-based applications, there is absolutely no comparison between Caché and other database technologies we’ve used. Caché outperforms them all.”

— Uwe Wagner

Co-Founder

Schmidt & Wagner

“Caché is a well-designed product that should be given serious consideration by organizations building Web and business applications which have complex transaction processing requirements.”

— International Data Corporation

Caché ObjectScript

Caché ObjectScript is a powerful, object-oriented programming language designed for rapid development of database applications. Here are some of the key characteristics of the language.

Overall Structure

Caché ObjectScript is command oriented; hence it has syntax such as:

     set x=a+b
     do rotate(a,3)
     if x>3  

There is a set of built-in system functions, whose names all start with the single ‘$’ character to distinguish them from variable and array names, that are particularly powerful for text manipulation. They include functions such as:

      $extract(string,from,to) // get a set of characters from a string
      $length(string)          // determine the length of a string 

Expressions use left-to-right operator precedence, just like most hand-held calculators, except when parentheses alter the order of evaluation.

Calling Code

Code is often called using the DO command, e.g.,

     do rotate(a,3)

Code that returns a value can also be called as a function, e.g.,

     set x=a+$$insert(3,y) 

calls the programmer written subroutine ‘insert’.

Code can also be invoked as an object method, e.g.,

    set money=invoice.Total()  // Total() returns the invoice total amount 

or 

   do part.Increment()        // Increment() doesn’t return a value of any interest 

Both call by value and call by reference is supported for parameters.

Flexible Data Storage

One of the most unique characteristics of Caché ObjectScript is its highly flexible and dynamic data storage. Data may be stored in:

. object properties.

. variables.

. sparse, multidimensional arrays that permit any type of data for subscripts.

. database files (“globals”) which resemble sparse multidimensional arrays.

With rare exception, any place in the language where a variable can be used, an array, object property, or global reference could also be used.

In most computer languages datatypes are an extension of hardware storage concepts (integer, float, char, etc.). However, Caché ObjectScript has the philosophy that humans don’t think using such storage types, and that these “computer-centric” datatypes simply impede rapid application development. Requiring such declarations and dimension statements introduces far more errors than they help prevent (errors such as a 2-byte integer overflow, or when a string overflows its allocation of memory and corrupts other storage). However, object typing, such a Person, Invoice, Animal, Car, etc., is viewed as highly valuable and consistent with the way humans think.

Thus in Caché ObjectScript object properties are strongly typed, but the other three types of storage (variables, arrays, and global nodes) are fully polymorphic, typeless entities that need not be declared or defined. They simply pop into existence as they are used and mold themselves to the data needs of what they are storing and how they are being used in an expression. Even arrays do not need any specification of size or dimension or type of subscripts or data. For example, a developer might create an array called Person by simply setting:

     set Person(“Smith”,”John”)=”I’m a good person” 

In this example, data was stored in a two-dimensional array using string data for subscripts. Other data nodes in this array might have a different number of dimensions and might intermix strings, integers, or other types of data for subscripts. For example, one might store data in:

   abc(3)
   abc(3,-45.6,”Yes”) 
   abc(“Count”) 

all in the same array.

Direct Access to the Database

A direct reference to the database (a “global reference”) is essentially a multidimensional array reference preceded by the carat character ‘^’. That character indicates this is a reference to data stored in the database rather than to temporary process private data. Each such database array is called a “global”.

As with multidimensional arrays and variables, no declarations or definitions or reservations of storage are required to access or store data in the database; global data simply pops into existence as data is stored. For example, to store information in the database one might write:

    set ^Person(“Smith”,”John”)=”I’m a very good person” 

and later might retrieve it by code such as:

    set x=^Person(“Smith”,”John”) 

The programmer has complete flexibility in how to structure these global data arrays. Thus, invoice data might be stored as:

   ^Invoice(invoice #,”Customer”) = Customer information 
   ^Invoice(invoice #,”Date”) = Invoice date
   ^Invoice(invoice #,”Items”) = # of Items in the invoice
   ^Invoice(invoice #,”Items”,1,”Part”) = part number of 1st Item
   ^Invoice(invoice #,”Items”,1,”Quantity”) = quantity of 1st Item
   ^Invoice(invoice #,”Items”,2,”Part”) = part number of 2nd Item 

etc.

Object References

Caché Objects implement the ODMG data model, with powerful extensions.

In Caché ObjectScript an “oref” is used to access an object (an “oref” is typically a variable whose value specifies which in-memory object is being referenced). The “oref” is followed by a dot and then by the name of a property or method. Object references can be used wherever an expression can be used. E.g.:

   set name=person.Name     // ‘person’ is a variable whose value is an oref
                                         // the person’s name is put into the variable ‘name’
   if person.Age>x            // see if the person’s age is greater than ‘x’
   set money=invoice.Total()  // ‘Total()’ is a method that calculates the sum of
                                       // all of the invoice’s line items 

Methods can also be executed with a DO command when no return value is needed. E.g.:

    do part.Increment()        // ‘Increment()’ is a method whose return value,
                           // if any, is not of interest 

The “oref” is not the same as a database object id. The object id is a value that is permanently associated with a database object; it is used to retrieve and store a database object. Once an object is in memory, it is assigned, as are all objects in memory, a reusable oref value that is then used to access the object’s data. The next time that same database object is brought into memory it will probably be assigned a different oref value.

Different Ways to Access the Database

Caché Objects that are persistent generate code that can store and retrieve themselves from the database as a series of one or more global nodes. They also automatically put a description of themselves in the SQL data dictionary, so that SQL access is also permitted. The query language for Caché Objects is Caché SQL, an object enhanced SQL.

Thus there are three ways to access the integrated database:

. Object Database syntax.

. Caché SQL, including ODBC and JDBC access for commonly used tools.

. Direct global reference access of multidimensional arrays.

HTML and SQL Access

HTML for Web applications and SQL can be embedded in Caché ObjectScript code.

Routines

In some object languages, all code has to be part of some method. Caché ObjectScript doesn’t have that restriction. Some code is invoked through methods, and other code is invoked as subroutines.

Caché ObjectScript code is organized into a set of “routines”. Each routine (typically up to 32kb in size) is atomic in the sense that it can be independently edited, stored, compiled, and executed. Routines are linked dynamically at runtime; there is no separate linking step for the programmer. Routine code is stored in the database; thus, routines can be dynamically paged across the network rather than having to be installed on each computer.

Within a routine, code is organized as a set of subroutines. To call a subroutine, the subroutine name should have the routine name appended to it. For example,

   do admit^pat3()    ; call the subroutine ‘admit’ which is in the routine ‘pat3’ 

When calling code that is within the same routine, only the subroutine name is needed.

   do discharge()     ; call the subroutine ‘discharge’ which is in the same                   ; routine 

If the subroutine returns a value that is of interest, the subroutine should be invoked through the “$$” function syntax. For example:

 Set x=$$admit^pat3()   ; the subroutine ‘admit’ is in the routine ‘pat3’
 Set y=$$discharge()    ; the subroutine ‘discharge’ is in the same routine 

Routines can be edited and compiled through the Caché Studio.

Objects are defined, and their methods edited, through the Caché Object Architect (although they can also be imported and exported though CDL). These definitions and method code are stored in global data files, and the Class Compiler uses these definitions to produce a set of routines. For instance, the compilation of the Patient class might produce a set of routines named ooPatientR1, ooPatientR2, etc., which include all of the Patient method code. Methods are simply subroutines in those routines, and the system knows how to dispatch a method call to the appropriate subroutine in the appropriate routine.

In addition to the runtime version of a routine, there is usually a source code version. The utilities use suffixes to distinguish between the object code and source code versions: a) .MAC refers to the macro source code, b) .INT indicates the intermediate source code after execution of the macro preprocessor, and c) .OBJ is the runtime compiled version. If a developer writes a routine called “Admit”, the macro source would be in Admit.Mac, which gets compiled by the macro preprocess to Admit.Int which has all of the macros replaced, and finally Admit.Obj which is the runtime code. Suffixes are only used by utilities, not by program code; you would never program a subroutine call as “do sub^routine.obj”.

Scalable Performance in Distributed Systems

Often, in distributed architectures, the network itself – the amount of traffic it must handle, and the path between clients and the data they request – plays an important role in the performance of transaction processing applications. The key to high performance is to cache information where the client can reach it easily.

Distributed Cache Protocol

Caché includes InterSystems’ unique Distributed Cache Protocol (DCP), which can dramatically reduce network traffic in networked systems.

DCP is effective because data is transported in packages. When information is requested across the network, the reply data package includes the desired data, and additional, related data as well. The natural data relationships inherent to objects and Caché’s multidimensional data model make it possible to identify and include information that is related to the originally requested data. This “associated” information is cached locally either at the client, or on the application server. Usually, subsequent requests for data can be satisfied from a local cache, thus avoiding another trip across the network. If the client changes any data, only the updates are propagated back to the database server.

The Distributed Cache Protocol can radically reduce network traffic. Performance is enhanced because for most requests, clients are using locally cached objects and data, and a Data Server can support more users and more application servers

The Caché Advantage

Performance

InterSystems’ unique Distributed Cache Protocol dramatically reduces network traffic, which means that transactions can be completed faster. Also, much of the time, clients use locally cached objects and data, resulting in even better performance.

Scalability

Thanks to DCP, Caché-based applications can be scaled up to serve many thousands of users without sacrificing performance. Dynamic namespace mapping allows networks to be expanded completely transparently to the applications running on them.

“Ontario’s Ministry of Health liked the application so much they expanded the project to include 170 hospitals. We never worried about the scalability issue. With Caché, we knew the application would perform well no matter how large it grew. … Our experience is in relational technology, including Oracle and DB2, and no other database technology that we know of compares to Caché.”

— Joseph Scaglione

Co-President

Rincon Technologies, Inc.

“Caché can significantly outperform and outscale its rivals.”

— Bloor Research

Deploying and Maintaining an Application

Hardware Platforms and Operating Systems

Caché applications typically run unchanged on a wide variety of hardware platforms and operating systems, including Windows 9x/ME/2000/NT, all major UNIX platforms, OpenVMS, and Linux.

Hardware Configurations

A Caché application may be deployed in a one-tier, two-tier, three-tier, or peer-to-peer hardware configuration without reprogramming or recompiling. In very large systems there may be multiple Caché Application Servers as well as multiple Caché Multidimensional Data Servers, but in general, there is far less processing overhead required when an Application Server accesses data that is on the same computer as the Application Server.

Usually a client connects to only one Caché Application Server, and it is that Application Server’s responsibility to obtain the data from the correct Data Server.

Large configurations may require a computer that primarily acts as a Data Server and several computers that serve as Application Servers. If possible in such a three-tier architecture, limit the Data Server to a single computer to avoid the overhead associated with coordinating multiple data servers.

Another commonly used architecture with Caché is a peer-to-peer architecture, in which two (or more) computers act both as Application and Data Servers. This becomes a particularly powerful architecture when each computer primarily serves a set of users who mostly access data stored on that computer but occasionally need access to data on another. For example, in a hospital one computer might be primarily dedicated to the lab and another to administrative applications, but occasionally they need to share data.

Caché also supports hardware clusters, in which several computers share access to the same disk drives and coordinate shared and exclusive access to disk blocks. This architecture provides enhanced reliability and greater performance than a single computer, but system management and operations are often complex. As with a peer-to-peer network, best performance in this environment is achieved when different computers are primarily responsible for distinct applications, reducing the contention among computers for the same disk blocks.

Backup shadow servers are also quite popular, and they are a good way to enhance reliability while off-loading some reporting and query activities.

These principals can be combined to form a wide range of hardware architectures.

Redeploying a Caché Application with a Relational Database

By virtue of Caché’s Unified Data Architecture and SQL Gateway, a Caché application can be recompiled to run against a relational database. Although the resulting performance will be less than optimal, this represents an important deployment option for VARs who need to offer a relational solution in order to be considered by potential new customers.

Installing an Application and Introducing Changes on a Running System

Once an application is written it must be installed and later changed. With thousands of PCs and multiple servers, this can be a real problem with most technologies.

Caché simplifies installation of application software. Caché ObjectScript code only needs to be installed on a single Data Server. Other computers get copies of it using DCP and cache it.

To introduce a change in a Caché ObjectScript routine into a running system, simply load the changed source code routine onto the single Data Server where the code resides. The source code will be automatically compiled and the Application Servers will be notified they need to reload the revised routine. Of course, such changes should be introduced with caution; a process that made a call from the old version to another routine will get an error upon attempting to return to the changed routine.

24-Hour Operation

Caché is designed to run 24 hours a day, every day of the year, and is in use that way at numerous sites with thousands of users. Caché supports such operations with minimal operator and system management involvement. See “Simple System Management / 24-Hour Database Operation”.

Chapter 4: Building Fast Web Apps Fast — Caché Objects For the Web

“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 primary means by which applications written in Caché are developed and interact with the Web, providing:

An advanced object-oriented development approach for database applications, and

Ultra-high performance and scalability at run-time.

CSP supports HTML, XML, WML, 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 that code with 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. However, 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 database applications.

The Cache Advantage

Object oriented procedural programming plus Caché Wizards result in rapid development of sophisticated 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. This session model enables Web transaction processing and many of the other characteristics of CSP.

. 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 – 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. The XML Wizard can be used to automatically generate XML descriptions of database objects, including code for the import and export of objects using XML documents.

. 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 a file of HTML, 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 layout 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 the technology 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.

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

The Caché Advantage

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.

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. (If there are multiple Caché Application Servers, the URL logically specifies which one to use.)

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.

State Preservation

In traditional Web programming, when a browser is running an application there’s no effective way (without a lot of programming) to retain information on the server from one request to the next. Instead, applications typically send all of the state information they need to retain out to the browser, either 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, for both saving and storing session context for each request.

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.

One of the advantages of the Session model is that it 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 also 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.

Class Architecture of Web Pages

For each Web page, there is a corresponding class that contains methods (code) to generate the page contents. Because these classes do not contain properties (data), there is no need to create a page object for each request.

When a request is received, its URL is used to identify a 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

The overall development process involves two steps. First, the Caché Object Architect is used to create database classes that describe the data that will be stored in the database. For example, there may be an account class, with an account name and billing address, and a person class with a person’s name and telephone number.

Next, a set of Web pages is defined to implement the user interface. There are two ways to build Web pages with CSP:

Web Designer - Use a Web design tool, or a simple text editor, to produce an HTML file with embedded Caché Application Tags, and compile it to generate the page class. Programmers provide additional methods in other classes.

Programmer – Programmers create the entire page class by coding the appropriate methods, typically using the Caché Object Architect. The page sent to the browser may use HTML, XML, WML, or other markup languages.

Both approaches yield the same quality of application with the same capabilities. The desired approach often reflects the talents and background of the people working on the project and their preferences.

Web Designer - Using Web Tools or HTML to Create the Web Page

With this strategy, a sequential file with HTML and Caché Application Tags is created (typically with a Web design tool although a simple text editor can also be used). That sequential file is not sent directly to the browser. Instead, it is used as a set of specifications that is read by a Caché Web compiler, which then generates application code (the Web page class) that runs whenever that page is requested.

The Web designer 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.

Although a complete simple application can be created this way, more commonly a programmer supplies additional code. This additional code is provided by writing methods in another class and having the HTML file include a Caché Application Tag that either calls that code or specifies that additional classes should be included (“inherited”) at compilation time. This is a good example of the power of multiple inheritance in the object architecture.

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 file and recompile the page.

With some Web design tools, such as Dreamweaver, Caché 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. The user simply clicks on the database class of interest, and then clicks on the set of properties (fields) 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.

Caché Application Tags

Caché Application Tags can be added to the HTML files used in the Web designer approach. 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 opening objects, running queries, program flow control, and directly specifying Caché Object Script code. For example, a CSP:Object tag enables the properties and methods of a Caché object to be used in a page and a CSP:Search tag provides database search capabilities.

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.

Caché Application Tags are extensible – developers can create their own to suit their specific needs.

Server Side Methods

CSP also makes it easy to have the browser directly call methods on the Caché server. After taking the appropriate action, that server method can return code for execution by the browser – typically JavaScript.

If the Web designer approach is being used, simply include in the HTML an expression of syntax “#server(…)#”. Within the parentheses is the name of the method to call and any input parameters it needs. The Web compiler will replace this syntax with JavaScript code that, when run on the browser, will invoke the Caché server method. 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())#"

HTML or XML?

HTML is the traditional “language” of the Web, and it is one of the most widely known programming 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 the Object Architect – 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.