Table of Contents | Previous
| Next
| Index
This chapter provides an overview of what a typical server-side JavaScript application looks like, and it shows you how to set up your system for server-side development.
This chapter contains the following sections:
As discussed in earlier sections, JavaScript applications have portions that run on the client and on the server. In addition, many JavaScript applications use the LiveWire Database Service to connect the application to a relational database. For this reason, you can think of JavaScript applications as having a three-tier client-server architecture, as illustrated in Figure 2.1.
Figure 2.1 Architecture of the client-server JavaScript application environment
The three tiers are:
-
WWW clients (such as Netscape Navigator clients): This tier provides a cross-platform end-user interface to the application. This tier can also contain some application logic, such as data-validation rules implemented in client-side JavaScript. Clients can be inside or outside the corporate firewall.
-
Netscape WWW server/database client: This tier consists of a Netscape server, with server-side JavaScript enabled. It contains the application logic, manages security, and controls access to the application by multiple users, using server-side JavaScript. This tier allows clients both inside and outside the firewall to access the application. The WWW server also acts as a client to any installed database servers.
-
Database servers: This tier consists of SQL database servers, typically running on high-performance workstations. It contains all the database data, metadata, and referential integrity rules required by the application. This tier typically is inside the corporate firewall and can provide a layer of security in addition to that provided by the WWW server. Netscape Enterprise Server supports the use of ODBC, DB2, Informix, Oracle, and Sybase database servers. Netscape FastTrack Server supports only ODBC. For further information about the LiveWire Database Service, see Part 3, "LiveWire Database Service."
The JavaScript client-side environment runs as part of WWW clients, and the JavaScript server-side environment runs as part of a Netscape web server with access to one or more database servers. Figure 2.2 shows more detail of how the server-side JavaScript environment, and applications built for this environment, fit into the Netscape web server.
The top part of Figure 2.2 shows how server-side JavaScript fits into a Netscape web server. Inside the web server, the server-side JavaScript runtime environment is built from three main components which are listed below. The JavaScript Application Manager then runs on top of server-side JavaScript, as do the sample applications provided by Netscape (such as the videoapp
application) and any applications you create.
Figure 2.2 Server-side JavaScript in the Netscape server environment
These are the three primary components of the JavaScript runtime environment:
In general, a JavaScript application can contain statements interpreted by the client (with the JavaScript interpreter provided with Netscape Navigator or some other web browser) and by the server (with the JavaScript runtime engine just discussed).
When you run a JavaScript application, a variety of things occur, some on the server and some on the client. Although the end user does not need to know the details, it is important for you, the application developer, to understand what happens "under the hood."
In creating your application, you write HTML pages that can contain both server-side and client-side JavaScript statements. In the source code HTML, client-side JavaScript is delimited by the SCRIPT
tag and server-side JavaScript by the SERVER
tag.
You can also write files that contain only JavaScript statements and no HTML tags. A JavaScript file can contain either client-side JavaScript or server-side JavaScript; a single file cannot contain both client-side and server-side objects or functions.
The JavaScript VM used in Netscape Enterprise Server 4.0 implements significant improvements in the processing of local variables (that is, variables that are declared inside a function) as compared to NES 3.6. Therefore it is suggested that use of global variables (that is, variables that are declared between the <server>
and </server>
tags) be minimized and applications be rewritten to use functions as much as possible. This can improve the application performance significantly.
If the HTML and JavaScript files contain server-side JavaScript, you then compile them into a single JavaScript application executable file. The executable is called a web file and has the extension .web
. The JavaScript application compiler turns the source code HTML into platform-independent bytecodes, parsing and compiling server-side JavaScript statements.
Finally, you deploy your application on your web server and use the JavaScript Application Manager to install and start the application, so that users can access your application.
At runtime, when a client requests a page from a server-side JavaScript application, the runtime engine locates the representation of that file in the application's web file. It runs all the server code found and creates an HTML page to send to the client. That page can contain both regular HTML tags and client-side JavaScript statements. All server code is run on the server, before the page goes to the client and before any of the HTML or client-side JavaScript is executed. Consequently, your server-side code cannot use any client-side objects, nor can your client-side code use any server-side objects.
For more details, see Chapter 5, "Basics of Server-Side JavaScript."
To develop and run JavaScript applications that take advantage of both client-side and server-side JavaScript, you need appropriate development and deployment environments. In general, it is recommended that you develop applications on a system other than your deployment (production) server because development consumes resources (for example, communications ports, bandwidth, processor cycles, and memory). Development might also disrupt end-user applications that have already been deployed.
A JavaScript development environment consists of
The development tools needed include:
The development and deployment machines require the following software:
In addition, if your application uses JavaScript's LiveWire Database Service, you need the following:
This section provides configuration information for using server-side JavaScript. For additional information on setting up your database to work with the LiveWire Database Service, see Chapter 10, "Configuring Your Database."
To run JavaScript applications on your server, you must enable the JavaScript runtime engine from your Server Manager by clicking Programs and then choosing server-side JavaScript. At the prompt "Activate the JavaScript application environment?", choose Yes and click OK. You are also asked about restricting access to the Application Manager. For more information, see "Protecting the Application Manager."
NOTE:
If you do not enable the JavaScript runtime engine, JavaScript applications
cannot run on the server.
To use both servlets and LiveWire, you need to enable server side JavaScript before enabling Java. Both can be enabled using the programs menu of the Administration Server. If you modify the classpath in obj.conf
, your changes will be lost if you enable/disable either server side JavaScript or Java from the programs menu of the Administration Server. An alternative to editing the classpath directive in the obj.conf
is setting the CLASSPATH
environment variable in Unix or setting the CLASSPATH
variable in the System settings for Windows NT. If you must edit the obj.conf
directly, please be sure to back up your changes. For Enterprise Server 4.0, you should add CLASSPATH
info to the JVM configuration files (jvm12.conf
for Solaris and NT) via the Enterprise Administration Server interface.
Once you activate the JavaScript application environment, you must stop and restart your web server for the associated environment variables to take effect. If you do not, JavaScript applications that use the LiveWire Database Service will not run.
The Application Manager provides control over JavaScript applications. Because of its special capabilities, you should protect it from unauthorized access. If you don't restrict access to the Application Manager, anyone can add, remove, modify, start, and stop applications on your server. This can have undesirable consequences.
You (the JavaScript application developer) need to have permission to use the Application Manager on your development server, because you use it to work with the application as you develop it. Your web server administrator, however, may choose to not give you this access to the deployment server.
When you enable the JavaScript runtime engine in the Server Manager, a prompt asks you whether to restrict access to the Application Manager. Choose Yes to do so, then click OK. (Yes is the default.) After this point, anyone attempting to access the Application Manager must enter the Server Manager user name and password to use the Application Manager and the dbadmin
sample application. For more information, see the administrator's guide for your web server.
If your server is not using the Secure Sockets Layer (SSL), the user name and password for the Application Manager are transmitted unencrypted over the network. An intruder who intercepts this data can get access to the Application Manager. If you use the same password for your administration server, the intruder will also have control of your server. Therefore, it is recommended that you do not use the Application Manager outside your firewall unless you use SSL. For instructions on how to turn on SSL for your server, see the administrator's guide for your web server.
In order to use Java classes in LiveConnect, you need to set up the server's CLASSPATH. For a complete description of this procedure, refer to the Programmer's Guide to Servlets and the Netscape Enterprise Server Administrator's Guide.
Installation of a Netscape server does not change your PATH
environment variable to include the directory in which the JavaScript application compiler is installed. If you want to be able to easily refer to the location of the compiler, you must modify this environment variable.
On Unix systems, you have various choices on how to change your PATH
environment variable. You can add $NSHOME/bin/https/lib
, where $NSHOME
is the directory in which you installed the server. See your system administrator for information on how to do so.
To change your NT system path, start the Control Panel application, locate the System dialog box, and set the PATH
variable in the Environment settings to include the %NSHOME%\bin\https\bin
, where NSHOME
is the directory in which you installed the server.
If you move the JavaScript application compiler to a different directory, you must add that directory to your PATH
environment variable.
Table of Contents | Previous
| Next
| Index
Last Updated: 09/29/99 18:01:49
© Copyright � 1999 Sun Microsystems, Inc. Some preexisting portions Copyright
� 1999 Netscape Communications Corp. All rights reserved.