Web Application Developer’s Guide phần 10 pps

Using the Borland Enterprise Server Web Edition
18-11
Modifying Web component connection
Modifying Web component connection
Borland Enterprise Server Web Edition provides an operational Apache
Web Server and Tomcat Web Container connection as “out of the box”
upon start up. The two components are connected with each other via the
IIOP Plug-in. This Plug-in allows both Apache and Tomcat to
communicate via Internet Inter-ORB Protocol (IIOP) to one another with
no required configuration.
Figure 18.5
Web components connection via IIOP
jss.softCommit=<true or false> Write to disk but only for crash recovery and not
a full transaction commit.
jss.userName=<char_string> This is the name of the database user.
jss.factoryName=<char_string> The name given to the JSS factory created by this
service. The service gets registered with this
name in the Smart Agent (osagent).
jss.workingDir=<path> The path of the working directory where the
database files are stored.
jss.pstore=<char_string> The name of the database file that gets created
under the jss.workingDir.
Table 18.2
JSS Properties (continued)
Property Name Description
18-12
Web Application Developer’ s Guide
Modifying Web component connection
Modifying Apache
To modify the Apache Web Server to a Tomcat Web Container, use the
following steps:

1
Open the configuration file, httpd.conf. It is located in the directory
path, such as:
<bes_home>\var\servers\<server_name>\apache1\conf\
You must edit the file by adding new lines of instruction discussed in
the following steps.
2
Load the mod_webapp using the LoadModule directive. You are
loading a new connection using a module name.
LoadModule webapp_module <bes-install>/lib/apache/ mod_webapp.so
Note
The webapp_module is a dynamic library.
3
Tell Apache about the connection using the WebAppConnection directive.
Have a new connection based on the name of the Tomcat server.
WebAppConnection myConnection iiop "tc_inst1"
Note
The name corresponds to the name you defined for the Tomcat IIOP
connector instance. In this case,
"tc_inst1"
is the IIOP connector
instance for Tomcat.
4
Tell Apache to use the WebAppDeploy directive for request handling.
The IIOP service will handle client request starting with the URL
/examples/
.
WebAppDeploy examples myConnection /examples/
Note
You can have multiple line entries for each deployments.

5
When completed, Save and exit the file.
Modifying the Connector in Tomcat
By default the Apache Web Server and Tomcat Web Container are
connected via the IIOP Plug-in. However, you can change the connection
configuration for this service in the configuration file,
server.xml
. This
service has a Connector named
IIOP
. It is capable of sending and receiving
IIOP messages by actually talking to the Apache Web Server for getting a
request and sending the response.
The IIOP service is separated into two portions; the Connector and the
Engine/Host.
Here is an example of the Connector portion:
<Service name="IIOP">
<Connector
className="org.apache.catalina.connector.iiop.IiopConnector"
name"tc_inst1"
/>
where
"tc_inst1"
is the name that Apache must point to.
Using the Borland Enterprise Server Web Edition
18-13
Modifying Web component connection
The Engine/Host portion has the same parameter values as a normal
Tomcat service.
Here is an example of the Engine/Host portion:

<Engine name="Iiop" defaultHost="localhost" debug="9">
<Host name="localhost" debug="9" appBase="wars"
unpackWARs="false">
</Host>
</Engine>
Afterwards, save and exit the file.
Connecting to the CORBA Server
The IIOP Plug-in also enables Apache to communicate with any
standalone CORBA service, but the VisiBroker ORB is required. (See the
“Understanding the Borland Enterprise Server Editions” chapter in the
Borland Enterprise Server
Developer’s Guide
, and the Borland Enterprise
Server
Installation Guide
for details.) This means you can easily put a
web-based front-end on almost any CORBA server.
Figure 18.6
Connecting from Apache to a CORBA server
18-14
Web Application Developer’ s Guide
Modifying Web component connection
Configuring the IIOP Plug-in for use with CORBA
You must configure Apache’s
httpd.conf
file in order for the CORBA
service to be invoked by the Web Server. This involves three steps:
1
Load the mod_webapp using the LoadModule directive
.

This is
achieved by adding the following line to the httpd.conf file:
LoadModule webapp_module c:/<install-dir>/lib/apache/mod_webapp.dll
2
Tell Apache about the connection using the WebAppConnection
directive. This is achieved by adding the following line to the
httpd.conf

file:
WebAppConnection <connection-name> <connection-protocol> <object-name>
where
<connection-name>
is the name by which you want your
connection referred in your application,
<connection-protocol>
is the
protocol used (e.g.
iiop
),
<object-name>
is the CORBA object name of the
object registered with the Smart Agent.
3
Tell Apache how to use the connection using the WebAppDeploy
directive. The Web Server needs to know which HTTP requests to
forward to the connector and which HTTP requests should not be
forwarded. This is achieved by adding a line of URI mapping to the
httpd.conf
file:
WebAppDeploy <web-application-name> <connection-name> /<URI-mapping-component>/

where <
web-application-name>
is the name of the web application using
the connector,
<connection-name>
is the name of the connection (the same
name as in Step 2), and
<URI-mapping-component>
is the URI used to
identify which HTTP requests should be routed through the connector.
A full example of the use of this connector is in the “Apache/Tomcat IIOP
Connector Example” in the Borland Enterprise Server
Developer’s Guide
.
Interface Definition Language (IDL) for Apache, Tomcat and
CORBA Server
The ReqProcessor Interface that allows communication between a web
server and a web container using IIOP. HTTP request can then be passed
from an Apache Web Server to another Tomcat Web Container or a
CORBA Server. The server must return HttpResponse.
Code sample 18.1
IDL Specification for ReqProcessor Interface
*/
module apache {
struct NameValue {
string name;
string value;
};
typedef sequence<NameValue> NVList;
typedef sequence<octet> OctetSequence_t;

Using the Borland Enterprise Server Web Edition
18-15
Security for the web components
/*
* HttpRequest analog
*/
struct HttpRequest {
string authType; // auth type (BASIC,FORM etc)
string userid; // username associated with request
string appName; // application name (context path)
string httpMethod; // PUT, GET etc,
string httpProtocol; // protocol HTTP/1.0, HTTP/1.1 etc
string uri; // URI associated with request
string args; // query string associated with this request
string postData; // POST (form) data associated with request
boolean isSecure; // whether client specified https or http
string serverHostname; // server hostname specified with URI
string serverAddr; // [optionally] server IP address specified
// with URI
long serverPort; // server port number specified with URI
NVList headers; // headers associated with this request
// format: header-name:value
};
/*
* HttpResponse analog
*/
struct HttpResponse {
long status; // HTTP status, OK etc.
boolean isCommit; // server intends to commit this request
NVList headers; // header array

OctetSequence_t data; // data buffer
};
interface ReqProcessor {
HttpResponse process(in HttpRequest req);
};
};
Security for the web components
The Borland Enterprise Server allows you to secure the web components
using the conventions of encryption, authentication, and authorization.
Like the security measures provided by the J2EE standards, where
security is set at the module level, you can also secure web components by
declaring the security mechanism within their configuration files.
Security for the Apache Web Server
The Apache Web Server uses data transport encryption technology for
security. The Borland Enterprise Server uses the
mod_ssl
module for this
purpose. This module provides strong cryptography for Apache Web
Server via the Secure Sockets Layer (SSL v2/v3) and Transport Layer
18-16
Web Application Developer’ s Guide
Security for the web components
Security (TLS v1) protocols by the help of the Open Source SSL/TLS
toolkit OpenSSL.
Security for the Tomcat Web Container
The Borland Enterprise Server allows you to control access to the web
resources by declaring the security roles. This information is specified in
the deployment descriptor tags and the runtime environment, when
validation is required. To set up the declarative security, do the following:
Authentication setup

1
Open the
web.xml
file (deployment descriptor) and identify the security
constraint for the web application:
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<! Define the context-relative URL(s)to be
protected >
<url-pattern>/servlet/*</url-pattern>
<! If you list http methods,only
those methods are protected >
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<! Anyone with one of the listed roles may access
this area >
<role-name>tomcat</role-name>
<role-name>role1</role-name>
</auth-constraint>
</security-constraint>
This code example enables security on any URL pattern containing
“servlet” in its path. The module deployment descriptor indicate which
security roles are allowed to access the web resource. Also, the
authorization constraint indicates that the roles of “tomcat” and “role1”
allowed user with these names access to the web resources.

2
Next, you want to set up authentication realms. In the
server.xml
file,
add a realm name to authenticate user access. Borland provides the
LoginModules, which are realms that you can define as shown below.
<Realm className="org.apache.catalina.realm.BSSRealm" name="NTLogin"/>
The realm name, “NTLogin” is user defined. The Borland Security
Service Realm corresponds to any of the names in the authentication
configuration file, below.
Using the Borland Enterprise Server Web Edition
18-17
Security for the web components
NTLogin {
com.borland.security.provider.authn.NTLoginModule required;
};
UnixRealm {
com.borland.security.provider.authn.UNIXLoginModule required;
};
MyRealm {
com.borland.security.provider.authn.JDSLoginModule required;
}
For more information on rolemap, see the “Authentication” chapter in
the Borland Enterprise Server
Developer’s Guide
.
You can add the realm at any level you want within the Tomcat
component structure. For example, you can add a realm at the engine
level. You can also add a realm at the host level. But if you have
multiple hosts, and one of those hosts does not have a specific realm

assigned to it, then that host will take the realm properties at the engine
level. This is also true if you do not assign a realm at a context level, it
will take the realm properties from the first host level with a realm. The
realm interaction is illustrated in the example below.
<engine>
<realm“eRealm” />
<host h1>
<realm “hRealm” />
<context webapp1>
<realm “cRealm” />
</context>
<context webapp2>
//For this context, webapp2 uses the
“hRealm” from host 1.
</context>
</host>
<host h2>
//For host 2, it uses “eRealm” from the engine.
</engine>
Authorization setup
Set up for basic (two-tier) authorization for users of the Tomcat Web
Container. Authorization is defined through a rolemap file where user
roles are listed. The code example below shows a typical rolemap.
Manager {
* (USERID=vbdev, groupname=vvseng)
}
Customer {
*groupname=vvseng
}
Someother {

*groupname=vvseng
}
18-18
Web Application Developer’ s Guide
Security for the web components
The role of “Manager” is listed in the rolemap file. This role must be
mapped using the authorization constraint specified in
web.xml
, for
example:
<auth-constraint>
<! Anyone with one of the listed roles may access this area >
<role-name>tomcat</role-name>
<role-name>Manager</role-name>
</auth-constraint>
This example of the auth-constraint is the same code snippet from the
security constraint previously mentioned in the Authentication Setup. For
more information on rolemap, see the “Authentication” chapter in the
Borland Enterprise Server
Developer’s Guide
.
Alternatively, you can set up for a three-tier authorization scheme to
accommodate a more complex client/server landscape. As illustrated in
the diagram below, a three-tier authorization scheme can include a client
browser, a web container, and an EJB container.
Figure 18.7
Three-tier authorization scheme
The server-side has two different container components with security
mechanism in each of them. So when a user (John) sends a client request,
his login ID is authorized and authenticated at the web container level.

Lets say that the client request requires the servlet running at the web
container to access a bean in the EJB container. However, the EJB
container does not know the user, “John”. You have two options to extend
security to the EJB container. The first and most common is to make the
EJB container knowledgeable of all users. The second is to use the concept
of “run as”. When the web container makes a EJB invocation, the web
container will “run as” a user that the EJB container recognize. The web
application can be configured with a “run as” user to access the third-tier
component. The web application with the servlet making the EJB
invocation can be configured with “run as” user “web container”. In this
case, though the real user is “John”, the EJB container acknowledges the
user as “web container”.
Using the Borland Enterprise Server Web Edition
18-19
Data Exchange using SOAP and Cocoon
Setting up ‘Run As’ role
The Borland web container, Tomcat, supports the “run as” configuration
for web applications. The web application can be set up with the “run as”
role which maps to a user. In the code example below, the “run as” role is
configured for the web application.
In the
web.xml
file of the web application you must have entries similar to:
<web-app>
<servlet>
<servlet-name>
HelloWorldExample
</servlet-name>
<servlet-class>
hot.HelloWorldExample

</servlet-class>
<run-as>
<description>Run as Web Container</description>
<role-name>Web-Container</role-name>
</run-as>
</servlet>
</web-app>
Beside setting the “run as” role in the web.xml, you also must set a
principal to map to the “run as” role. Set the property:
vbroker.security.domain.<domain name>.runas.<run as role> =<principal>
as an example:
vbroker.security.domain.authz_dom1.runas.Web-Container=
ejb-user
Afterward, whenever the
/servlet/HelloWorldExample
is accessed by the
user, the that user will be set to ‘ejb-user’ for the duration of invocation.
Data Exchange using SOAP and Cocoon
The Web Edition includes support for the Simple Object Access Protocol
(SOAP) and the Apache Cocoon. The Cocoon servlet is pre-installed in the
Tomcat Web Container.
About SOAP
SOAP is a protocol for exchanging XML-formatted messages between
network peers. SOAP is used for implementing Web Services. These
services can be invoked within the Tomcat Web Container via HTTP
requests executed either from standalone Java applications or embedded
within the web applications that are run from a browser.
The Web Edition includes the SOAP pre-installed with the Tomcat Web
Container as a web application (
soap.war

). There are several examples of
18-20
Web Application Developer’ s Guide
Clustering of multiple web components
SOAP services that are also included so that they are available “out of the
box”. In addition, a jar file is provided for you to develop and run SOAP
clients.
Note
For detailed information on deploying the SOAP example, see the
“Additional Features and Examples” chapter in the Borland Enterprise
Server
Developer’s Guide
.
About Cocoon
Cocoon is a web publishing framework that renders XML data into a
number of formats including HTML, WML, PDF, and the like. These
formats are based on a set of properties provided by an XSL stylesheet.
The Web Edition includes the Cocoon servlet pre-installed in the Tomcat
Web container. The
web.xml
file contains specifications for the Cocoon
servlet, which is pre-configured to point to the cocoon properties file in
the WEB-INF directory of the context under which Cocoon is invoked.
However, you can change this specification to point to another location if
desired. Additionally, the
web.xm
l file includes a mapping for “*.xml”
directing any such file to be processed by Cocoon. This mapping can be
modified or deleted.
An unmodified copy of the properties file is included as part of the

Cocoon webapp (
cocoon.war
) distributed with the Web Edition. You can
customize this file to create your own cocoon.properties file. This
unmodified
cocoon.properties
file is compiled in with the Tomcat Web
Container. As the default properties file, it is used whenever the file
specified in the Cocoon servlet definition cannot be found.
Cocoon is an open-source product distributed by the Apache Software
Foundation. For additional information about Cocoon, see the website:
/>Clustering of multiple web components
In a typical deployment scenario, you can use multiple Borland Partitions
to work together in providing a scalable n-tier solution. Each Borland
Partition can have the same or different services. These services can be
turned off or on depending on your clustering schema. In any case,
leveraging these resources together or clustering, makes deployment of
your web application more efficient. Clustering of the web components
involve session management, load balancing and fault tolerance (failover).
Using the Borland Enterprise Server Web Edition
18-21
Clustering of multiple web components
Interaction between the client and server involves two types of connection
services: stateless and stateful. A stateless service does not maintain a state
between the client and the server. There is no “conversation” between the
server and the client while processing a client request. In a stateful service,
the client and server maintains a dialogue of information, thereby having
multiple interactions with one another the client in the context of the same
session.
Stateless service

The Borland Enterprise Server Web Edition supports clustering of web
components. For a stateless connection, a single Apache Web Server is
connected to multiple Tomcat Web Containers. The diagram below shows
how the web components are connected using IIOP in conjunction with
the JSS.
Figure 18.8
Apache and Tomcat communicate via IIOP
18-22
Web Application Developer’ s Guide
Clustering of multiple web components
The IIOP Plug-in allows the Tomcat Web Container and the Apache Web
Server to communicate through the IIOP protocol. The IIOP Plug-in uses
an interface that handles Apache Web Server’s HTTP requests and
transmits them via IIOP to the Tomcat Web Container. The configuration
of the web components illustrated in this diagram shows that it does not
matter which Tomcat instance gets the client request.
Load balancing
When clustering several web components, client requests are serviced to
load balance request in an even, distributed fashion between the multiple
Tomcat Web Containers using a round-robin scheme.
In this example, the first client request goes to Tomcat 1. The second client
request goes to Tomcat 2. The third client request goes to Tomcat 1. And
so forth.
Fault tolerance
When the first instance of Tomcat goes down, the Apache Web Server
transparently re-routing of all client requests to the second instance of
Tomcat. Since this is a stateless connection (no session), the JSS is not
involved.
Stateful service
In a stateful service, the web components (Apache and Tomcat servers)

maintain the “conversational” interaction within the same context of a
session. If the first Tomcat instance goes down, another instance of
Tomcat can then pick up where the first Tomcat left off since it gets
session information from the JSS.
Session management
The JSS is responsible for session management of clustered web
components. It does not support load balancing indiscriminately,
meaning that the Apache Web Server needs to send data to the first
Tomcat instance that it initially started in the session. The proceeding
session is then sent to the next Tomcat instance. And so forth. In the
Using the Borland Enterprise Server Web Edition
18-23
Clustering of multiple web components
diagram below, Session 1 is sent to the first Tomcat instance and Session 2
is sent to the second instance of Tomcat. Any client request from Session 1
will always be serviced in the first Tomcat instance.
Figure 18.9
Session Management for multiple Tomcats
JSS role
In a stateful service connection, the JSS provides session management to
all Tomcat Web Containers. Session data between the client and a specific
Tomcat instance is “flushed” to the JSS for session management.
18-24
Web Application Developer’ s Guide
Clustering of multiple web components
Figure 18.10
JSS providing session management to multiple Tomcats
When the first instance of Tomcat goes down, then the Apache Web
Server finds the next Tomcat instance and send the client request to that
instance. That particular Tomcat instance then consults JSS to obtain

session information.
Fault tolerance
In the Web Edition, fault tolerance or failover is supported by the JSS that
allows continuous session processing when a web container (Tomcat)
dealing with the session suddenly dies. JSS provides a transparent
mechanism to store session data in the database. The JSS caches entity and
session information for recovery in case of the web container or service
failure.
Using the Borland Enterprise Server Web Edition
18-25
Clustering of multiple web components
Modifying Tomcat for Failover
In the Tomcat configuration file, server.xml, you need to add an entry
similar to the code snippet shown here for each web application.
<Manager className="org.apache.catalina.session.PersistentManager">
<Store className="org.apache.catalina.session.BorlandStore"
storeName="jss_factory"/>
</Manager>
This code is specifying to use a PersistentManager with a storage class
BorlandStore. You also specify the connection to a BorlandStore factory
named jss_factory. There must be a JSS with that factory name running in
the local network.
See the description for jss.factoryName in “Managing/Configuring the
JSS properties” on page 18-10.
Session storage implementation
There are two methods of implementing session storage to your clustered
web components. They are:
• Programmatic implementation
• Automatic implementation
Programmatic implementation

The Programmatic implementation assumes that each time you change
the session attributes, you will call
session.SetAttribute()
to notify to the
Tomcat Web Container that you have changed the session attributes. This
is a common operation in servlet development and when executed, there
is no need to modify the
server.xml
file. Each time you change the session
data, it is immediately written to the database through the JSS. Then if
your Tomcat instance unexpectedly goes down, the next Tomcat instance
designated to pick up the session will access the session data. In essence,
the Programmatic implementation guarantees to save changes
immediately.
Automatic implementation
The Automatic implementation lets you store the session data periodically
to JSS, no matter if the data has changed or not. By using this
implementation, you do not need to notify the Tomcat Web Container that
the session attribute has changed.
For example, you can change state without calling setAttribute () as
depicted in the following code entry:
Object myState = session.getAttribute("myState");
// Modify mystate here and do not call setAttribute ()
Any change of state (or not) is automatically written to the database based
on a user-defined interval time frame (heartbeat).
18-26
Web Application Developer’ s Guide
Clustering of multiple web components
Your configuration file, server.xml, will have the following code snippet:
<Manager className=

"org.apache.catalina.session.PersistentManager"
maxIdleBackup="xxx">
<Store className=
"org.apache.catalina.session.BorlandStore"
storeName="jss_factory"/>
</Manager>
where
xxx
is the desire time interval in seconds that you want the session
data to be stored.
Note
Using the Automatic implementation does have some limitations to
consider. The first, is that if the Tomcat Web Container goes down
between the save interval time period, the latest changes are not visible for
the next Tomcat instance. This is an important concern when defining the
time interval value for the heartbeat.
The second consideration is that the data is saved at the desired time
interval no matter if the data is changed or not. This can be wasteful if a
session frequently does not changes and the defined time interval is set
too low of a value.
Using JSS for session storage
There are two separate approaches you can take to attain persistency in
your session data. One approach is to use JSS as a front end to the Borland
JDataStore. The second approach is to use the native session management
facilities of Tomcat Web Container, which provides a mechanism to
connect directly to the JDataStore database.
In order to use the session management facilities of the Tomcat Web
Container you must add configuration entries to the
server.xml
file to

identify the connection URL. If the location of the session data changes in
the database, then the URL must be changed as well to show the new
location.
The Web Edition supports both of these operation, however, using JSS
instead of the native session management of the Tomcat Web Container is
highly recommended because of the following advantage:
• Once you have defined a JSS with a given name, it can run any where in
the local network. Afterwards, stopping the initial JSS and starting a
new one requires no changes to the configuration entries. This is called
“location transparency”.
• JSS does not require set up of database tables for session storage. The
database tables are automatically created by JSS.
• JSS also has a mechanism to store EJB session information in the
Borland Enterprise Server. All your session information are easily
stored in one place using the same JSS.
Using the Borland Enterprise Server Web Edition
18-27
Clustering of multiple web components
Using HTTP sessions
The HyperText Transfer Protocol (HTTP) is a stateless protocol. In the
client/server paradigm, it means that all client request that the Apache
Web Server receives is viewed as an independent transaction.There is no
relationship between each client requests. This is a typical stateless
connection between the client and the server. However, there are times
when the client deems it necessary to have a session concept for
transaction completeness. A session concept typically means having a
stateful interaction between the client and server. An example of the
session concept is shopping online with an interactive shopping cart.
Every time you add a new item into your shopping cart, you expect to see
that new item added to a list of previously added items. HTTP is not

usually regarded for handling client request in a stateful manner. But it
can. The Borland Enterprise Server Web Edition supports the HTTP
sessions through two methods of implementations:
• Cookies — The web server send a cookie to identify a session. The web
browser keeps sending back the same cookie with future requests. This
cookie helps the server-side components to determine how to handle
the transaction for a given session.
• URL rewriting — The URL that the user clicks on is dynamically
rewritten to have session information.
18-28
Web Application Developer’ s Guide
Index
I-1
A
Apache Web Server
configuration 18-5
configuration syntax 18-5
connecting to Tomcat Web Container 18-2
.httaccess files 18-6
applet deployment 4-8, 4-13
in archives 4-9
applet security
restrictions 4-11
sandbox 4-10
security manager 4-2, 4-10
signing 4-11
solutions 4-11
applet tag 4-2
attributes 4-3
mistakes 4-4

applets 4-1
archiving 4-9
browser issues 4-5, 4-7
browser Java implementation 4-6
debugging 4-21
debugging in a browser 4-22
in a WAR file 3-11
Java Plug-in 4-7
Java Virtual Machine 4-2
overview 2-1, 2-2, 4-2
running 4-19
running JDK 1.1.x applets in JBuilder 4-20
running JDK 1.2 4-20
testing 4-13
third-party libraries 4-12
tips 4-8
using packages 4-9
AppletTestbed 4-20
debugging applets 4-21
appletviewer 4-20
debugging applets 4-21
application homepage
Web Start 17-5
archive attribute, applet tag 4-3
archive file
deploying to a web server 16-1
authentication
for a WebApp 16-14
B
Borland

contacting 1-5
Borland Online 1-6
Borland-specific DTD 18-8
browsers
difference in Java implementation 4-6
Java Plug-in 4-7
JDK support issues 4-5
running applets 4-5
solutions for running applets 4-7
C
case sensitivity
in applets and applet tag 4-9
CGI (Common Gateway Interface)
compared to servlets 2-3
Classes page
of WebApp properties 3-6
client requests to servlet 5-6
code attribute, applet tag 4-3
codebase attribute, applet tag 4-3
Common Gateway Interface (CGI)
compared to servlets 2-3
compiling
applets 4-19
JSPs 15-2
servlets 15-2
configuring web server 14-1, 14-3
Connection
stateful service 18-22
contacting Borland 1-5
newsgroups 1-6

World Wide Web 1-6
control tag, InternetBeans Express 11-7
Core Services
Web Edition 18-2
D
data-aware
JSP 11-1
servlets 6-12, 11-1
Database class
using in a JSP 11-7
using in a servlet 11-3
database tag, InternetBeans Express 11-7
DataExpress
using in a JSP 11-1, 11-6
using in a servlet 11-1, 11-3
debugging
applets 4-21
applets in a browser 4-22
JSP 15-13
servlets 15-13
Index
I-2
Web Application Developer’ s Guide
Dependencies page
of WebApp properties 3-8
deploying
applet archive files 4-9
applets 4-8, 4-13
applications 17-1
archive file 16-1

by file type 3-10
JSP 16-3
servlets 5-8, 16-2
WAR file 16-1
WebApp 16-1
deployment descriptors 3-1
editing 3-2
for a WebApp 3-3
more information 16-18
node of WebApp 3-4
vendor-specific for a WebApp 16-17
web application 16-3
web.xml file 3-4, 16-4
WebApp DD Editor 16-4
developer support 1-5
distributed applications
vs. web applications
documentation conventions 1-3
Macintosh-specific 1-5
platform conventions 1-4
E
EJB References page
in WebApp DD Editor 16-14
enabling web commands 15-8
Environment page
in WebApp DD Editor 16-13
Error Pages page
in WebApp DD Editor 16-12
F
Fault Tolerance

for Tomcat Web Container 18-22, 18-24
file locations
in a WebApp 3-3
file types
included in WAR file 3-10
filter
adding to web.xml file 16-5
filter servlet 6-1, 16-7
Filters page
in WebApp DD Editor 16-7
fonts
JBuilder documentation conventions 1-3
G
generated URL 15-7
generating tables
with InternetBeans Express 11-5
H
height attribute, applet tag 4-3
hspace attribute, applet tag 4-3
HTML servlets 5-7, 6-4
HTTP servlets 5-7
HTTP Sessions 18-27
I
image tag, InternetBeans Express 11-7
importing
files to a WebApp 3-4
web application 3-3
installing Web Start 17-3
internet technologies
table of 2-1

InternetBeans Express 11-1
and JSPs 11-6
and servlets 11-3
displaying servlet data 11-3
format of tag library file 11-9
generating tables 11-5
overview 2-1, 2-5
parsing HTML 11-5
posting servlet data 11-4
table of classes 11-1
table of JSP tags 11-7
tag library 11-6
InternetBeans Express tag library
control tag 11-7
database tag 11-7
image tag 11-7
query tag 11-7
submit tag 11-7
table tag 11-7
InternetBeans Express tutorials
JSP 13-1
servlet 12-1
internetbeans.tld file 11-6
format 11-9
table of JSP tags 11-7
invoking servlets 6-9
IxCheckBox class 11-1
IxComboBox class 11-1
IxControl class 11-1
using in a JSP 11-7

using in a servlet 11-3
Index
I-3
IxHidden class 11-1
IxImage class 11-1
using in a JSP 11-7
IxImageButton class 11-1
IxLink class 11-1
IxListBox class 11-1
IxPageProducer class 11-1
servletGet() method 11-3
servletPost() method 11-4
using in a servlet 11-3
IxPassword class 11-1
IxPushButton class 11-1
IxRadioButton class 11-1
IxSpan class 11-1
IxSubmitButton class 11-1
using in a JSP 11-7
using in a servlet 11-4
IxTable class 11-1
generating tables 11-5
using in a JSP 11-7
IxTextArea class 11-1
IxTextField class 11-1
J
JAR files
applet archive attribute 4-3
including in WAR file 3-11
signing 4-11

Java Network Launching 17-1
Java Network Launching Protocol 17-1
See also JNLP
Java Plug-in 4-7
Java Session Service
connecting with Tomcat Web Container 18-3
Role 18-23
Storage Implementation 18-25
Automatic 18-25
Programmatic 18-25
using session storage 18-26
Java support, browsers 4-5
Java Web Start 17-1
See also Web Start
JavaServer Page wizard 10-1
JavaServer Pages 9-1
See also JSP
JBuilder
working with WebApps 15-1
JNLP 17-1
JNLP file 17-5
JSP (JavaServer Pages) 9-1
and InternetBeans Express 11-6
and servlets 5-2
compiling 15-2
connecting to a JDataStore 13-1
creating in wizard 9-3, 10-1
data-aware 11-1, 13-1
debugging 15-13
deploying 16-3

features of JBuilder 9-3
including in WAR file 3-10
links 9-5
overview 2-1, 2-3
running 15-5
setting run parameters 15-9
source debugging 15-13
syntax 9-2
tag library mapping 16-11
using JavaBeans 10-1
wizard 10-1
JSP (JavaServer Pages) tutorials 10-1
using InternetBeans 13-1
JSP API 9-2
comment tag 9-2
declaration tag 9-2
expression tag 9-2
getProperty tag 9-2
page directive 9-2, 11-6
scriptlet tag 9-2
setProperty tag 9-2
taglib directive 9-2, 11-6
useBean tag 9-2
JSP tag libraries
InternetBeans Express 11-6
JSP wizard 9-3
and InternetBeans Express 11-6
L
launch URI 15-9
listener servlets 6-1, 16-8

interfaces 6-9
Listeners page
in WebApp DD Editor 16-8
Load Balancing 18-22
Login page
in WebApp DD Editor 16-14
M
Macintosh
support in JBuilder 1-5
Manifest page
of WebApp properties 3-9
mapping servlets 6-6, 15-3, 15-9
MIME Types page
in WebApp DD Editor 16-12
multi-threaded servlet 5-6
I-4
Web Application Developer’ s Guide
N
name attribute
applet tag 4-3
internetbeans.tld file 11-9
naming servlets 6-6, 15-3
newsgroups 1-6
Borland 1-6
O
online resources 1-6
P
packages
in applets 4-9
param tag, applets 4-3

parameters
applet tag 4-3
plugin for web server
creating 14-7
Plug-in, Java 4-7
projects
setting up for Web Start 17-3
properties
of a WebApp 3-5
of WAR file 3-10
Q
query tag, InternetBeans Express 11-7
QueryDataSet class
using in a JSP 11-7
using in a servlet 11-3
R
required attribute, internetbeans.tld file 11-9
Resource References page
in WebApp DD Editor 16-13
root directory
of a WebApp 3-3
rtexprvalue attribute, internetbeans.tld file 11-9
run parameters
JSPs 15-9
servlets 15-9
running
applets 4-19
JSPs 15-5
servlets 15-3, 15-5
S

sandbox
applet security 4-10
Web Start application security 17-1
security
applet restrictions 4-11
applets 4-11
for a Web Start application 17-1
for a WebApp 16-15
sandbox 4-10
security manager 4-10
signing applets 4-11
security constraint
adding to web.xml file 16-5
Security page
in WebApp DD Editor 16-15
servlet API 5-3
servlet HTTP package 5-4
servlet tutorials
guestbook 8-1
hello world 7-1
using InternetBeans 12-1
Servlet wizard 12-1
options 6-1
ServletContext 3-3
servletGet() method 11-3
servletPost() method 11-4
servlets 5-1
adding to web.xml file 16-5
and InternetBeans Express 6-12, 11-3
and JSPs 5-2

and URIs 15-3
and URLs 6-6, 15-3
and web servers 5-3
and WebApp 6-1, 6-6, 15-3
compared to CGI (Common Gateway
Interface) 2-3, 5-1
data-aware 11-1
deploying 5-8, 16-2
destroying 5-6
examples of use 5-8
filter 6-1, 16-7
handling client requests 5-6
HTML-aware 5-7
HTTP-specific 5-7
including in WAR file 3-10
initializing 5-5
internationalizing 6-11
invoking 6-9, 6-10
lifecycle 5-5
listener 6-1, 6-9, 16-8
mapping 6-6, 15-3, 15-9
multi-threaded 5-6
naming 15-3
overview 2-1, 2-3
passing responses 5-6
ServletContext 3-3
standard 6-1, 16-9
starting 5-5
Index
I-5

URL pattern 6-6, 15-3
web servers 5-1
servlets in JBuilder 6-1
compiling 15-2
content type 6-4
creating parameters 6-8
creating with wizard 6-1
debugging 15-13
making data-aware 6-12
making single threaded 6-1
naming 6-6
overriding standard servlet methods 6-5
running 15-3, 15-5
setting run parameters 15-9
setting run properties 15-12
SHTML file 6-6
Servlets page
in WebApp DD Editor 16-9
Session Management 18-22
SHTML file 6-6
signing applets 4-11
single threaded servlet 6-1
Smart Agent
Web Edition 18-2
source debugging for JSPs 15-13
standard servlet 6-1
SHTML file 6-6
starting web server 15-6
Stateful Service 18-22
Stateless Service 18-21

stopping web server 14-8, 15-8
submit tag, InternetBeans Express 11-7
T
table tag, InternetBeans Express 11-7
tables
generating with InternetBeans Express 11-5
tag libraries
InternetBeans Express 11-6
Tag Libraries page
in WebApp DD Editor 16-11
tagclass attribute, internetbeans.tld file 11-9
technical support 1-5
testing
applets 4-13
third-party libraries
applets 4-12
Tomcat 5-3
configuring 14-1
using with JSP 10-1
Tomcat Web Container
connecting to Apache Web Server 18-2
connecting to JSS 18-3
modifying for failover 18-25
tutorials
guestbook servlet 8-1
JSP (JavaServer Page) 10-1
JSP using InternetBeans 13-1
servlet using InternetBeans 12-1
simple servlet 7-1
U

URI launching 15-9
URIs and servlets 15-3
URL pattern 6-6, 15-3
URLs and servlets 6-6, 15-3
Usenet newsgroups 1-6
V
vspace attribute, applet tag 4-3
W
WAR file 3-5
WAR file (web archive) 3-2
adding applets 3-11
adding JAR files 3-11
definition of 3-10
deploying 16-1
generating 3-3
included file types 3-10
properties 3-10
relation to WebApp 3-10
setting location of 3-5
setting name of 3-5
tools 3-2
viewing contents of 3-10
Web Application wizard 3-3
web applications 1-1, 2-1, 2-7, 3-1, 15-1
See also WebApp
in JBuilder
overview
overview of developing
vs. distributed applications
working with

web archives 3-2
See also WAR file
web commands
enabling 15-8
Web Debug command 15-1
enabling 15-8
web development
basic process 2-6
Web Edition
Apache Web Server 18-4
configuration 18-5
directory structure 18-6
modifying 18-12
I-6
Web Application Developer’ s Guide
architectural overview 18-1
authorization
three-tier authorization 18-18
Core Services 18-2
Smart Agent 18-2
Web Server 18-4
Java Session Service
properties 18-10
session management 18-9
Partition Services 18-6
Java Session Service (JSS) 18-9
Tomcat Web Container 18-7
Web Application Archive File (WAR file). 18-8
web component connection
modifying 18-11

web resource collection
adding to web.xml file 16-5
Web Run command 15-1, 15-6, 15-7
enabling 15-8
web run options 14-6
web server plugin 14-8
GUI editor 14-9
JSP considerations 14-9
registering as OpenTool 14-8
setting up the web server 14-8
starting the web server 14-8
web servers 5-3
configuring 14-1, 14-3, 14-4
creating plugin for 14-7
formatted output 15-7
raw output 15-7
starting 15-6
stopping 15-8
Tomcat 5-3, 14-1
web run options 14-6
web view options 14-4
Web Start 17-1
and JBuilder 17-3
applet 17-4
application 17-4
application homepage 17-5
application security 17-1
installing 17-3
JAR file 17-4
JNLP file 17-5

setting up your project 17-3
tutorial 17-6
wizard 17-5
web technologies
table of 2-1
web view 15-7
web view options 14-4
web view source 15-7
web.xml file 3-1, 16-3
adding a filter 16-5
adding a security constraint 16-5
adding a servlet 16-5
adding a web resource collection 16-5
authentication method 16-14
creation of 3-4
editing 3-2, 16-4
EJB references 16-14
environment entries 16-13
error page mapping 16-12
filter-mapping tags 16-7
listener tags 16-8
MIME Type mapping 16-12
more information 16-18
resources 16-13
security constraints 16-15
servlet tags 16-9
tag libraries 16-11
taglib tags 16-11
WebApp
deploying 16-1

deployment descriptor editor 16-4
deployment descriptors 3-3, 16-3
deployment descriptors, vendor-specific 16-17
file locations 3-3
importing files 3-4
importing into JBuilder 3-3
properties 3-5
root directory 3-3
structure 3-1
testing 16-3
tools 3-2
WEB-INF directory 3-3
wizard 3-3
WebApp DD Editor 16-4
adding a filter 16-5
adding a security constraint 16-5
adding a servlet 16-5
adding a web resource collection 16-5
context menu 16-5
EJB References page 16-14
Environment page 16-13
Error Pages page 16-12
Filters page 16-7
Listeners page 16-8
Login page 16-14
MIME Types page 16-12
Resource References page 16-13
Security page 16-15
Servlets page 16-9
Tag Libraries page 16-11

WebApp Deployment Descriptor page 16-5
WebApp Deployment Descriptor page 16-5
WebApp node 3-3
WebApp properties 3-5
Classes page 3-6
Index
I-7
Dependencies page 3-8
directory 3-5
file types included 3-5
Manifest page 3-9
WAR file location 3-5
WAR file name 3-5
WebApp page 3-5
web-borland.xml 18-8
WEB-INF directory 3-3
WebLogic
deployment descriptor 16-3
weblogic.xml file 16-3
width attribute, applet tag 4-3
wizards
JSP (JavaServer Page) 9-3, 10-1, 11-6
Servlet 12-1
Web Application 3-3
WML servlets 6-4
X
XHTML servlets 6-4
XML servlets 6-4
Z
ZIP files

applet archive attribute 4-3