Oracle 9Ias Forms Deployment
Total Page:16
File Type:pdf, Size:1020Kb
Oracle9i Forms Services Deployment : Multiple OC4J Instances
ORACLE9i FORMS SERVICES DEPLOYMENT : MULTIPLE OC4J INSTANCES
Inderpal S. Johal, PR Newswire
INTRODUCTION This paper is a detailed discussion on the deployment options available for Forms Services. It will give full details and steps to create multiple OC4J instances for Forms deployment. This is very good feature for Oracle 9iAS release 2 to create multiple OC4J instances like to implement both Dev and Test environment of Forms application in single installation of 9iAS. You will be able to know as how the bouncing of Dev OC4J instance will not affect the Test Instance users and vice versa. The document also gives the technical aspects of Oracle 9iAS Architecture, OC4J Architecture along with Oracle 9iAS Forms services architecture Oracle9iAS provides the latest in J2EE technology with it's J2EE 1.3 compatible server. It delivers the performance, scalability, high availability, security, and ease-of-use required to support e-Business today by providing full support for the J2EE platform, XML, and emerging Web services standards.
J2EE OVERVIEW Java2 Platform, Enterprise Edition (J2EE) has rapidly become the industry platform of choice for new enterprise computing applications. The J2EE component-based approach to the design, development, assembly, and deployment of enterprise applications produces applications that are more reusable, extendable, and adaptable. J2EE is built on the base of J2SE (Java 2 Standard Edition). Meaning that all of the advantages of J2SE are also available in J2EE. These advantages are Write once, run anywhere portability, JDBCTM API for database access, CORBA technology for interaction with existing enterprise resources, and a security model that protects data even in internet applications. J2EE extends this base by providing full support for Enterprise JavaBeans components, Java Servlets API, JavaServer Pages and XML technology. In order to achieve full J2EE compatibility, Oracle has enhanced its feature-rich application server product by including a compatible J2EE Server implementation, Oracle9iAS Containers for J2EE (OC4J). WHAT IS OC4J? Oracle9iAS Containers for J2EE (OC4J) is Oracle’s fast, lightweight, high performance, highly scalable, easy-to- use and fully certified J2EE Server implementation. The J2EE server, Oracle9iAS Containers for J2EE (OC4J), is J2EE 1.3 compatible and is written entirely in Java. It executes using the standard Java Development Kit (JDK) virtual machine. Applications residing in OC4J are completely portable and can therefore be deployed to any J2EE-compliant application server. The latest release of OC4J, 9.0.3, provides a fully J2EE 1.3 certified environment.
Page 1 Paper 36636 Oracle9i Forms Services Deployment : Multiple OC4J Instances
OC4J is based on technology licensed from Ironflare Corporation, which develops the Orion server--one of the leading J2EE containers. Although OC4J is integrated with the Oracle9iAS infrastructure, the product and some of the documentation still contains some reference to the Orion server.
Oracle9iAS Containers for J2EE is distributed in two different ways - as a pure Java standalone distribution, and as a part of the full Oracle9iAS product.
The pure Java standalone distribution is ideally suited for use in development and testing environments, as well as small scale production systems. It is distributed as single zip file and can be easily downloaded and installed. It is configured and managed through the manual manipulation of a set of simple XML files. In this usage model, OC4J runs as a single process, and HTTP requests are processed directly by the J2EE container itself.
For large scale production systems which require the use of a world class HTTP server, single-sign-on capabilities for security, automatic process management for system availability, and browser based server management, Oracle9iAS Containers for J2EE can be used within the Oracle9iAS product environment. Oracle9iAS Containers for J2EE is tightly integrated with the entire Oracle9iAS technology stack. In this configuration, server management and application deployment is performed using the HTML console of Enterprise Manager. Incoming HTTP requests are serviced with Oracle HTTP Server, and processes are managed automatically by the high availability services provided in Oracle9iAS.
Both of these usage models use the same Oracle9iAS Containers for J2EE code therefore providing a consistent level of J2EE support. This enables developers to use the standalone distribution to develop and test applications, and then deploy the completed applications to Oracle9iAS, safe in the knowledge that the two environments are compatible with one another.
OC4J ARCHITECTURE The OC4J Architecture uses the Oracle Http Server and a module called mod_oc4j to forward HTTP requests to the OC4J Server (see Diagram below).
Page 2 Paper 36636 Oracle9i Forms Services Deployment : Multiple OC4J Instances
ORACLE HTTP SERVER AND MOD_OC4J
The following describes the architecture during an HTTP Request where mod_oc4j sits within Oracle HTTP Server and perform the following actions 1. Identifies the requests it needs to act on, 2. Determines which OC4J to route those requests to, and 3. Communicates with that process.
I dentifies the requests Every J2EE based (web) application, when deployed, needs to be associated with a root context. This root context (i.e. URL prefix) acts as the identifier of requests that need to be handled by mod_oc4j. Client sends an HTTP request to the OC4J server. For example: http://myserver.com/j2ee/HelloWorldServlet Oracle HTTP Server determines from the URL which modules are configured for this request. In this case, the Oracle HTTP Server resolves that mod_oc4j is responsible for this request, because the /j2ee virtual path is mapped to the OC4J server. This mapping can be configured in either the httpd.conf or mod_oc4j.conf configuration file present in $ORACLE_HOME/Apache/Apache/conf directory.
Determines which OC4J The mod_oc4j routing algorithm for stateless requests is simple round robin. If this is a new request (with no valid routing cookie), it picks the next OC4J process from the list as the destination. If an attempt to send the request to that OC4J process fails, mod_oc4j picks the next process from the list, until all OC4J processes in that instance are exhausted. And if so, it returns failure to the client. If it is a request with a valid routing cookie, the cookie already identifies the process to route to uniquely. This target process is changed only if the target OC4J process is dead. In that case, mod_oc4j picks the next OC4J process from the same island and routes to it.
Communicates with OC4J mod_oc4j then contacts OC4J using Apache JServ Protocol (AJP 1.3). AJP is the protocol used to communicate between a Web server module and the servlet engine over a TCP socket. Mod_oc4j analyzes the response from OC4J and takes appropriate actions - ex. If a single sign on redirect is required. The request is then executed in the context defined in the OC4J server and the response is sent back to the client.
NOTE: OC4J EJB clients can also communicate using Oracle Remote Method Invocation (ORMI). RMI allows an object running in one Java Virtual Machine (VM) to invoke methods on an object running in another Java VM. RMI provides for remote communication between programs written in Java.
Page 3 Paper 36636 Oracle9i Forms Services Deployment : Multiple OC4J Instances
WHAT IS ORACLE 9IAS FORMS SERVICES Oracle 9iAS Forms Services is the collective name for the Forms components used to deploy a forms application on the web. These components are The Forms Services Web client, a generic Java applet that, after being loaded, renders any number and sizes of Forms applications The Forms Servlet, accepting incoming Web requests and returning the Forms applet HTML start page The Forms Listener Servlet, dispatching the communication between Forms generic Java client and the runtime process on the middle-tier server The Forms Web runtime, executing the business logic stored in Forms application modules and performing the database connect. Oracle Containers for J2EE (OC4J) is the powerful new servlet engine in Oracle 9iAS. Forms services support the servlet engine by using the new Apache mod_oc4j module. This module integrates the OC4J servlet engine with Apache, as did Apache Jserv previously
ORACLE 9IAS FORMS SERVICES ARCHITECTURE Broadly speaking, the two main components of Oraclei9iAS that concern us here are the HTTP Server and Forms Services. Forms Services is itself comprised of two sub-components: the Forms servlets and the Forms Runtime Processes. Here is the list: HTTP Server Forms Services: o Forms Servlet + Forms Listener Servlet (Both of these run in the OC4J Servlet Engine) o Forms Runtime Processes
The principles are as follows: 1. The two components of Forms Services must reside on the same server. Namely, the Forms Servlet and the Forms Listener Servlet must be on the same machine as the Forms Runtime Processes they interact with. These servlets run in the OC4J Servlet Engine. 2. The HTTP Server and Forms Services can be on the same machine, or separate machines. 3. The HTTP Server should point to any of OC4J Servlet Engines where you want Forms to run. This is done in MOD_OC4J, which is contained in the HTTP Server.
The Figure below shows how Oracle Forms on the web is deployed using a three-tier architecture: The Client Tier The Application Tier or Middle Tier The Database Tier
Page 4 Paper 36636 Oracle9i Forms Services Deployment : Multiple OC4J Instances
THE CLIENT TIER The Forms Client is a thin 100% Java Applet that runs in the user's browser. Anyone with a Java-enabled browser can run a Forms application, over any network: Internet, intranet, or extranet. It receives messages from the server about what to display, and reports back to the server what actions the user performed, so they can be processed. No business logic is executed on the client; it is responsible for rendering the screen. All logic is processed on the application tier.
When a user runs a Forms session, Java Applet - dynamically downloaded from the Oracle9i Application Server. This Java applet is used for any Forms application, therefore it is downloaded only once and cached on the client and so is available for subsequent Forms applications and is renewed automatically only when a new Forms client version is detected on the Application server.
In order to run a Java applet in a browser, it is necessary to have a Java Virtual Machine (JVM) installed. Depending on the client platform the browser is running, we are supporting the following JVMs: Windows32 o Oracle JInitiator (with Netscape and Internet Explorer) o Internet Explorer 5.x native JVM Macintosh o Apple MRJ 2.2.3 (with Internet Explorer 5.0) Solaris o Sun JDK and Java plug-in
Page 5 Paper 36636 Oracle9i Forms Services Deployment : Multiple OC4J Instances
The Oracle JInitiator provides these major benefits: Allows the latest Oracle-certified JVM to run in older browser releases. Ensures a consistent JVM between different browsers. Provides functional extensions to the basic JVM such as HTTPS/SSL support. Provides a reliable deployment platform. Oracle JInitiator has been thoroughly tested and certified for use with the Oracle9iAS Forms Services and for Oracle Applications E-Business suite. JInitiator is the preferred deployment environment. Application class files are automatically cached by JInitiator, providing faster application startup. JInitiator is a self-installing and self-updating deployment environment.
THE APPLICATION TIER The Forms Client communicates to the Forms Runtime process, not directly, but via the HTTP Listener within Oracle9iAS. By default, HTTP communication is used, but you may configure Oracle9iAS to use SSL (HTTPS) for secure networking.
The application tier is made up of following major Forms components, which are discussed in details in the Forms Services in Action 1. Forms Servlet 2. Forms listener Servlet 3. Forms runtime processes
THE DATABASE TIER The database typically runs on a dedicated machine, or on a cluster of machines. A Forms application will usually connect to one database instance. However there may be many different Forms applications running on the one Application Server, each connecting to a different database.
Page 6 Paper 36636 Oracle9i Forms Services Deployment : Multiple OC4J Instances
INTERACTION BETWEEN THE FORMS CLIENT AND FORMS SERVICES
1. The user starts up their Web browser on the Client Tier and call he Forms application by using the URL like the following http://devindy.prnewswire.com:7780/forms90/f90servlet
2. Oracle HTTP listener receives the request. OHS forwards the request to OC4J, since the path "/forms90/f90servlet" matches one of the OC4J mount directives in the $ORACLE_HOME/forms90/server/forms90.conf file (the one for the Forms Servlet as shown below).
# Config. for OC4J
OHS passes the request to the OC4J server through the mod_oc4j module using Apache Jserv Protocol (AJP). Each OC4J process needs one port for AJP13 communication with mod_oc4j. These ports are specified in the opmn.xml file, which is located in ORACLE_HOME/opmn/conf/ directory.. AJP is faster than HTTP, through the use of binary formats and efficient processing of message headers.
Fig. HTTP Application Listener
3. OC4J maps the request to the Oracle9i Forms application (whose context root is /forms90). It read the Forms servlet setting in the web.xml and finds the alias match for the Forms Servlet (f90servlet). Then it checks the parameter "configfilename" in web.xml(by default it is formsweb.cfg). Check the Note:219822.1 on Metalink if you want to change the name for the servlet from f90servlet to something else
Web.xml is available in
Default web.xml File
Page 7 Paper 36636 Oracle9i Forms Services Deployment : Multiple OC4J Instances
4. The Forms Servlet (running in OC4J Servlet Engine) processes the request as follows: a. Opens the servlet configuration file (formsweb.cfg by default). If the parameter configFileName is not set in above web.xml, the default configuration file (
Browser detected IE parameter Setting Base HTML file used
Internet Explorer 5.x or 6* Native VM baseie.htm Internet Explorer 5.x or 6* jinitiator basejini.htm Netscape Navigator or Internet Explorer not applicable basejini.htm version preceding version 5
All other browsers Not applicable base.htm * Internet Explorer 6 that has been upgraded from 5.5 only (IE 6 is not certified in the base release)
d. Finally Reads the baseHTML file, and sends the contents back as dynamically generated HTML page to the user's Web browser, after doing variable substitution as follows: i. Whenever a variable (like %myParam%) is encountered, the Forms Servlet looks for a matching URL query parameter (for example, &myParam=xxx), or, failing that, looks for a matching parameter in the formsweb.cfg file. If a matching parameter is found, the variable (%myParam%) is replaced with the parameter value. For example, the baseHTML file contains the text %form%. In our example, this is replaced with the value "test" as defined in formsweb.cfg file with “form=test.fmx” in the default section.
5. Depending on which baseHTML file the Forms Servlet selected, the dynamically generated HTML page sent back to the Web browser will contain an Applet, Object or Embed tag to start up the Forms applet (thin client). The Forms applet runs in a JVM (either the Web browser's native JVM, or a "plugged in" JVM like Oracle JInitiator or Sun's Java plug-in)
6. If the baseHTML file selected was for a plug-in (Oracle JInitiator or Sun's JDK Java plug-in), and if the user does not already have that plug-in installed on their machine, they are prompted to install the plug-in. In the case of JInitiator, the download location is under the virtual path /forms90/jinitiator (a virtual path defined in the forms90.conf file).
7. In order to start up the Forms applet, its Java code must first be loaded. The Browser then asks the HTTP Listener for the Java Class files from the location specified in the HTML file. The CODEBASE parameter in the HTML file is used to define this. The files may be downloaded individually or as an “Archive”. This archive will have an extension of .JAR and can be best thought of as a .ZIP file containing all of individual CLASS files required by the Applet. The ARCHIVE parameter defines which (if any) .JAR should be used.. For example, if the user is running with Oracle JInitiator, the applet code is loaded from the file http://devindy.prnewswire.com:7780/forms90/java/f90all_jinit.jar. Below is some portion of the Dynamically generated HTML file sent to Forms client browser