Understanding Web Server 7.0

Web Server includes a new administration framework that provides enhanced
distributed management across servers in a server farm. Robust administration
capabilities enable Web Servers to be managed and deployed remotely using
both graphical and command-line interfaces. Servers can be managed on a central
location in a server farm and distributed to one or more nodes to create server
instances. Monitoring and lifecycle management of these server instances are
also provided.

Web Server is configured to enable you to turn on or off various features,
determine how to respond to individual client requests, and write programs
that run on and interact with the server’s operation. The instructions
(called directives) that identifies these options are stored in configuration
files. Sun Java System Web Server reads the configuration files on startup
and during client requests to map your choices with the desired server activity.

For more information about these files, see the Sun Java System Web
Server 7.0 Administrator’s Configuration File Reference Guide.

In Web Server 7.0 all configurable elements of a server instance like
web applications, configuration files, and search collection indexes are logically
grouped and termed as a Configuration.
A Configuration can be created, modified or deleted using CLI or the web based
administration interface. You can manage more then one Configuration at a
time. The term Configuration also refers to the set of metadata that configures
the runtime services of the server. For example, a runtime service serves
web pages from a configured document root. The configuration metadata is used
by the server runtime to load built-in services, third party plug-ins and
setup other server extensions such as database drivers for serving web pages
and dynamic web applications.

Note –

All the Configuration related files are stored in a repository
in your file system called as Configuration Store.
You must refrain from manually editing any of the files in this repository
unless explicitly specified in this guide.

In Web Server, any
change to the Configuration using the CLI or through the web based administration
interface is first made to the Configuration Store and then the Configuration
is deployed. Consequently the changes are copied to the instance directory.
When a web application is deployed it gets deployed under:

When you deploy a configuration, the entire web application directory
and configuration directory under config-store is zipped
up and copied to the server instance directory. This file is the current.zip file under:

<install_dir>/admin-server/config-store/<config_name>

Hence depending on the size of the web application, deploying a selected
configuration might take some time to complete.

The following figure shows a schematic diagram of how Configurations
are deployed to Administration Nodes:

When you deploy a Configuration to a Node (Network
resource, such as server or a host), an Instance of
that Configuration is created. The instance contains log files and other runtime
files such as lock databases, caches and temporary files that are required
by the instance. You can manage these instances through the CLI or web based
administration interface.

Instances can also span across one or more nodes to form a Cluster. In case of a cluster, all nodes that form
the cluster must have identical configuration. All nodes in a cluster must
be homogenous. They must have the same operating system, be identically configured,
and offer the same services.

One node in the server farm has a server running on which the administration
application is deployed. This specially configured server is called the Administration Server and the administration application
that is deployed is the web based Administration Console.
You use the Administration Console to control the lifecycle of your server
instances.

The Administration Server controls the actions of other servers in that
node called as Administration Nodes. An
administration node does not provide a GUI interface. One node in the server
farm has the Administration Server installed. All other nodes in the server
farm have Administration Nodes installed. An administration Node is registered
with an Administration Server upon installation. This action will make the
Administration Server aware of that Administration Node.

The Administration server and the administration node always communicate
over SSL. The Administration Server and Administration Node authenticate each
other by the Administration Server trusting the Administration Node's server
certificate and the Administration Node trusting the client certificate presented
by the Administration Server. During registration of an Administration Node,
the Administration Server will generate a server certificate for that Administration
Node, which is then downloaded and installed on the Administration Node. The
issuer of the server certificate is also installed on the Administration Node.