Oracle WebLogic Server is a scalable, enterprise-ready Java EE application server. It implements the full range of Java EE technologies, and provides many more additional features such as advanced management, clustering, and Web services. It forms the core of the Oracle Fusion Middleware platform, and provides a stable framework for building scalable, highly available, and secure applications.
This chapter contains the following sections:
Managed Servers host business applications, application components, Web services, and their associated resources. To optimize performance, managed servers maintain a read-only copy of the domain's configuration document. When a managed server starts up, it connects to the domain's administration server to synchronize its configuration document with the document that the administration server maintains. Oracle Fusion Middleware system components (such as SOA, WebCenter, and Identity Management components), as well as customer-deployed applications, are deployed to managed servers in the domain. During configuration, some managed servers are created specifically to host the Oracle Fusion Middleware system components (for example, wls_soa, wls_portal, and wls_forms).
Figure 5-1 shows a simple scenario of the Oracle WebLogic Managed Server. In the left side of the image, the Forms servlet renders the start HTML file and provides the information about the Forms Listener servlet to the client. An HTTP request is then received by the Oracle HTTP Server Listener, which passes it off to the Forms Listener servlet running inside Oracle WebLogic Managed Server, in the right side of the image. The Forms Listener servlet establishes a runtime process and is responsible for on-going communication between the client browser and the runtime process. As more users request Oracle Forms sessions, the requests are received by the Oracle HTTP Server Listener. The HTTP Listener again passes them off to the Forms Listener servlet, which establishes more runtime processes. The Forms Listener servlet can handle many Forms runtime sessions simultaneously. While there is, of course, a limit to the number of concurrent users, the architecture presents a number of opportunities for tuning and configuration to achieve better performance (see the next section).
By default (out-of-the-box installation), the Forms Services Java EE application (
formsapp.ear) is deployed on Forms Managed Server (
WLS_FORMS). You can manage
formsapp.ear using Oracle WebLogic Administration Console or Oracle Enterprise Manager Fusion Middleware Control. Refer to the following topics for more information:
Deploying Forms Application to Forms Managed Server: For more information, refer to "Install an Enterprise application" in WebLogic Administration Console Online Help. For information on deploying, undeploying, and redeploying applications, see "Deploying Applications" in Oracle Fusion Middleware Administrator's Guide.
Expanding Forms Managed Server Clusters: For more information, refer to Section 5.2.1, "Expanding Forms Managed Server Clusters".
weblogic-application.xml post deployment: For more information, refer to Section 5.2.2, "Modification of Forms J2EE Application Deployment Descriptors".
Starting Forms Managed Server as a Windows Service: For more information, refer to "Setting Up a WebLogic Server Instance as a Windows Service" in Oracle Fusion Middleware Managing Server Startup and Shutdown for Oracle WebLogic Server.
To improve the scalability and performance of Forms deployments on high-end machines (multiprocessor and high-memory configuration machines), expand the Forms Managed Server cluster (
cluster_forms). Perform the following manual steps to expand the Forms Managed Server cluster:
Perform the following steps to add a new Managed Server to the cluster (
Using the Oracle WebLogic Server Administration Console, you can choose to either clone the default Forms Managed Server (
WLS_FORMS) or create a new Managed Server (for example,
WLS_FORMS_1, with port number 9010).
In the Server Properties page, add the newly created Managed Server to the Forms cluster
In the General Tab, assign a port number to the Managed Server.
Assign a machine to the Managed Server.
Perform the following steps to edit the configuration of the new managed server:
Using the Oracle WebLogic Server Administration Console, in the Server Start Tab, set the following Server Start properties.
Add the following system properties without any carriage returns to the arguments:
-Dclassic.oracle.home=<ORACLE_HOME location>-Doracle.instance=<ORACLE_INSTANCE location>-Doracle.instance.name=<ORACLE_INSTANCE Name>
Add the following to the CLASSPATH:
Activate the changes and start the new Managed Server.
Add the new Managed Server's host and port information to the WebLogicCluster entry in
WebLogicCluster <HostName>:9001, <HostName>:9010
Post-deployment, Forms J2EE application deployment descriptors (
weblogic-application.xml) cannot be modified in Oracle WebLogic Server.
As a workaround, perform the following steps to customize the Forms J2EE application deployment descriptors and redeploy the application:
Back up the default formsapp deployment plan,
Add the deployment descriptors customizations to the Forms J2EE application's deployment plan. See the "Modifying the Deployment Plan" for an example.
Note:For more information on updating the deployment plan, refer to the Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server.
Using the WebLogic Administration Console, update the forms application (redeploy) and select the option Update this application in place with new deployment plan changes.
Restart the Forms J2EE application using the WebLogic Administration Console.
In this example, the deployment plan is modified to override the Forms Servlet
testMode parameter and set it to true. To modify the deployment plan, perform the following steps:
Enter the following commands:
mkdir –p $CLASSIC_ORACLE_HOME/forms/j2ee/backup cd $CLASSIC_ORACLE_HOME/forms/j2ee cp $DOMAIN_HOME/deploymentplans/formsapp/11.1.1/plan.xml backup/ vi $DOMAIN_HOME/deploymentplans/formsapp/11.1.1/plan.xml
Modify the deployment plan. The following is a sample of the deployment plan with the added entries highlighted in bold:
<?xml version='1.0' encoding='UTF-8'?> <deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd" global-variables="false"> <application-name>formsapp</application-name> <variable-definition> <variable> <name>vd-/scratch/t_work/Oracle/Middleware/as_1/forms</name> <value>/scratch/t_work/Oracle/Middleware/as_1/forms</value> </variable> <variable> <name>vd-/scratch/t_work/Oracle/Middleware/user_projects/domains/ClassicDomain/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config/forms</name> <value>/scratch/t_work/Oracle/Middleware/user_projects/domains/ClassicDomain/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config/forms</value> </variable> <variable> <name>FormsServlet_InitParam_testMode</name> <value>true</value> </variable> </variable-definition> <module-override> <module-name>formsapp.ear</module-name> <module-type>ear</module-type> <module-descriptor external="false"> <root-element>weblogic-application</root-element> <uri>META-INF/weblogic-application.xml</uri> </module-descriptor> <module-descriptor external="false"> <root-element>application</root-element> <uri>META-INF/application.xml</uri> </module-descriptor> <module-descriptor external="true"> <root-element>wldf-resource</root-element> <uri>META-INF/weblogic-diagnostics.xml</uri> </module-descriptor> </module-override> <module-override> <module-name>formsweb.war</module-name> <module-type>war</module-type> <module-descriptor external="false"> <root-element>weblogic-web-app</root-element> <uri>WEB-INF/weblogic.xml</uri> <variable-assignment> <name>vd-/scratch/t_work/Oracle/Middleware/as_1/forms</name> <xpath>/weblogic-web-app/virtual-directory-mapping/[url-pattern="java/*"]/local-path</xpath> </variable-assignment> <variable-assignment> <name>vd-/scratch/t_work/Oracle/Middleware/as_1/forms</name> <xpath>/weblogic-web-app/virtual-directory-mapping/[url-pattern="webutil/*"]/local-path</xpath> </variable-assignment> <variable-assignment> <name>vd-/scratch/t_work/Oracle/Middleware/user_projects/domains/ClassicDomain/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config/forms</name> <xpath>/weblogic-web-app/virtual-directory-mapping/[url-pattern="registry/*"]/local-path</xpath> </variable-assignment> </module-descriptor> <module-descriptor external="false"> <root-element>web-app</root-element> <uri>WEB-INF/web.xml</uri> <variable-assignment> <name>FormsServlet_InitParam_testMode</name> <xpath>/web-app/servlet/[servlet-name="frmservlet"]/init-param/[param-name="testMode"]/param-value</xpath> </variable-assignment> </module-descriptor> </module-override> </deployment-plan>
Using the WebLogic Administration Console, update the Forms J2EE application deployment (formsapp (11.1.1)). For more information on redeploying Forms J2EE application, refer to Oracle Fusion Middleware Administrator's Guide.
Restart the Forms J2EE application using the WebLogic Administration Console.
The steps for tuning the Forms Listener servlet are similar to steps for tuning any high throughput servlet application. You have to take into account resource management and user needs for optimal tuning of your particular Forms Services configuration. For more information, see Oracle Fusion Middleware Performance Guide available on OTN at
To control spawning HTTPD processes (which is memory consuming) set the KeepAlive directive in the Oracle HTTP Listener configuration file (
KeepAlive specifies whether or not to allow persistent connections (more than one request per connection). If you must use
KeepAlive On, for example, for another application, make sure that
KeepAliveTimeout is set to a low number for example, 15 seconds, which is the default. The KeepAlive setting is used to maintain a persistent connection between the client (Browser) and the OHS server. It does not have anything to do with the OHS to Oracle WebLogic Server connection.
You can let the HTTP Listener determine when to create more HTTPD processes. Therefore, set the
MaxClients directive to a high value in the configuration file (
httpd.conf). However, you need to consider the memory available on the system when setting this parameter.
MaxClients=256 indicates that the listener can create up to 256 HTTPD processes to handle concurrent requests.
If your HTTP requests come in bursts, and you want to reduce the time to start the necessary HTTPD processes, you can set
httpd.conf) to have an appropriate number of processes ready. However, the default values of 5 and 10 respectively are sufficient for most sites.
The Forms Listener servlet architecture allows you to load balance the system using any of the standard HTTP load balancing techniques available.
The Oracle HTTP Server Listener provides a load balancing mechanism that allows you to run multiple WebLogic instances on the same host as the HTTP process, on multiple, different hosts, or on any combination of hosts. The HTTP Listener then routes HTTP requests to Oracle WebLogic Managed Server instances.
The following scenarios are just a few of the possible combinations available and are intended to show you some of the possibilities. The best choice for your site will depend on many factors.
For a complete description of this feature, refer to the Oracle Fusion Middleware Performance Guide (available on OTN at
The following images illustrate four possible deployment scenarios:
Figure 5-2 shows the Oracle HTTP Server balancing incoming requests between multiple Oracle WebLogic Managed Servers on the same host as the Oracle HTTP Listener.
Figure 5-3 shows the Oracle HTTP Server balancing incoming requests between multiple Oracle WebLogic Managed Servers on a different host to the Oracle HTTP Listener.
Figure 5-4: shows the Oracle HTTP Server balancing incoming requests between multiple Oracle WebLogic Managed Servers on multiple different hosts and multiple different hosts each running an Oracle HTTP Listener.
Figure 5-5: shows the Oracle HTTP Server balancing incoming requests between multiple Oracle WebLogic Managed Servers on a single host but with multiple different hosts each running an Oracle HTTP Listener.
For more information about tuning and optimizing Forms Services with the HTTP Listener and Oracle WebLogic Server, see Oracle Fusion Middleware Performance Guide, available on Oracle Technology Network (OTN) at
Using HTTPS with Oracle Forms is no different than using HTTPS with any other Web-based application. HTTPS requires the use of digital certificates (for example, VeriSign). Because Forms Services servlets are accessed via your Web server, you do not need to purchase special certificates for communications between the Oracle Forms client and the server. You only need to purchase a certificate for your Web server from a recognized certificate authority.
The default configuration as set up by the Oracle Fusion Middleware installation process supports authenticating proxies. An authenticating proxy is one that requires the user to supply a username and password in order to access the destination server where the application is running. Typically, authenticating proxies set a cookie to detect whether the user has logged on (or been authenticated). The cookie is sent in all subsequent network requests to avoid further logon prompts.
The codebase and server URL values that are set up by the Oracle WebLogic Server installation process include
/forms/lservlet. As these are under the document base of the page (
$ORACLE_HOME/forms), authenticating proxies will work.
Create a Wallet to manage certificates.
Enable the HTTPS port in Oracle HTTP Server. By default, Oracle HTTP Server has one SSL Port enabled (8890).
Enable Web Cache to accept HTTPS connections from Oracle HTTP Server.
Note:When you change the Oracle Web Cache port using Enterprise Manager, regenerate the
osso.confand copy the generated
$ORACLE_INSTANCE/config/OHS/<OHS_INSTANCE>/moduleconfdirectory. Restart the Oracle HTTP Server and Oracle Web Cache for the changes to take effect.
Running a Forms application that uses an HTTPS port requires a certificate to be imported. If Oracle Forms is behind a load balancing router, and SSL terminates at it, you need to import the certificate from the load balancing router.
Start a Web browser and enter the Forms application HTTPS URL containing the fully qualified host name (including port number if required) used by your own Oracle installation. For example:
The Security Alert dialog box is displayed.
Click View Certificate.
Click the Details tab in the Certificate dialog.
Click Copy to File...
In the Welcome page of the Certificate Export Wizard, click Next.
In the Export File Format page, select Base-64 encoded X.509 (.CER), then click Next.
Enter a file name such as
c:\temp\forms, then click Next.
A message appears saying that the export was successful.
Close the Certificate Export Wizard, but keep the Security Alert dialog open.
Import the security certificate file that you saved earlier into the certificate store of the JVM you are using. For more information, see the next section.
At the Security Alert dialog, click Yes to accept the security certificate and start the Forms application.
On the client machine, open the Control Panel.
Navigate to Securities tab.
Import the certificate that was exported in the previous section.