Web Application Server on C Series Controllers Overview
The SRC software on a C Series Controller includes a Web application server that hosts the Web Services Gateway and the Volume Tracking Application (SRC VTA). In production environments, this application server is designed to host only these applications. However, you can load your own applications into this server for testing or demonstration purposes.
By default, the SRC Web application server listens on port 8080 for HTTP connections on the eth0 interface (interface to the trusted network) and on the configured ports for HTTP and HTTPS connections on the eth1 interface (interface to the untrusted network).
You can control access to applications deployed in the Web application server by configuring virtual hosts. A virtual host contains aliases and lists of the clients that are allowed to access the virtual host.
The aliases are DNS names or IP addresses that appear in the host part of the URLs used by clients to access a Web application. When the Web application server receives a request for an application, it searches for the virtual host with the alias that matches the host in the URL. If a virtual host is found, the Web application server verifies that the application is deployed on this virtual host and the client making the request is allowed to access the virtual host. If no virtual host is found, or if access to the application or client is not allowed by the virtual host, the request is rejected and the client receives an error code.
By default, SRC applications use the virtual host eth0. You must configure this virtual host and the following aliases:
The IP address assigned to eth0.
The name for the SRC host configured at the [edit system host-name] and [edit system domain-name] hierarchy levels.
For this reason, if you want to access the eth0 virtual host with URLs containing the DNS name of your SRC host, you must configure your SRC hostname in your DNS server.
You configure the built-in applications, such as Dynamic Service Activator, to deploy the application to a specific virtual host. Other applications that you can load for demonstration purposes are automatically deployed on the built-in virtual host eth0.
The SRC Web application server supports clustering, which provides reliability through failover and load balancing. The nodes in the cluster automatically discover one another on startup and automatically synchronize their state with the rest of the group. The cluster configuration is part of the shared SRC configuration and is stored in the Juniper Networks database. You can configure several Web application server clusters. However, a single SRC Web application server instance belong to only one cluster; it cannot belong to more than one cluster.
Local and Shared Configuration
If you want a Web application server instance to be part of a cluster, you need to specify the cluster name in the local configuration by using the [edit slot 0 application-server] configuration statement. This statement points to the shared configuration stored in the Juniper Networks database. The Web application shared configuration is specified using the [edit shared application-server cluster cluster-name] configuration statement.
Storing the cluster configuration in the Juniper Networks database ensures that all nodes in the cluster share the same configuration, including the unique identifier of each node, and the shared cluster name. All nodes must be specified within the same Juniper Networks database community name.
The configuration of the application server cluster lists the information about each application server node. When the application server is started, the system retrieves the shared application server cluster configuration and generates the appropriate startup script for the application server node. If no cluster is defined, the application server is started in “all” mode, but without the cluster parameters.
If you change the shared-cluster configuration, you must restart the local Web application server.
By default, the intra-cluster communication is done through multicasting and UDP is used as the channel stack protocol. If multicasting is not an option for deployment, you can use TCP as the channel stack. The shared cluster configuration is valid only if the following conditions are fulfilled:
The multicast-address is configured and either the channel stack is not set (the system uses UDP by default) or the channel stack is set to UDP.
The channel stack is set to TCP and the multicast-address is not configured.