Ministry of Education and Advanced Education

OAS 10g High Level Architecture

And Functionality

Prepared by: Kieran Harrop

Prepared for: Ministry of Education and
Advanced Education

Document Number: 1.0

Version: 1.0

Last Updated: April 10, 2007

Creation Date: April 10, 2007
Table of Contents:
Table of Contents:............................................................................................................... 2
Purpose:............................................................................................................................... 4
Audience: ............................................................................................................................ 4
Terms and Concepts............................................................................................................ 4
Introduction..................................................................................................................... 4
The term “Landscape” .................................................................................................... 4
Tiers and Layers.............................................................................................................. 4
Public Web Server (Reverse Proxy Server).................................................................... 5
Application Servers......................................................................................................... 6
Database Server Connections ......................................................................................... 6
What Is a Farm? .............................................................................................................. 7
What Is an OracleAS Cluster? ........................................................................................ 7
High Level Architecture ..................................................................................................... 7
Architectural Review .................................................................................................... 11
Versions of OAS 10g .................................................................................................... 11
OAS 10g 10.1.2.0.2 (Forms, Reports, mod_plsql, Portal)................................................ 11
Oracle HTTP Server ..................................................................................................... 11
Oracle HTTP Server Components ............................................................................ 12
Oracle HTTP Server Architecture ............................................................................ 13
Oracle HTTP Server Features................................................................................... 15
Common Gateway Interface (CGI) Support ............................................................. 17
Oracle Application Server Containers for J2EE (OC4J) .............................................. 17
Introduction to J2EE Application Development....................................................... 17
Oracle Application Server Containers for J2EE Architecture .................................. 21
Oracle Application Server Containers for J2EE Features......................................... 22
Deploying an ear File................................................................................................ 26
Deploying the J2EE Application Using an existing OC4J Instance ......................... 27
Deploying JSP reports to a new OC4J instance........................................................ 28
Middle Tier Administrator Setup – Data Source Connection Pooling ..................... 29
Oracle Application Server Forms Services................................................................... 32
Oracle Application Server Forms Services Architecture.......................................... 32
Oracle Application Server Forms Services Features ................................................ 34
Oracle Application Server Reports Services................................................................. 34
Report Server Architecture ....................................................................................... 35
Middle Tier Administrator Forms/Reports/mod_plsql Middle Tier Setup – Example:
FREDS ...................................................................................................................... 37
Developer Forms/Reports/mod_plsql Middle Tier Setup – Example: FREDS ........ 41
Oracle Portal ................................................................................................................. 41
Introduction to Oracle Application Server Portal ..................................................... 41
Oracle Application Server Portal .............................................................................. 42
Oracle Instant Portal ................................................................................................. 43
Oracle Portal Architecture ........................................................................................ 43
 Portal Page Creation, Management, and Customization .......................................... 44
High Availability .............................................................................................................. 45
Requirements ................................................................................................................ 45
Introduction................................................................................................................... 45
Hardware Cluster .......................................................................................................... 46
Fail over ........................................................................................................................ 47
Primary Node ................................................................................................................ 47
Secondary Node ............................................................................................................ 47
Logical or Virtual IP ..................................................................................................... 47
Virtual Hostname .......................................................................................................... 47
Shared Storage .............................................................................................................. 48
The Ministry’s High Availability Configuration .......................................................... 48
Recommendations:........................................................................................................ 49
Fail over example:......................................................................................................... 49
Recommended Server Farms ........................................................................................ 51
Future Possibilities........................................................................................................ 52
Security Architecture ........................................................................................................ 52
Oracle HTTP Server Security Features......................................................................... 53
Access Control .............................................................................................................. 53
User Authentication and Authorization ........................................................................ 54
Firewalls, Proxy Servers and DMZ .............................................................................. 54
Mod_proxy.................................................................................................................... 55
How to implement tunnelling through Reverse Proxy ................................................. 55
To pass everything: ................................................................................................... 56
To pass only the mod_plsql requests: ....................................................................... 56
To hide a completely different server (such as an IIS application called xyzWeb): 57
Single Sign On (SSO) ................................................................................................... 57
Netegrity Siteminder..................................................................................................... 58
Secure Socket Layer (SSL)........................................................................................... 60
SSL Confidentiality .................................................................................................. 60
SSL Client Authentication ........................................................................................ 60
SSL Environment Variables ..................................................................................... 60
SSL Logging ............................................................................................................. 61
PKI Support .................................................................................................................. 61
Directory-Enabled Security via OID ............................................................................ 62
Java Security ................................................................................................................. 62
Secure Access to Oracle Database................................................................................ 63
Appendix A - Hardware/OS Details ............................................................................. 65
Appendix B - Architectural Review Forrester Research .............................................. 67
Appendix C - Oracle’s Linux Support .......................................................................... 68
Appendix D – Oracle Application server Port Numbers .............................................. 69
Appendix E – Oracle Application server Instances ...................................................... 75
Purpose:
To describe the high level architecture and new functionality of the OAS 10g middle tier
environment to aid in the ongoing maintenance of the middle tier environment.

Audience:
Middle tier administrators, database administrators, application architects, developers and
ITMB team leads.

Terms and Concepts

Introduction
This section describes the terms and concepts behind the Ministry’s Middle tier
architecture.

The term “Landscape”

For the purpose of this document we will use the term “landscape” to indicate a self
contained and encapsulated middle tier environment which is completely isolated from
all the other middle tier environments residing on the same server or hardware cluster.
A Landscape is a middle tier environment with special characteristics, with its own
Domain name system (DNS) entry, File system mount point (Each landscape’s mount
point must be a real disk partition and not an existing file system’s directory). The
executable code and log files of a landscape are distinct from other landscapes. In
addition it attempts to abstract the environment from any particular server name, disk
space configuration and location. In this context we will use terms like development
landscape, test landscape and production landscape meaning corresponding middle tier
environments with those special characteristics of complete isolation, encapsulation and
abstraction.

Tiers and Layers

The Enterprise applications will be deployed in an n-tier architecture, however, from a
high level perspective, the following 4 layers can be distinguished:
• Browser
• Public web server (Reverse Proxy)
• Oracle 10g application Server
• Oracle Database server

Oracle Application Server 10g provides a comprehensive application server environment

with many modules such as mod_plsql, mod_oc4j, mod_proxy, mod_ossl, forms service,
reports services and so on. Each module is specialized in providing a particular service,
for example mod_oc4j implements J2EE application containers.
The internal users (intra-net) may access these services directly whereas the external
users (Internet) will most likely reach them through a public web servers / web Cache
acting as reverse proxy server to hide the internal application servers as well as providing
Secure Socket Layer (SSL) encryption functionality.
The public web servers will be running Oracle 10g proxy services. The reverse proxy
server is exposed to the Internet and can provide SSL services when necessary. In the
case of applications with a great deal of static pages used by Internet users, and only a
few calls to Oracle Application Server 10g modules such as mod_plsql or report service,
the static pages may reside on the public web servers and only the requests to mod_plsql
or report server will be tunneled through to the application servers.

Public Web Server (Reverse Proxy Server)

This server is to represent external (Internet) users to the internal application servers and
is the public face of the Ministry’s applications. The following is how it should behave:

1. Receive requests from the external users

2. Determine which internal application server is the appropriate one to respond
to it (based on its internal proxy pass configuration directives)
3. Pass through (tunnel) the request to the appropriate internal application
server
4. Internal application servers are configured to accept requests originating
from the internal network as will as this reverse proxy server. They will ignore
requests from all other external sources. It is even possible to limit this
access to only certain parts of an internal application
5. Internal application server generates the response and sends it to the
reverse proxy server
6. Receive the response from the internal application server
7. Strip the internal server’s host name, IP address and all other revealing
information from the HTTP header and body and replaces them with its own
information so that as far as the external users are concerned there are no
internal application servers
8. Pass the updated response to the external users

It is entirely possible to serve certain public or static pages directly from the reverse
proxy server. In other words, this server can play two distinct roles at the same time:

• Reverse Proxy Server

• Public Web Server

For example, it can host a Ministry public web site and manage and serve all the static or
non-database related pages right from this server (public web server role) but any
requests for pages that need to be generated from databases, produce Oracle reports or
run in J2EE containers are transparently tunnelled through to an internal application
server and the responses are received and served back to the external user as if coming
from this server itself (reverse proxy role).
Another possibility is to use the caching capability of this server (provided by web cache
module) and greatly reduce the load on internal application servers. In this way a lot of
static or repeated requests aimed at internal application servers will be cached by this
server the first time and consequently served directly from the cache and not from the
internal application server.
Yet another advantage of this architecture is the ability to enable SSL (Secure Socket
Layer) encryption for the traffic between the reverse proxy server and external users.
The primary purpose of SSL is to encrypt and secure the communications over the
Internet and in general, due to its overhead and impact on performance, we do not want to
use it at the intra-net level. By limiting SSL on the traffic between the reverse proxy
server and the external users only, we can achieve secure Internet communications
without adversely affecting our internal users.
Although it is possible to use a free version of Apache HTTP server instead of Oracle
Application server 10g on this server (The current practice), we may find it preferable to
use a lightweight Oracle 10g instance instead. This is due to extensive 10g support by
Oracle and the fact that we will not need an extra set of expertise to deal with more than
one type of server. We can consider that option later on if the Oracle Licensing and the
Ministry’s budget allow such move, for the time being, the current configuration will do
fine.
If at some point there is a great demand to use Microsoft IIS as the public Web server, It
may be possible to use a specialized DLL written by Oracle in order to make the
Microsoft IIS act as reverse proxy server, This DLL currently exists, however this will
create a dependency on Oracle and assuming that it will keep this DLL up to date. Such
decision should only be taken after extensive tests and by accepting the extra risks
associated with such combination.

Application Servers

Application servers do the actual work. These servers support applications that require
services such as J2EE containers, web services, forms10g, Reports10g, Oracle Portal,
Discoverer, BI beans and PLSQL etc. They are based on Oracle Application server 10g
software.

Database Server Connections

Most of the Ministry applications running on the middle tier application servers will be
connected to and will be using the Oracle database servers. For most modules such as
mod_plsql, Forms servers and Report servers, depending on the version of Oracle
database server, we will use Oracle net8, net9 or later for communication. For the J2EE
applications, we use Oracle JDBC thin client libraries.
What Is a Farm?
A farm is a collection of clusters and instances that share the same Oracle application
server infrastructure.
When instances belong to a farm, we can manage them as a group and we can also cluster
them.
Oracle Application Server can store repository information in a database ("database-
based repository") or file system ("file-based repository"). Repository information
includes things such as the list of instances that belong to a farm, whether or not the
instances are clustered, and configuration information for clusters.
The repository for a file-based farm exists within a specific instance of a middle tier
instance Oracle Home. This instance is called the "repository host".
The repository for a database-based farm exists within the Metadata Repository.
We can set a J2EE and Web Cache instance to belong to a farm during or after
installation. If we are unsure during installation, we can install the instance as a
standalone instance (that is, not belonging to a farm). After installation, if we so desire,
we can associate the instance with a farm. Conversely, we can install an instance as part
of a farm and after installation; we can convert the instance to a standalone instance.

What Is an OracleAS Cluster?

We can cluster instances that belong to a farm. All the instances in a cluster have the
same configuration. Any instance in a cluster can handle requests directed to any cluster
member.
The installer does not cluster instances for us. We have to do this after installation.

High Level Architecture

The OAS 10g infrastructure consists of three two-node clustered environments (see
diagram 1 below). The three clustered environments with their corresponding servers are
…

1. mtsbx cluster
a. Hornby
b. Cortez
2. mtdev cluster
 a. Taku
b. Bighorn
3. mtprd cluster
a. Columbia
b. Fraser

Please see Appendix 1, Hardware/OS Details for more specific information for the
configuration of each cluster.

The following picture gives a logical high level view of the architecture:
 Middle Tier Architecture

INTERNET
Desktop Laptop PDA

FIRE WALL

DMZ
PUBLIC WEB
SERVERS
(Apache)
T
U
N
N
E FIRE WALL
L
INTERA-
NET
APPLICATION
SERVERS
(OAS 10g)

DATABASE
DATABASE SERVERS SERVERS

Figure 1 – Middle Tier Architecture – High level view

 Client Tier Gateway Tier Middle Tier Database Tier
GOLD Cluster Dean Cluster White Cluster

Public Gateway Application Server OLTP Tier

T Tier Tier
U
N Apache OAS 10g Oracle RDBMS
N mod_ssl HTTP Server Corporate
E
L mod_ sm Subject Area
Internet Client
mod_plsql
mod_ proxy Headstart

OC4J GAME

Portal Generic User

DMZ-Firewall Named User
Reports Server
Application
Forms Service
Data

Firewall LEGEND
Generic User = xxx_web
Intranet Client Named User = DB User (eg. jsmith)
Application = Code Repository (xxx_app)
Data = Data Repository (xxx)
where xxx = application acronym

Figure 2 – Middle Tier Architecture – Detailed View

Architectural Review

After it was discovered in a failed proof of concept that Reports Services would not run
on Tru64, it was decided to do an evaluation of the Middle Tier software and an
architectural review for the operating system, clustering software, and servers for all
ITMB servers. The outcome of that exercise was the decision to run OAS 10g, Redhat 4.0
and HP Service Guard for Linux running on HP Proliant servers. Please refer to
Appendix 2 Architectural Review Forrester Research for details.
Another factor which influenced our decision to go with Linux was that Linux was a tier
one and fully supported operating system for Oracle software. See Appendix 3 Oracle’s
Linux support for details.

Versions of OAS 10g

Currently we have two versions of OAS 10g in the middle tier environment.

1. OAS 10g 10.1.2.0.2 (Forms, Reports, mod_plsql, Portal)

2. OAS 10g 10.1.3 (J2EE) – this version of OAS 10g has none of the required Forms
and Reports functionality, but desirable functionality around J2EE. It does not use
the Infrastructure component to manage instance configuration metadata.
a. Greater stability: we experience instability of the OC4J in version
10.1.2.0.2 that is resolved in OAS 10g R3.
b. More flexibility with manageability.
c. Does not require the Infrastructure instance (DCM not required).
d. Uses higher version of JDK (1.5 rather than 1.4)

OAS 10g 10.1.2.0.2 (Forms, Reports, mod_plsql, Portal)

Oracle HTTP Server

Oracle HTTP Server is the underlying deployment platform for all programming
languages and technologies that Oracle Application Server supports. It provides a Web
Listener for Oracle Application Server Containers for J2EE (OC4J) and the framework
for hosting static and dynamic pages and applications over the Web. Based on the proven
technology of the Apache HTTP Server (version 1.3), Oracle HTTP Server includes
significant enhancements that facilitate load balancing, administration, and configuration.
It also includes a number of enhanced modules or mods, which are extensions to the
HTTP server that extend its functionality for other enterprise applications and services.
Oracle HTTP Server allows developers to program their sites in a variety of languages
and technologies, such as Java, Perl, C, C++, PHP, and PL/SQL. Additionally, it can
serve as either a forward or reverse proxy server. The following sections describe how
Oracle HTTP Server provides a deployment platform for web sites and applications.

Oracle HTTP Server Components

Oracle HTTP Server consists of several components that run within the same process.
These components provide the extensive list of features that Oracle HTTP Server offers
when handling client requests. Major components include the following:

• HTTP listener: Oracle HTTP Server is based on an Apache HTTP Listener to

serve client requests.
• Modules: Many of the standard Apache mods are included with Oracle HTTP
Server. Oracle also includes several internal modules that are specific to Oracle
HTTP Server components. The following lists some of the Oracle HTTP Server
modules.
• Perl Interpreter: A persistent Perl runtime environment embedded in Oracle
HTTP Server through mod_perl.

Prominent Oracle HTTP Server Modules

Module Description
mod_php Supports PHP version 4.3.9, an open source client-side scripting language
that is embedded in standard HTML.
mod_security Increases Web application security by protecting Web applications from
known and unknown attacks.
mod_fastcgi Supports FastCGI, which allows C, C++, and Java CGI programs to run in
a performant environment
mod_perl Routes requests to the Perl Interpreter
mod_plsql Routes requests for stored procedures to the database server
mod_oc4j Supports communication with Oracle Application Server Containers for
J2EE and also performs some load balancing tasks
mod_oradav Supports file as well as database distributed authoring and versioning
mod_ossl Supports Secure Sockets Layer (SSL) and certificate sharing
mod_osso Routes requests to Oracle Application Server Single Sign-On server
The following shows the path of various requests through Oracle HTTP Server
components.

Oracle HTTP Server Request Flow

Oracle HTTP Server Architecture

At startup, the Web server parent process loads the entire configuration and the
associated mods, and spawns a preconfigured number of child processes.

The following shows the process architecture of Oracle HTTP Server in a Linux
environment.

Oracle HTTP Server Process Architecture

The parent process does not listen to HTTP requests. Its sole job is to ensure that the
child processes are running or that new ones are started when the load requires it.

On UNIX platforms, each child process handles a single HTTP request. The child
processes determine who should take the next request based on a mutex mechanism that
you can configure.
Modular Architecture

As mentioned above, the architecture of Oracle HTTP Server is modular. The core HTTP
listener is very small, and all capabilities are implemented as modules that plug in and are
invoked at the appropriate place during the HTTP request lifecycle. The following shows
the lifecycle of an HTTP request in Oracle HTTP Server.

Oracle HTTP Server HTTP Request–Response Cycle

A child process guides the request through this entire lifecycle. The modules register their
application programming interfaces (APIs), which are then either invoked automatically
when the request reaches a certain stage in its lifecycle, or can be configured to be
invoked only in certain situations.

Oracle HTTP Server Features

In addition to the standard Web server functionality of serving client requests to other
Oracle Application Server components, Oracle HTTP Server provides the necessary
features for both creating dynamic applications and implementing enterprise support. It
also contains security enhancements that help protect important business resources. Key
features of Oracle HTTP Server include the following:

• PHP support through mod_php: Oracle HTTP Server now supports PHP
(recursive acronym for PHP: Hypertext Preprocessor), an open source, client-side
scripting language used to generate dynamic HTML pages. PHP support is
provided through mod_php.
• Increased application security with mod_security: mod_security is an
open source intrusion detection and prevention engine for Web applications,
which protects against known and unknown attacks.
• Security through Secure Sockets Layer: Secure Sockets Layer (SSL) is
required to run any Web site securely. Oracle HTTP Server supports SSL
 encryption based on patented, industry standard algorithms. SSL works with both
Internet Explorer and Netscape browsers. Oracle HTTP Server also provides
support for dedicated SSL hardware, session renegotiation, and communication
with OC4J using the AJP protocol over SSL.
• Single Sign On Support: Oracle HTTP Server supports the standard basic
authentication features of Web servers. In addition, the mod_osso module is
included to support single sign on across sites and across applications, improving
the end-user experience.
• Virtual Host Support: A virtual host is a Web site that may share its Web
server with other similar sites. Oracle HTTP Server provides a "container"
environment for a virtual host, providing the virtual host with its own set of
security and configuration directives. It also provides the location from which
files are served. This allows ISPs to save on hardware and administrative costs by
enabling multiple sites to be served from a single runtime instance of Oracle
HTTP Server. However, due to technology limitations, only one virtual host can
enable SSL.
• Dynamic monitoring services (DMS): These services automatically measure
runtime performance statistics for both Oracle HTTP Server and OC4J processes.
As applications run, DMS collects detailed performance statistics. This data
allows you to monitor the duration of important request processing phases and
status information. With this information, you can locate performance bottlenecks
and tune the application server to maximize throughput and minimize response
time.
• Request ID: To enhance request tracking through various components, a
request ID is now attached to each request. This provides more detailed
tracking information, allowing you to see how much time a particular
request spends in any component or layer.
• External API for performance monitoring: This API allows you to use
external, third-party performance monitoring tools to monitor Oracle
Application Server-based J2EE components, such as servlets and JSPs,
as well as J2EE containers.
• OC4J Plug-In: The OC4J Plug-In provides a way for you to use Apache
as well as the IIS and Sun ONE third-party listeners to access servlets
running in OC4J without having to use the Oracle HTTP Server as a
proxy. The OC4J Plug-In routes requests directly from the third-party
HTTP listener to OC4J.
• Oracle Application Server Single Sign-On Plug-in: This plug-in is the
Oracle single sign-on solution for third-party listeners such as Sun ONE
and IIS. The plug-in is designed to protect native third-party listener
applications using the single sign-on infrastructure. Using this plug-in, you
can be authenticated to different third-party listener applications using only
one password. You can integrate these protected third-party listener
applications with other single sign-on enabled applications as long as they
are all protected by the same single sign-on server.
Common Gateway Interface (CGI) Support

Requests that are sent to a common gateway interface (CGI) program may
invoke two new processes—the child process that handles the HTTP request
and the CGI program itself. It is possible to avoid this overhead by configuring
Oracle HTTP Server to pre-start child processes and keep them running,
leveraging the Perl module to run the CGI programs in memory, or using the
FastCGI mechanism.

Oracle Application Server Containers for J2EE (OC4J)

OC4J is a fast, lightweight, and scalable J2EE1.3 certified server implementation

that is written in Java and runs on a standard Java Virtual Machine (JVM). It has
been designed to support following APIs.

Oracle Application Server Containers for J2EE Supported APIs

API Version
JavaServer Pages (JSP) 1.2
Java Servlet 2.3
Enterprise JavaBeans (EJB) 2.0
Java Database Connectivity (JDBC) 2.0 Extensions
Java Transaction API (JTA) 1.0
Java Message Service (JMS) 1.0.2b
JavaMail 1.2
JavaBeans Activation Framework 1.0
Java API for XML (JAXP) 1.1
J2EE Connector Architecture 1.0
Java Authentication and Authorization Service (JAAS) 1.0

Introduction to J2EE Application Development

The following sections provide introductory definitions and summaries of

application programming technologies that Oracle Application Server supports.
For detailed information on the technologies introduced in this section, refer to
the following information sources.
 See Also:

• The official J2EE Web site at http://java.sun.com/j2ee

• The J2EE Tutorial at http://java.sun.com/j2ee/tutorial
• The Oracle Application Server Documentation Library

J2EE Application

A J2EE application is an application that is written in Java using the J2EE APIs. It
can be deployed, managed, and executed on a J2EE-compatible server. The
J2EE application itself is composed of a set of components, such as Web
presentation modules, business logic modules, and data access modules. Each
component is assembled into the overall application with all of its related classes
and XML deployment descriptors.

J2EE Distributed Multi-tiered Application Model

The J2EE platform provided in Oracle Application Server uses a multi-tiered

distributed application model. A multi-tiered distributed application model divides
application logic into components according to function, and the various
application components that make up J2EE applications can be installed on
different machines, depending on which tier in the multi-tiered J2EE environment
the application component belongs. The following shows two multi-tiered J2EE
applications divided into the client, Web, business logic, and data tiers.

J2EE Distributed Multi-tiered Application Architecture

You can distribute J2EE applications across the four tiers shown in this figure,
but generally they are considered to be three-tier applications because they are
usually distributed over the following machine locations:

• client machines
• J2EE Server machines hosting presentation services, like JSPs and
servlets, and business logic components, like EJBs
• database servers or legacy machines at the back end

Three-tiered applications that run in this way extend the standard two-tiered
client and server model by placing an application server between the client and
the back-end storage.

Types of J2EE Clients

J2EE applications support the following clients:

• Application Clients: Applications running on a client machine that directly

access enterprise beans that are running in the business logic tier.
Application clients can also open an HTTP connection to establish
 communication with a servlet running on the Web tier if a J2EE application
requires it.
• Dynamic HTML and XML Pages: In the context of J2EE applications,
dynamic HTML and XML pages are either generated by servlets or
created with JavaServer Pages technology running in the Web tier. These
pages can be extensions to traditional static HTML pages, allowing
application developers to offer customized and personalized pages to the
client.

Types of J2EE Application Components

You can use the following components in J2EE applications:

• Servlets: A servlet is a Java class that executes behind a Web server and
can extend the capability of the Web server to provide services for
dynamic page creation or application logic. The servlet works in the
standard HTTP request-response model.
• JavaServer Pages: JavaServer Pages (JSPs) are text files that contain
two types of information: static template data, which can be expressed in
any text-based format, such as HTML, XML, or WML (Wireless Markup
Language); and JSP elements, which construct dynamic content.
• Enterprise Beans: Enterprise beans are server-side components that
encapsulate the business logic of an application.

Types of J2EE Containers

A container provides the runtime support for J2EE application components.

Containers provide a federated view of the underlying J2EE APIs to the
application components. J2EE application components never interact directly
with other J2EE application components. They use the protocols and methods of
the container for interacting with each other and with platform services.
Interposing a container between the application components and the J2EE
services allows the container to transparently inject the services defined by the
components' deployment descriptors, such as declarative transaction
management, security checks, resource pooling, and state management.

Before a Web or enterprise bean component can run, it must be assembled into
a J2EE application and deployed into a J2EE container. The assembly process
involves specifying container settings for each component, which customize the
underlying support provided by the J2EE server. These settings can be standard
J2EE settings or container-specific settings, depending on your application
requirements. Some of the container settings that you can specify include
security services, transaction model, naming and directory lookup, and remote
connectivity model.

There are two primary types of J2EE container:

 • Enterprise JavaBeans Container: The Enterprise JavaBeans container
(EJB Container) manages the execution of all enterprise beans for J2EE
applications. Enterprise beans and their container run on the J2EE server.
• Web Container: Web components such as JSP pages and servlets are
managed and executed in the servlet container. The container provides
services such as request dispatching, security, concurrency, and life cycle
management. The Web container also gives web components, typically
JSPs and servlets, access to the J2EE APIs such as naming,
transactions, and JDBC.

J2EE Application Packaging Concepts

J2EE components are packaged separately and bundled into a J2EE application.
Each component, with its related files such as GIF and HTML files or server-side
utility classes, are packaged together with a deployment descriptor (DD), and are
assembled into a module that is added to the J2EE application. Typically, a J2EE
application is composed of one or more enterprise beans and Web or application
client component modules.

Oracle Application Server Containers for J2EE Architecture

The following shows the architecture of OC4J within Oracle Application Server.
OC4J is supported by the Java 2 Platform, Standard Edition (J2SE) infrastructure
as shown in. This means that the OC4J Web container and OC4J EJB use the
J2SE virtual machine. J2EE applications are modularized for reuse of application
components, such as:

• User interfaces, which can be composed of JavaServer Pages (JSPs),

dynamic HTML, and so on
• Business logic, which is usually contained in an Enterprise JavaBean
(EJB) or normal Java classes

The J2EE containers also perform services for applications, such as providing
access to the APIs and lifecycle management.

Oracle Application Server Containers for J2EE Features

Oracle Application Server Containers for J2EE (OC4J) has the following features.

Oracle Application Server Containers for J2EE Containers

OC4J supplies the following J2EE containers:

• A servlet container that complies with the servlet 2.3 specification

• A JSP container that complies with the Sun JSP 1.2 specification
• An EJB container that complies with the EJB 2.0 specification

Oracle Application Server Containers for J2EE Servlet Container

A servlet is a Java program that runs on a J2EE server, such as OC4J. A servlet
is one of the application component types of a J2EE application. It must execute
under the control of a servlet container, which is part of the OC4J Web container.
The servlet container calls the servlet's methods and provides services that the
servlet needs when running.

About the Servlet Container

The servlet container executes and manages servlets. It provides the servlet with
access to properties of the HTTP request, such as headers and parameters.
Also, the container provides the servlet with access to other Java APIs, such as
JDBC to access a database, remote method invocation (RMI) to call remote
objects, or JMS to perform asynchronous messaging.

How the Servlet Container Works

When a request is mapped to a servlet, the servlet container performs the
following steps:

1. If an instance of the servlet does not exist, the container does the
following:
a. Loads the servlet class
b. Instantiates an instance of the servlet class
c. Initializes the servlet instance
2. The container then invokes the servlet, passing request and response
objects. The request object contains information about the client, request
parameters, and HTTP headers. The response object returns the servlet's
output to the client.

The servlet extracts information from the client request, accesses external
resources, and then populates the response based on that information.

OC4J JavaServer Pages Container

JavaServer Pages provide a convenient way to generate dynamic content in

Web pages. JSP technology, which is closely coupled with servlet technology,
allows you to include Java code fragments and make calls to external Java
components (in the form of tags and directives) from within your Web pages.
Typically, the markup code used to compose your Web pages is HTML or XML.
JSPs work well as a front-end for business logic and dynamic functionality in
Java Beans or Enterprise JavaBeans (EJBs).

A JSP is translated into a Java servlet before being run, and it processes HTTP
requests and generates responses like any servlet. However, JSP technology
provides a more convenient way to code a servlet. Translation occurs the first
time the application is run. A JSP translator is triggered by the .jsp file name
extension in a URL.

JSPs are fully interoperable with servlets. You can include output from a servlet
or forward the output to a servlet, and a servlet can include output from a JSP or
forward output to a JSP.

About the JSP Translator

The JSP translator has a translator and a compiler. The JSP translator translates
a JSP into a Java source file. The container compiles the source file into a Java
bytecode (.class) file, which executes as a servlet in the servlet container using
the JSP runtime library. The servlet container provides access to Java APIs and
other services.

How the JSP Translator Works

When a user requests a URL that maps to a JSP file, such as
http://host/Hello.jsp, the following steps occur:

1. The Web server invokes the JSP translator, which translates Hello.jsp
and produces the file Hello.java.
2. The Java compiler is invoked, creating a Hello.class servlet.
3. Hello.class runs, using the JSP runtime library, which contains the
supporting files to interpret the tags and directives from the JSP.
4. If the Hello class requires information from a database, then the servlet
container provides JDBC access to the class so it can retrieve the
information and return its output to the client browser.

J2EE Services

Java 2 Platform Enterprise Edition (J2EE) provides core services for writing J2EE
components. The J2EE containers manage access to these services for the
application components. The services are as follows:

• Java Database Connectivity (JDBC): This service lets you invoke SQL
commands from Java programming methods. You use the JDBC API in an
enterprise bean when you override the default container-managed
persistence or have a session bean access the database. You can also
use the JDBC API from a servlet or a JSP to access a database directly
without going through an enterprise bean.

Oracle Application Server includes the following drivers to provide highly

scalable and reliable connectivity to both Oracle and non-Oracle data
sources:

• Oracle JDBC drivers: The Oracle JDBC drivers, in addition to

providing standard JDBC API support, have extensions to support
Oracle-specific datatypes and to enhance their performance. They
are meant to be used with the Oracle database.
• J2EE Connectors: The J2EE Connector architecture, part of the
J2EE platform, provides a Java-based solution for connecting
various application servers and enterprise information systems that
are already in place.
• DataDirect Connect Type 4 JDBC drivers: DataDirect JDBC
drivers are meant specifically for connecting to non-Oracle
databases, such as Microsoft SQL Server and Sybase.
• Java Message Service (JMS): This service is a messaging standard that
allows J2EE application components to create, send, receive, and read
messages. It enables distributed communication that is loosely coupled,
reliable, and asynchronous.
 For this release, JMS support has been enhanced by the addition of a
lightweight JMS provider in addition to the Oracle JMS offered in previous
versions. The new lightweight JMS is fully JMS 1.0 compatible and can
support durable messaging through a file-based persistence mechanism,
which provides improved stability and performance. Support for Message
Driven Beans is also now available for both Oracle JMS (AQ) and the
lightweight OC4J JMS.

• Java Transaction API (JTA): This service provides a standard

demarcation interface for demarcating transactions. Typically, it is used in
J2EE applications that use two or more separate database access
operations that depend on each other to demarcate where the entire
transaction begins, rolls back, and commits.

OC4J provides additional support for two-phase commits for applications

that require commit coordination across machines and containers. The
two-phase commit engine is responsible for ensuring that when a
distributed transaction ends, changes to all participating databases are all
either committed or rolled back.

• Java Naming and Directory Interface (JNDI): This service provides a

standard interface to naming and directory services. J2EE applications
use JNDI to find other distributed objects. The JNDI Interface has two
parts: an application-level interface used by application programs to
access naming and directory services, and a service provider interface to
attach a provider of naming and directory services.
• JavaMail Technology: This service provides J2EE applications with a
JavaMail API and a JavaMail service provider with which to send e-mail
notifications.
• Java API for XML (JAXP): This service provides support for the industry
standard SAX and DOM APIs for parsing XML documents, as well as
support for XSLT transform engines. It enables applications running in a
J2EE container to make use of XML.
• J2EE Connector Architecture: This service provides an interface for
resource adapters that allow J2EE applications to access and interact with
databases and other enterprise information systems (EIS). Oracle
Application Server provides several out-of-the box adapters, and also
allows you to build your own.
• Java Authentication and Authorization Service (JAAS): This service
provides a way for a J2EE application to authenticate users against
different security provider systems and authorize a specific user or group
of users to run J2EE applications under role permission and control
enforcement.
• Oracle Application Server provides an implementation of Java
Authentication and Authorization Service (JAAS) that integrates
with the Oracle Application Server J2EE security infrastructure to
 enforce security constraints for Web components (servlets and
JSPs) and EJB components.

Oracle J2EE Services

In addition to the standard J2EE Services, Oracle also provides the following
services to Java developers:

• Java Object Cache stores frequently accessed or resource-intensive

objects in memory or on disk. It is a low-level object caching API,
supporting generic object types such as memory objects, disk objects,
pooled objects, and StreamAccess objects. Java Object Cache uses
distributed object management to coordinate updates and invalidations of
Java objects.

Objects are loaded using a user-defined CacheLoader object and

accessed through the easy-to-use API. This eliminates the need to
repeatedly create and load information within a Java application. The Java
Object Cache retrieves content quickly and greatly reduces the load on
Oracle Application Server.

Java Object Cache provides caching for expensive or frequently used

Java objects when the application servers use a Java program to supply
their content. Cached Java objects may contain generated pages, or they
may provide support objects within the program to assist in creating new
content. Java Object Cache automatically loads and updates objects as
specified by the Java applications and includes APIs to manage the
cached Java objects. The generic nature of Java Object Cache makes it
an ideal cache repository for higher level caches such as Web Object
Cache, easing the development effort and reducing complexity.

Deploying an ear File

After you’ve created the EAR file, you can deploy it to the Oracle Application Server,
which will serve the application to the Web. You can deploy these files using Oracle
Enterprise Manager 10g using either an existing Reports OC4J instance
(OC4J_BI_FORMS) or preferably an application’s particular OC4J instance such as
OC4J_ECAS. Oracle recommends installing JSP reports in an OC4J instance other than
OC4J_BI_FORMS.
Deploying the J2EE Application Using an existing OC4J Instance
1. Make sure you’ve created the J2EE application based on creating a
new J2EE Application standards
2. In Oracle Enterprise Manager 10g, display the detail page for your
middle tier.
3. Under System Components, click OC4J_BI_Forms. (Or preferably
something like OC4J_ECAS)
4. Under Deployed Applications, click Deploy EAR file to deploy the
EAR file you created in Creating a New J2EE Application.
5. On the first page of the Deploy Application wizard, click Next
(located at the bottom of the screen).
6. On the Select Application page, under Select the J2EE application
(EAR file) to be deployed, enter the location of the EAR file you
created in the previous section.
7. Under Specify a unique application name for this application, type
the name of your application, such as MyReportApp, then click
Next.
8. On the URL Mapping page, note that the text in the URL Binding
field is the name your users will enter to access the new
application.
9. In the URL Binding field, add a forward slash (/) to the beginning of
the application name, since it is part of a URL address. For
example: /MyReportApp
10. Click Finish.
11. On the next page, click Deploy.
12. On the OC4J_BI_Forms detail page that displays, you should now
see your application (MyReportApp) listed under Deployed
Applications.
13. Click your application name (MyReportApp).
14. On the Application page, under Properties, click General.
15. Under Library Paths, click Add Another Row, then add the following
path to the rwrun.jar library:

ORACLE_HOME\reports\jlib\rwrun.jar
16. Add another row with the following path to the zrclient.jar library:
ORACLE_HOME\jlib\zrclient.jar
17. Click Apply, then click OK.
 18. Click Stop, then Start to restart your application so that the new
library paths take effect.

Deploying JSP reports to a new OC4J instance

1. Make sure you’ve created the J2EE application based on creating a
new J2EE Application standards
2. In Oracle Enterprise Manager, display the detail page for your
middle tier.
3. Click Create OC4J Instance.
4. Type the name of your OC4J instance. (such as OC4J_ECAS, if it
already does not exist)
5. Click Create.
6. On the confirmation page, click OK.
7. On Application Server page, under System Components, you
should now see the new OC4J instance. Now, you must manually
configure the OC4J to support connection to a Reports Server and
the security integration.

Note: If you are deploying the Report to an existing Application

OC4J instance such as OC4J_ECAS, you should start from the
step 8 to make the OC4J instance capable of running reports
8. Copy the following properties and their definitions in the
oc4j.properties file from an existing OC4J instance, for example the
OC4J_BI_FORMS instance
(ORACLE_HOME/j2ee/OC4J_BI_FORM/config/oc4j.properties),
into the oc4j.properties file of your new OC4J instance
(ORACLE_HOME/j2ee/yourapplication/config/oc4j.properties):
a) oracle.home
b) java.rmi.server.randomIDs
c) oracle.display
d) oracle.path
e) org.omg.CORBA.ORBClass
f) org.omg.CORBA.ORBSingletonClass

9. In the opmn.xml file in your ORACLE_HOME, add the PATH and

DISPLAY properties to your new OC4J instance:
a) In ORACLE_HOME/opmn/conf/opmn.xml, find the XML
element that describes your new OC4J instance:
<oc4j instanceName="<your application>" gid="<your
application>">
 <config-file path="D:\oracle\Ora9iasR2App\j2ee\<your
application>\config\server.xml"/>
<oc4j-option value="-properties"/>
<port ajp="3001-3100" rmi="3101-3200" jms="3201-3300"/>
</oc4j>

b) Add the PATH and DISPLAY properties by copying them

from the OC4J_BI_FORMS instance in the same opmn.xml
file, for example:
<oc4j instanceName="<your application>" gid="<your
application>">
<config-file path="D:\oracle\Ora9iasR2App\j2ee\<your
application>\config\server.xml"/>
<oc4j-option value="-properties"/>
<port ajp="3001-3100" rmi="3101-3200" jms="3201-3300"/>
<environment> <!-- entry to copy from the other instan -->
<prop name="PATH" value="values are dependant of the
system"/>
<prop name="DISPLAY" value="localhost:0"/>
</environment>
</oc4j>

c) Restart the OC4J instance

Middle Tier Administrator Setup – Data Source Connection Pooling

Oracle AS 10.1.3 provides convenient methods to configure and manage database

connections. Data source configuration can be performed entirely in the Oracle Enterprise
Manager 10g Application Server Control Console.

Please note that there have been few changes to data source configuration and usage. The
OC4J Data Sources types are managed data sources and native data sources, replacing
emulated, non-emulated, and native. Managed data source uses OC4J container
connection pooling.

Creating a managed data source

To create a managed data source …

1. Connect as oc4jadmin (or other admin user) to AS Control Console

2. Find the application that data source is going to be created for.

Note: If the application is new and hasn’t been deployed yet to application server then
deploy the application following the process accepted in your organization.
3. From application home page go to Administration link

and then ServicesÆJDBC Resources

 4. While on JDBC Resources page create connection pool first

5. Provide all needed information:

- Connection pool name (ex: TSWConnectionPool)
- JDBC URL (ex: jdbc:oracle:thin:@oradev1.educ.gov.bc.ca:1524:dev2)
- Username
- Password
Click ‘Finish’ to complete the connection pool definition

6. Create Managed Data Source

7. Provide all needed information:

- Data Source name (ex: TSW_DB)
- JNDI location (ex: jdbc/TSW_TD)
Connection pool attribute identifies the connection pool with which
this managed data source will interact to get connections.
- Login timeout (ex: 30)

8. Redeploy the application

Note: For more information please refer to Oracle Containers for J2EE Services Guide
10g Release 3 (10.1.3)
Oracle Application Server Forms Services

Oracle Forms applications combine interactive graphical interfaces with strong

support for data validation. Forms developers can quickly create applications with
powerful data manipulation features.

An Oracle Forms application gives you the power of a desktop application

deployed in a browser. It provides a very rich and productive user interface by
allowing the following:

• Immediate data validation as clients enter data into the form instead of
after submitting the form
• Automatic completion and list of value searches for fields that enable
users to enter correct information quickly

An Oracle Forms application is analogous to a traditional HTML form application.

In the traditional application, the user enters data into a form on a Web page and
submits the data. The Web server processes the data from the form in a CGI
application. The application then performs any necessary transactions and
returns feedback to the user's browser. JavaScript and the database perform
data validation tasks to ensure that the data from the form is correct and
complete.

Forms Services deploys Forms applications to Java clients in a Web

environment. Oracle Application Server Forms Services automatically optimizes
class downloads, network traffic, and interactions with the Oracle database.

Oracle Application Server Forms Services consists of four components:

• Forms Servlet: The Forms Servlet is used to establish the initial

connection when a user starts a Forms application. It returns to the client
the HTML file that contains the Forms Client applet.
• Forms Client Applet: A Java applet running in the client browser. It
provides the user interface for the corresponding Forms Runtime Process.
• Forms Listener Servlet: A servlet running in the OC4J servlet container.
It manages the lifecycle of the Forms Runtime Process and network
connections to the runtime process.
• Forms Runtime Process: A process running in an Oracle Application
Server instance. The process maintains the connection between the client
applet and the database.

Oracle Application Server Forms Services Architecture

When a client requests an Oracle Application Server Forms Services application,

the request has the following flow:
 1. The user launches a browser and navigates to the URL for the Forms
application.
2. The HTTP Listener interprets the URL and displays an HTML page
containing an <APPLET> tag that describes the Forms Java Client to the
browser. The URL calls the Forms servlet to create the HTML page
dynamically.
3. The client receives the HTML file served by the HTTP Listener. The HTML
file supplies the information required to locate the Java class files that
make up the Forms Java Client. The HTML file also contains information
about the requested Forms application, as well as parameters that get
passed to the Forms session, such as login information.
4. The browser downloads the Forms Java Client and the Java applet starts.
5. The Forms Java Client applet sends a request to start a Forms session
through the HTTP Listener to the Forms Listener Servlet.
6. After receiving the connection request from the Forms Java Client, the
Forms Listener Servlet starts a new Forms Runtime process for the client.
7. The Forms Runtime process allocated to the client loads the module
specified in the HTML file and any libraries and menus that are required
by that form. All communication between the Forms Java Client and the
Forms Runtime process is passed through the Forms Listener Servlet.
8. The user is prompted for database login information, and the connection
to the database server is established.
9. The user is now ready to work with the Forms application.

The following diagram illustrates this flow in terms of the Oracle Application
Server Forms Services architecture.

Oracle Application Server Forms Services Request Flow

Oracle Application Server Forms Services Features

Oracle Application Server Forms Services provides the following features to

allow a robust and standard deployment of Forms applications on the Internet.

1. Automatic Internet Scalability and High Performance

2. Native services (record caching, record locking, database management, exception
handling and load balancing) and other out-of-the-box functionality
3. Application server integration (uses OC4J and Oracle Enterprise Manager OEM)
Also, codeless integration with SSO available (not implemented).
4. OEM is used to start, shutdown, monitor, trace and diagnose Forms Services
runtime processes.
5. Network Traffic Optimizations to reduce the number of round trips between the
client and the middle tier and between the middle tier and the database.
6. HTTPS Support

Oracle Application Server Reports Services

OAS Reports Services is part of Oracle Reports. Oracle Application Server also
includes Oracle Reports Developer, a component of the Oracle Developer Suite.
Using Oracle Reports Developer you can build a complex data model and share
it between an existing high quality paper layout and an improved high quality
Web layout using servlets and JSP technology.

Developers can publish sophisticated, high quality reports from any data source,
in any data format, and deploy them anywhere on Oracle Application Server.
OAS Reports Services can combine data from multiple data sources into a single
report, including the Oracle database, XML feeds and JDBC-enabled data
sources.

Reports can be generated on demand or scheduled for a specific time or interval.

Once formatted, a report can be distributed to a standard Web browser, email,
printer or Oracle Portal, be stored on the middle tier for rapid retrieval, or be
stored in a custom destination via the Pluggable Destinations API.

OAS Reports Services enables you to do the following:

• Access reports dynamically from any browser on demand

• Leverage middle-tier load balancing to provide high volumes of reports,
without excessive demands on limited resources
• Generate reports in HTML for browser viewing, PDF for quality viewing,
XML to communicate data to Web sites, RTF and delimited output for
import into Microsoft Office, and PCL for printing
• Optionally secure distribution of reports by allowing only specific users to
access the report and grant secure access
• Link to published reports and provide portlet support using Oracle Portal

Report Server Architecture

The following illustration shows how Oracle Application Server Reports Services
handles client requests. OAS Reports Services runs reports by entering all
requests into a job queue. When one of the server's runtime engines becomes
available, the next job in the queue is dispatched to run.

As the number of jobs in the queue increases, the server can start more runtime
engines until it reaches the maximum limit specified in your server configuration.
OAS Reports Services runtime engines are shut down automatically after having
been idle for a period of time that you specify.

OAS Reports Services keeps track of all jobs submitted in the server, including
jobs that are running, scheduled to run, or finished. The Reports Queue Manager
(Windows), the Reports Queue Viewer (UNIX), or the show jobs command
(Web) enable you to view information on when jobs are scheduled, queued,
started, and finished, as well as the job output and the final status of the report.
Oracle Application Server Reports Services Architecture

A more detailed view of the reports architecture.

OAS Reports Services job objects are persistent. This means that if the server is shut
down and then restarted, all jobs are recovered, not just scheduled jobs.

Oracle Reports Developer enables you to embed a report within a larger existing
Web page. This technology enables you to open and save HTML, JSP, and XML
files that contain report definitions. When a report is saved as a JSP file, the data
model is embedded using XML tags. The entire report can also be defined using
XML tags and saved as an XML file.

You can also use Oracle Reports Developer to take retrieved data, using the
data model, and embed it into an existing Web page. This provides tremendous
flexibility in creating reports that meet business demands by completely
integrating multiple sources of information within a single Web page. If you
choose to create your own JSP, Oracle Reports Developer supplies templates
that can be used to build your report.

Developers can easily create a JSP layout using the Reports Block Wizard to
generate the necessary JSP tags in Oracle Reports Developer. Alternatively,
they can add the tags themselves manually for more precise control.

Middle Tier Administrator Forms/Reports/mod_plsql Middle Tier

Setup – Example: FREDS
Step-by-Step Instructions:

Prerequisites

1) Access to application server middle tier control console with admin user
username and password.
The information about the hostname and port # can be obtained from the file
$ORACLE_HOME/install/readme.txt

http://oasdev1.educ.gov.bc.ca:1812

2) File $ORACLE_HOME/network/admin/tnsnames.ora is updated to allow distributed

access to the corporate database.
DEV2 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = oradev1.educ.gov.bc.ca)(PORT = 1524))
)
(CONNECT_DATA =
(SID = DEV2)
)
)

Set up UNIX environment

1) Create UNIX user fred_dev in the oasdev1 environment.

2) Make sure that the .profile (Linux: .bash_profule) file sets all the
environment variables

In the .profile of the fred_dev user add the following lines

export ORACLE_HOME=/oasdev1/home/oracle/product/oas.10.1.2.0.2
export
PATH=$PATH:$ORACLE_HOME/bin:/home/fred_dev/bin:$ORACLE_HOME/jdk/jre/lib/i386/se
rver
:/oasdev1/app1/freds/src
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/jdk/jre/lib/i386/server
:$ORACLE_HOME/jdk/jre/lib/i386/native_threads
export FORMS_PATH=/oasdev1/app1/freds/bin:$ORACLE_HOME/forms
export TMP=/oasdev1/app1/freds/tmp
export TMPDIR=/oasdev1/app1/freds/tmp
export TERM=vt220 Å important in order to run converting and compililation
scripts
cd /oasdev1/app1/freds

3) Create UNIX group fred_dev. Members are the UNIX users oracle and fred_dev.

4) Create the following directory structure

Root user creates the directory /oasdev1/app1/freds and then changes owner to
fred_dev. Then fred_dev user can create all the subdirectories.
/oasdev1/app1/freds
/oasdev1/app1/freds/admin
/oasdev1/app1/freds/src
/oasdev1/app1/freds/bin
/oasdev1/app1/freds/logs
/oasdev1/app1/freds/tmp Å this directory is used by conversion and compilation
executables
/oasdev1/app1/freds/www
/oasdev1/app1/freds/www/img
/oasdev1/app1/freds/www/html
/oasdev1/app1/freds/www/dmp

All directories are created by fred_dev and their group is fred_dev

Set up Form Configuration

1) From application server middle tier control console access Forms Æ

Configuration; that brings to the page, which provides functionality to update
formsweb.cfg file.
This file physically located in the directory $ORACLE_HOME/forms/server.
Backup this file before updating it through web interface.

Create new section freds in formsweb.cfg file. Add the following values to this
section:

workingDirectory=/oasdev1/app1/freds/bin // working directory for Forms runtime

processes
form= frd_start.fmx // which form module to run
envFile=freds.env // file setting environment variables
for
the Forms runtime processes
pageTitle=FREDS DEV
background=NO
width=974
height=688
lookandfeel=Generic
serverApp=freds
splashScreen=NO
otherParams=term=/oasdev1/home/oracle/product/oas.10.1.2.0.2/forms/admin/
resource/
US/fmrpcweb.res

2) Create new freds.env file that belongs to user oracle. Environment file must
be created manually in $ORACLE_HOME/forms/server with an .env extension.

cp default.env freds.dev

For a new environment file to be picked up by Application Server Control

Console restart the Enterprise Manager processes:

emctl stop em
emctl start em

From application server middle tier control console access Forms Æ Environment;
that brings to the page, which provides functionality to update freds.env file.
Update FORMS_PATH environment variable:

FORMS_PATH=/oasdev1/app1/freds/bin

3) Set up icons directory

a) Define virtual directory in file $ORACLE_HOME/forms/server/forms.conf.

Find section with “AliasMatch ^/” and add the following line:
AliasMatch ^/freds/icons/(..*) "/oasdev1/app1/freds/www/icon/$1"

b) Create new registry file that belongs to user oracle. Environment file
must be created manually in $ORACLE_HOME/forms/java/oracle/forms/registry
with a .dat extension.

cp Registry.dat freds.dat

Update newly created freds.dat file with the following values:

default.icons.iconpath=/freds/icons Å should point to the defined

virtual directory(a)

c) The reference to this file is reflected in formsweb.cfg file

(refer to Setup Forms Configuration (1))

Set up Reports Server

Add new Reports Server:

- use addNewServerTarget.sh script to register a new Reports server in
opmn.xml and targets.xml:
$ORACLE_HOME/bin/addNewServerTarget.sh rep_dev1_freds

-run $ORACLE_HOME/opmn/bin/opmnctl reload

- start added Reports Server

In file $ORACLE_HOME/reports/conf/rep_dev1_freds.conf :
1) define cache directory
- find the section that starts from :

<cache class="oracle.reports.cache.RWCache">

- uncomment and add values for the properties:

<property name="cacheSize" value="50"/>

 <property name="cacheDir" value="/oasdev1/app1/freds/www/dmp"/>

2) define source and temp directories

- find the serction that starts from :
<engine id="rwEng"…
- add values for the properties
<property name="sourceDir" value="/oasdev1/app1/freds/bin"/>
<property name="tempDir" value="/oasdev1/app1/freds/tmp"/>
3) comment the section that starts from <security id="rwSec"… - this will allow
reports to execute without sso authorization

Add the following line to the keymap file $ORACLE_HOME/reports/cgicmd.dat :

freds: server=rep_dev1_freds userid=freds_app/freds@dev2 %*

Add BLOB destionation to reports server

1) Copy BLOBDestination.jar to $ORACLE_HOME/reports/jlib directory

2) Update the file $ORACLE_HOME/bin/reports.sh

Add the following entry to the REPORTS_CLASSPATH environment variable:

ORACLE_HOME/reports/jlib/BLOBDestination.jar

3) Register the new destination with the Oracle Reports Services.

Add the following entry in the Reports Server configuration file
$ORACLE_HOME/reports/conf/rep_dev1_freds

<destination destype="BLOBDestination"
class="oracle.reports.plugin.destination.blob.BLOBDestination"></destinat
ion>

4) Restart the Reports Server for your changes to take effect.

Set up Mod_PLSQL

Creating a Database Access Descriptor (DAD) for mod_plsql using Oracle HTTP
Server Home page:
1) From application server control console access HTTP Server Æ Administration
Æ PL/SQL Properties. This opens the mod_plsql Services page.
2) On the mod_plsql Services page, scroll to the DAD Status section. Click
Create. This opens the DAD Type page.
3) Select the General radio button. Click Next. This opens the Database
Connection page.
4) Enter the following values on Database connection page:
- unique name in the DAD Name field: /pls/freds
- database account: freds_app
- password: freds
- connect string: oradev1.educ.gov.bc.ca:1524:dev2
- connect string format: host:port:service_name
- name of the PL/SQL procedure that should be invoked when one is not
specified: test_mod_plsql.hello_world
- NLS Language field: AMERICAN_AMERICA.AL32UTF8
- authentication mode: Basic
Click Next. This opens the Document, Alias, and Session page.
5) The fields on the next two pages are typically not configured. Click Apply.
6) Restart Oracle HTTP Server.
Developer Forms/Reports/mod_plsql Middle Tier Setup – Example:
FREDS

Set up Test Applications : Note Step 2 for Upgrade Only

1) Deploy the forms application onto the middle tier server

FTP the files of the following directories

/src -> /oasdev1/app1/freds/src

2) Convert forms application using Forms Migration Assistant (only for

migration from 9iAS to OAS 10g):

Connect as fred_dev to oasdev1.educ.gov.bc.ca

cd /oasdev1/app1/freds/admin/

Run upgradeall.sh
./upgradeall.sh <db connection string>

upgradeall.sh invokes Forms Migration Assistant (frmplsqlconv.sh) for plsql

libraries (.pll), menus (.mmb) and then forms (.fmb).
The script will generate log files for each component: upgrade_pll.log,
upgrade_mmb.log, upgrade_fmb.log that could be found in
/oasdev1/app1/freds/logs/ directory.

3) Recompile forms application from Windows to UNIX platform.

Connect as fred_dev to oasdev1.educ.gov.bc.ca

cd /oasdev1/app1/freds/admin/

Run compall.sh
./compall.sh <db connection string>

Note: In case of a problem with compiling plsql library open and recompile
.plls in Forms Builder and then use compall_nopll.sh to compile menues forms
and reports.

The compall.sh script should create *.plx, *.mmx, *.fmx files and move them to
the directory
/oasdev1/app1/freds/bin

Oracle Portal

Introduction to Oracle Application Server Portal

Portals allow clients to access information through a Web browser. This information
usually comes from different data sources that the portal makes available through a single
entry point. That entry point is known as a page.
Portals also support personalized views, so that each user or user group can customize
both the content and the appearance of the portal to suit individual preferences and
requirements.

For example, a financial analyst's page would likely include information from real-time
Internet-based stock quotes, financial reports from an online repository, and access to
legacy financial accounting and banking systems. The data from these systems are
independent of each other, but the portal allows them to exist within a single page.

Oracle Application Server Portal

Oracle Application Server Portal is a Web-based tool for building and deploying e-
business portals. It provides an environment for accessing and interacting with enterprise
software services and information resources. A portal page makes data from multiple
sources accessible from a single location. The following figure shows a sample portal
page from http://my.oracle.com. Each one of the tabbed areas within the Office tab
contains information from a different data source.
Sample Portal Page
Oracle Instant Portal
Oracle Instant Portal is a custom application built with OracleAS Portal that provides
smaller enterprises an opportunity to build simple portals in a short amount of time. We
are not currently using Oracle Instant Portal at the Ministry of Education. Instant Portal
provides instant out-of-the-box portals for publishing and content sharing, which is ideal
for enterprises with a need for smaller-scale intranets or an internal communications hub.

Oracle Portal Architecture

When a user requests an OAS Portal page, many Oracle Application Server
components service parts of the request. Requests have the following flow:

1. The browser requests a portal page. OAS Web Cache receives this
request.
2. OracleAS Web Cache forwards the request to the OracleAS Portal
Parallel Page Engine (PPE) through Oracle HTTP Server.
3. The PPE retrieves the portal page definition, and coordinates with all of
the portlet providers to see if there is a cached copy available or if fresh
information is needed.
4. The PPE aggregates all of the portlet content into a single page. This
page is sent to OracleAS Web Cache.
5. OracleAS Web Cache returns the final page to the browser.

The following diagram illustrates this flow in terms of the OracleAS Portal
architecture.
Portal Page Creation, Management, and Customization
OracleAS Portal incorporates a portal creation and deployment framework. The
framework defines Web information sources as information components, and
assembles these components within a portal page. It also supports customization
of the Web page to one or more user communities.

Each portal page is divided into either item regions or portlet regions. Item
regions allow you to add text, images, and files to a portal page. Portlet regions
provide an area where you can place one or more portlets.

A portlet is an HTML or XML area that summarizes, promotes, or provides basic

access to an information resource. The information resources can take on many
forms and can serve many purposes. Stock feeds, weather forecasts, even other
Web sites are all examples of information that can appear as portlets on a page.

Items and portlets are the fundamental building blocks of an OracleAS Portal
page. Page owners can populate the pages they create with content, or they can
delegate that task, as well as page maintenance tasks, to other users.
High Availability
Requirements
Some of the requirements addressed by high availability are:
• Continuous uptime
• High availability of applications
• High level of flexibility in server management
• Minimized fail over time
• Improved application scalability
• Dynamic load balancing of client connections
• Increased capacity

Introduction
High availability solutions can be categorized into local high availability solutions that
provide high availability in a single data centre deployment, and disaster recovery
solutions, which are usually geographically distributed deployments that protect
applications from disasters such as floods or regional network outages.
Amongst possible types of failures, process, node, and media failures as well as human
errors can be protected by local high availability solutions. Local physical disasters can
be protected by geographically distributed disaster recovery solutions. Disaster recovery
is out of the scope of the current document; therefore we will focus on local high
availability only. The disaster recovery can be added later on if required.
To solve the high availability problem, a number of technologies and best practices are
needed. The most important mechanism is redundancy. High availability comes from
redundant systems and components.
Local high availability solutions can be categorized -- by their level of redundancy -- into
active-active solutions and active-passive solutions (see Figure 2). Active-active solutions
deploy two or more active system instances and can be used to improve scalability as
well as provide high availability. All instances handle requests concurrently.
Active-passive solutions deploy an active instance that handles requests and a passive
instance that is on standby. In addition, a heartbeat mechanism is set up between these
two instances. This mechanism is provided and managed through vendor-specific cluster
ware. Generally, vendor-specific cluster agents are also available to automatically
monitor and fail over between cluster nodes, so that when the active instance fails, an
agent shuts down the active instance completely, brings up the passive instance, and
application services can successfully resume processing. As a result, the active-passive
roles are now switched. The same procedure can be done manually for planned or
unplanned down time. Active-passive solutions are also generally referred to as cold fail
over clusters (CFC).

Figure 3- Active-active and active-passive high availability solutions

Hardware Cluster
A hardware cluster is a collection of loosely coupled computers (called nodes) that
provides a single view of network services (for example: an IP address) or application
services (for example: databases, web servers) to the clients of these services. Each node
in a cluster is a standalone server that runs its own processes. These processes can
communicate with one another to form what looks like a single system that cooperatively
provides applications, system resources, and data to users. This type of clustering offers
several advantages over traditional single server systems for highly available and scalable
applications.
Hardware clusters achieve high availability and scalability through the use of additional
hardware (cluster interconnect, shared storage) and software (health monitors, resource
monitors). (The cluster interconnect is a private link used by the hardware cluster for
heartbeat information to detect node death.) Due to the need for additional hardware and
software, hardware clusters are commonly provided by hardware vendors such as SUN,
HP, IBM, and Dell. While the number of nodes that can be configured in a hardware
cluster is vendor dependent, for the purpose of Oracle Application Server 10g High
Availability using the Oracle Application Server Cold Fail over Clusters solution, only
two nodes are required. Hence, this document will assume a two-node hardware cluster
for the purpose of explanation.
Fail over
Failover is the process by which the hardware cluster automatically relocates the
execution of an application from a failed node to a designated standby node. When a
failover occurs, clients may see a brief interruption in service and may need to reconnect
after the failover operation has completed. However, clients are not aware of the physical
server from which they are provided the application and data. The hardware cluster’s
software provides the APIs to automatically start, stop, monitor, and failover applications
between the two nodes of the hardware cluster.

Primary Node
The node that is actively executing one or more middle tier application or infrastructure
instance at any given time is called the primary node. If this node fails, the hardware
cluster automatically fails the middle tier or Infrastructure over to the secondary node.
Since the primary node runs the active middle tier or Infrastructure installation(s), it is
considered the "hot" node.

Secondary Node
This is the node that takes over the execution of the middle tier or Infrastructure if the
primary node fails. Since the secondary node does not originally run the middle tier or
Infrastructure, it is considered the "cold" node. And, because the application fails from a
hot node (primary) to a cold node (secondary), this type of failover is called cold failover.

Logical or Virtual IP
To present a single system view of the cluster to network clients, hardware clusters use
what is called a logical or virtual IP address. This is a dynamic IP address that is
presented to the outside world as the entry point into the cluster. The hardware cluster’s
software manages the movement of this IP address between the two physical nodes of the
cluster while the external clients connect to this IP address without the need to know
which physical node this IP address is currently active on. In a typical two-node cluster
configuration, each physical node has its own physical IP address and hostname, while
there could be several logical IP addresses, which float or migrate between the two nodes.
For a given OracleAS Infrastructure installation, the logical IP/virtual name associated
with that installation is the IP/name that is used by the clients to connect to the
Infrastructure.

Virtual Hostname
The virtual hostname is the hostname associated with the logical or virtual IP. This is the
name that is chosen to give the OracleAS middle tier a single system view of the
hardware cluster. This name-IP entry must be added to the DNS that the site uses, so that
the middle tier nodes can associate with the Infrastructure without having to add this
entry into their local /etc/hosts (or equivalent) file. For example, if the two physical
hostnames of the hardware cluster are node1.mycompany.com and
node2.mycompany.com, the single view of this cluster can be provided by the name
selfservice.mycompany.com. In the DNS, selfservice maps to the logical IP address of
the middle tier, which floats between node1 and node2 without the middle tier knowing
which physical node is active and servicing the requests. Whenever the phrase "virtual
name" is used in this document, it is assumed to be associated with the logical IP address.
In cases where just the IP address is needed or used, it will be explicitly stated so.

Shared Storage
Even though each hardware cluster node is a standalone server that runs its own set of
processes, the storage subsystem required for any cluster-aware purpose is usually
shared. Shared storage refers to the ability of the cluster to be able to access the same
storage, usually disks, from both nodes. While the nodes have equal access to the storage,
only one node, the primary node, has active access to the storage at any given time. The
hardware cluster’s software grants the secondary node access to this storage if the
primary node fails. For the OracleAS 10g, its ORACLE_HOME is on such a shared
storage file system. The primary node mounts this file system; if that node fails, the
secondary node takes over and mounts the file system. In some cases, the primary node
may relinquish control of the shared storage, such as when the hardware cluster’s
software deems the Infrastructure as unusable from the primary node and decides to
move it to the secondary.

The Ministry’s High Availability Configuration

Currently, for the purpose of high availability of our middle tier applications we use the
cold fail over cluster configuration, which as described earlier, means that when a middle
tier application server goes down, another one takes over automatically and the user
community’s work is not disrupted. This capability restores both infrastructure services
as well as the middle tier and its applications in a matter of minutes without manual
intervention and is a key requirement of our environment.
We made an attempt to upgrade to Oracle application serve10g R1 (9.0.4) and found out
that it only provided partial support for Cold Fail Over clustering in that it only fails over
the infrastructure services but not the middle tier services that are hosting user
applications. This was not acceptable in our environment.
Oracle application server 10g Release 1 only provides an active-active mechanism called
“Oracle clustering” for the middle tier layer. This mechanism supports a similar
functionality but at the cost of increasing the number of required Oracle Application
server licenses compared to cold fail over configuration.
The recently released OAS 10g Release 2 (10.1.2) provides the full cold fail over
capability (infrastructure and middle tier, including applications) and therefore is our
preferred release to upgrade to.
Recommendations:
Taking the Ministry’s requirements in mind the following approach is recommended:
1. Select Application Server 10g R2 as the target release for upgrade and
bypass 10g R1 because it does not have Cold Fail over cluster capability
for the middle tier
2. Select Active-Passive (Cold Fail Over) clustering over Active-Active
(Oracle Cluster or Grid) clustering for now, because:
ƒ It can potentially be half as expensive in terms of licenses,
ƒ It does not require the purchase of a load balancer hardware
ƒ It provides similar capability with lower cost
ƒ It is easier to manage
ƒ We already have a lot of experience using this technology and
are very familiar with how it works
ƒ We do not need to change our software configuration
ƒ It satisfies our existing requirements.
ƒ We are not closing any doors. We can always switch to active-
active fail over if our requirements indicate that such action is
necessary.

3. Implement a slightly modified configuration of cold failover cluster, in

which during the normal mode, OracleAS Infrastructure runs on node 1,
while the middle tier runs on node 2. Unlike normal cold failover cluster
configurations, both nodes are active in this case but running different
components (either the OracleAS Infrastructure components or the
middle-tier components).
4. Use two virtual hostnames: one virtual hostname (for example,
vhost_infra or oaisbx2) points to the node running OracleAS Infrastructure
(and the other virtual hostname (for example, vhost_mt or oassbx2) points
to the node running the middle tier (see the following example for how the
fail over will function)
5. Use enterprise manager with Grid Control to manage the servers instead
of the current manual process as much as possible.

Fail over example:

If node 1 fails, the OracleAS Infrastructure processes fail over to node 2. The virtual
hostname that was pointing to node 1 now points to node 2.
If node 2 fails, the middle-tier processes fail over to node 1. The virtual hostname that
was pointing to node 2 now points to node 1.
Recommended Server Farms
To begin with, we should start with the following three Oracle Application Server farms:
1. Production: Includes two servers, with hardware clustering enabled
between them. One server will run infrastructure and the other one
will run the middle tier. They are configured for cold fail over
clustering so that if any one of the servers goes down, the other
will take over running the component that its server has gone
down.
2. Development: Includes two servers with hardware clustering
enabled between them. One server will run a shared infrastructure
for all the middle tier instances that run on the two servers,
including DEV, TST, UAT, TRN and EFX. The two servers are
configured for cold fail over. If any one of the servers goes down,
the other will take over running the components that their server
has gone down
3. Sandbox: includes two servers with clustering enabled to test
various configurations as well as for testing new patches and bug
fixes.
Future Possibilities
In the future, as the need for scalability arises and one server may not be
enough to handle all the traffic, we might want to consider the following
configuration:

• Study the possibility of using Oracle Active-Active Clustering for the

Middle tier instances instead of cold fail over. This will allow us to run
applications on more than one server simultaneously so that if one goes
down, the others will take the load.
• Continue with Cold Fail Over Clustering for the infrastructures
• This option will require the use of load balancing, for which we might
want to look into using Oracle web cache or a hardware based load
balancers.

Security Architecture
Security is a critical concern when deploying web applications. OAS 10g provides a solid
framework for building web applications using the Apache-based Oracle HTTP Server,
Oracle’s J2EE framework, and OAS 10g Portal. OAS 10g security starts from the basic,
highly configurable web security services provided by Apache, adds a comprehensive set
of web single sign-on, directory-based authorization and user management, and Java2
security services, and extends them further with portal security and application
integration mechanisms. OAS 10g also support secure access to Oracle database systems
using Oracle Advanced Security. In addition, the modular nature of the middle tier allows
integration with other security mechanisms such as the Government Security Gateway.
The use of Netegrity SiteMinder Policy Server and Web Agent by the Government
Security Gateway is outside the scope of this document and will be handled in a future
phase. The current document focuses on the introduction of various elements of security
infrastructure and their role and prepares the reader for the future security related phases.
For more information on the Government Security Gateway, please refer to
http://mtddev.educ.gov.bc.ca:8080/html/gsg/index.html.
Oracle HTTP Server Security Features
Oracle HTTP server is the Oracle web server component of OAS 10g. It is based on the
open source Apache web server. The Apache server is among the most widely adopted
web server products; it provides a flexible and well-understood security model. Apache is
a very well tested platform on which to deploy secure applications.
Oracle HTTP Server security services include the ability to restrict or allow access to
files and services based on the identity of users established via basic challenge/response
operations, via client-supplied X.509 certificates and via IP or hostname addresses.
Another important feature is protection of data exchanged between clients and the server.
This is provided via the SSL protocol, which also provides data integrity and strong
authentication of both users and HTTP servers.
In addition, Apache provides logging and other facilities needed to detect and resolve
intrusion attempts. It provides integration with the other OAS 10g components and
products such as the Oracle database.

Access Control
When URL requests arrive at the Oracle HTTP server they are processed in a number of
steps which are implemented via the mod/plug-in architecture common to all the popular
web server / listeners. Access control is applied early in the request processing cycle.
Oracle HTTP Server access control is based on Apache access control mechanisms,
which allow the server administrator to restrict access to particular files, directories, or
URLs on the server. For each restricted object on the server, the administrator can
specify, by means of a directive, that access to the object is denied or allowed based on
the value of one or more attributes associated with the requester. The administrator can
configure directives such as deny, allow and order to inhibit further processing, based on
user attributes such as hostname, IP address, or browser type. Restrictions can be applied
to particular files, directories or URL formats using the <files>, <directory> and
<location> configuration directives, respectively.
In the following example, requests originating from any IP address in the 192.168.1.*
range or with the hostname us.oracle.com are allowed access to files in the directory
/internalonly/.
<Directory /internalonly/>
order deny,allow
deny from all
allow from 192.168.1.* us.oracle.com
</Directory>
Note that allowing or restricting access based on hostname for Internet access is not
considered a very good method of providing security, since hostname is easy to spoof.
While the same is true of IP addresses, sabotage is slightly more difficult. Thus, access
control via IP/hostname for intranet use is reasonable in many situations where the same
cannot be said for Internet IP and hostname restrictions.
Although the Oracle HTTP Server is based on the open source Apache Server, it contains
some access control enhancements, which improve security. For example, the Apache
Server provides for access restrictions per directory/folder via files with the suffix
.htaccess. The processing of these files is disabled by default in Oracle HTTP Server,
since. htaccess processing involves both security and performance-degradation problems.

User Authentication and Authorization

In many applications it is desirable to control access to resources on the web server based
on user identity. Oracle HTTP Server provides several mechanisms for user
authentication, including client authentication over the Secure Socket Layer (SSL) using
X.509 certificates, username/password (as in basic authentication), and other forms. A
server administrator can specify, via Apache directive, that access to specific URLs is
restricted to specific users, who must be authenticated via a specific mechanism.
Once user authentication is established, additional rules can be applied restricting or
allowing further processing of URL requests. Access control directives based on user
identity can be combined with directives based on IP address or hostname (as described
above), so that user requests must satisfy both directives in order to allow further
processing. For example, we can constrain access to a particular URL so that only certain
named users can access it, and then only from within the corporate intranet. We can do
this by configuring the directive for the URL so that it requires user authentication,
denies access except for specific named users, and requires that the IP address be within a
certain range (to ensure that the user is within the intranet). The Apache directive access
control mechanisms implemented in Oracle HTTP Server thus provide a great deal of
flexibility in managing user access to objects.

Firewalls, Proxy Servers and DMZ

A firewall is a set of related programs, located at a network gateway server that protects
the resources of a private network from users coming from other networks. (The term
also implies the security policy that is used with the programs.) An enterprise with an
intranet that allows its workers access to the wider Internet installs a firewall to prevent
outsiders from accessing its own private data resources and for controlling what outside
resources its own users have access to.
Basically, a firewall, working closely with a router program, examines each network
packet to determine whether to forward it toward its destination. A firewall also includes
or works with a proxy server that makes Internet requests on behalf of internal users. A
reverse proxy server does the opposite; it makes requests to the Intra-net on behalf of
the external users. A firewall is often installed in a specially designated computer
separate from the rest of the network so that no incoming request can directly get at
private network resources
Database and application servers need to be protected by firewalls. The firewall filters out
unwanted and unauthorized requests and does not allow them to reach those servers.
A DMZ (demilitarized zone) is a computer host or small network inserted as a "neutral
zone" between the Ministry’s private network and the outside public network. It prevents
outside users from getting direct access to a servers at the Ministry.
In a typical DMZ configuration, a separate computer (Proxy Server) receives requests
from users within the private network for access to Web sites or other companies
accessible on the public network. The DMZ proxy server host then initiates sessions for
these requests on the public network. However, the DMZ proxy server is not able to
initiate a session back into the private network. It can only forward packets that have
already been requested.
Users of the public network outside Ministry can only access the DMZ. The DMZ host
may typically have the Ministry’s public web pages so these could be served to the
outside world. When this host is allowed to pass through authenticated requests to the
internal network on behalf of the outside users, it is called a reverse proxy server.
In our configuration, the public web server acts as reverse proxy server. It will be located
in the DMZ.
The benefit of using a Reverse-Proxy server in DMZ is that it allows our application
servers to be located behind the firewall and therefore become immune from the direct
Internet connections. Outside clients can only talk to the reverse-Proxy server. Only the
reverse proxy server can talk to the application server through specifically designated
ports on the firewall. These openings in the firewall need to be restricted to only reverse
proxy to application server communications so that other applications could not make use
of them to access our Intranet.
One way to minimize the risk would be to set up a separate segment for the servers
behind the firewall. Then implement firewall rules that the reverse-proxy can be limited
to that segment and not affect the rest of the LAN (assuming that our firewall allows
separate rules for each segment). This gives us the benefit of reverse-proxy, without
changing the firewall protection for the rest of the LAN.
The Apache HTTP server included in the OAS 10g, contains modules that allow us to use
it as a reverse proxy server

Mod_proxy
This is one of the modules that come with both OAS 10g and vanilla Apache server. It
implements and enables reverse proxy capabilities.
We can use the mod_proxy module for tunneling external users to application servers as
well as to other internal http servers if we choose to publish some of their information to
Internet.

How to implement tunnelling through Reverse Proxy

We Use Tunneling in the following different scenarios:
• To fully hide a middle tier application server from the Internet users for
security reasons, so that they don't know the server’s name, DNS entry or
IP address but can access it through a public web server,
• To provide SSL encrypted access to internal applications which are not
SSL enabled themselves
• To allow a public web server access to middle tier services such as J2EE
applications, mod_plsql pages or reports in a seamless manner
• Tunneling is accomplished using mod_proxy configuration instructions.
 • The process is as follows:
o Create an application on the middle tier in a normal fashion using
its own DNS entry and virtual host under proper OAS 10g
landscapes. Let’s assume that the application is called ‘xyz’. We
will have: http://xyz.educ.bc.ca pointing to its production
landscape.
o Create a virtual host on the public web server (reverse proxy
server) and enable SSL for it (if required). Let's assume that the
application’s public virtual host is accessed through
https://secure_xyz.educ.bc.ca
o Modify the application’s virtual host configuration on the reverse
proxy server by adding the following lines:

To pass everything:
<IfModule mod_proxy.c>
ProxyRequests On
ProxyPass /
http://xyz.educ.bc.ca/
ProxyPassReverse /
http://xyz.educ.bc.ca/
</IfModule>

These instructions, will allow the public web server to successfully

pass all the requests made to secure.xyz.educ.bc.ca to the middle
tier application xyz.educ.ca and return the answers to the user but
in the process remove and hide all the references to the middle tier
server such as IP address, DNS name and port number.

To pass only the mod_plsql requests:

<IfModule mod_proxy.c>
ProxyRequests On
ProxyPass /pls/ http://xyz.educ.bc.ca/pls/
ProxyPassReverse /pls/ http://xyz.educ.bc.ca/pls/
</IfModule>
These instructions, will serve all the pages locally from the public
web server, however if there is any reference to a mod_plsql page
(identified by /pls/ in the path), it will pass that request to the
middle tier application server; receive the response and pass it to
user without any references to the middle tier server in the
response page. As far as the external user is concerned the public
web server contains all the information.
To hide a completely different server (such as an IIS application
called xyzWeb):
<IfModule mod_proxy.c>
ProxyRequests On
ProxyPass
/xyz/ http://IIS_Server.educ.bc.ca:8888/xyzWeb/
ProxyPassReverse /xyz/
http://IIS_Server.educ.bc.ca:8888/xyzWeb/
</IfModule>

We may or may not need to use this option, however for the sake
of completeness, it has been mentioned here.

Single Sign On (SSO)

Single Sign On is an authentication framework, which can be highly useful when
deploying multiple web applications. SSO improves the user experience, reduces
application development costs since applications do not need their own authentication
mechanisms, reduces system administration costs, and improves system security since
problems associated with multiple passwords are eliminated.
An important security feature of an application server is to provide support for single
sign-on (SSO) to web-based applications. There are a number of reasons why we would
like to use SSO. These include the increasing use of web-based e-Business applications
used by employees, customers and partners. Without SSO, each user must maintain a
separate identity and password for each application he/she accesses. Maintaining multiple
accounts and passwords for each user is insecure and expensive as well as unpleasant for
the user.
Most users cannot remember more than a few passwords. Users who maintain more than
one login account often choose easy-to-remember passwords, choose identical passwords
for different accounts, reuse passwords when asked to change them, or write passwords
down. All these practices reduce password security. Writing passwords down or choosing
easily remembered (and thus easily guessed) passwords increases the risk of passwords
being compromised. Both reusing passwords when asked to change them, and using the
same password on multiple systems, increase the potential damage if a password is
compromised. Although many systems implement password management mechanisms,
which force users to choose complex passwords, or prevent them from reusing a
password, these mechanisms often backfire: users figure out ways to defeat them, and
thus reduce security even more. For example, forcing users to use random passwords
almost guarantees that the passwords will be written down. If a user joins or leaves an
organization, or changes functional roles within the organization, the privileges, which
that user has when accessing applications supported by the organization, change.
Multiple, independent accounts per user often means that the associated user privileges
do not keep up with organizational changes. For example, user accounts and access
privileges may remain in the system long after the user has left the organization or
changed roles. This opens the system up to potential attack by disgruntled former
employees.
Managing multiple accounts and passwords per user is expensive. In many enterprise
deployments, a substantial fraction of the system administrators’ time is spent on
account- and password-related problems, including initial creation of users’ accounts
when they join the organization, deletion of accounts when they leave or change roles,
and resetting passwords that have been forgotten. Having several accounts per user
multiplies the associated demands on the system administrator. Among the problems
which system administrators must deal with is having to access multiple systems, through
multiple, possible different administrative intexyzces, to add or remove user accounts on
each system.

Netegrity Siteminder
The Provincial Government has selected Netegrity SiteMinder software to provide a
common authentication Single Sign-on service for all web-based applications/sites that
require authentication. Presently, authentication is handled within each application at
ITMB, typically with an html login form that prompts the user for an id/username and
password.
The Netegrity SiteMinder solution provides a secure foundation for centrally managed,
policy-based authentication and authorization across heterogeneous application
development environments
Here is a high-level diagram of the architecture ...
When a user attempts to access an application through a protected URL, the user is
challenged for credentials (username and password) and presents them to the Web Agent.
The user's credentials are passed to the SiteMinder Policy Server. The Policy Server
authenticates the credentials against the appropriate LDAP directory store (BCeID or
IDIR). The Policy Server grants access, if the user is authenticated. User profile
formation is passed to the application through custom header variables. The user gets
access to the secured application. Authorization and entitlements are handled by the
application security in phase one of the ITMB project to integrate with the Government
Security Gateway.
OAS 10g SSO provides an API for integration of third-party authentication and single
sign-on; The API allows SSO to be configured to obtain user identity from a trusted
external authentication mechanism, and allows integration of OAS 10g into an SSO
framework provided by a third party product, such as Siteminder from Netegrity, Inc.
This feature will become useful when the Ministry will attempt to integrate its
applications with BC Government’s Netegrity Siteminder.
A second phase will attempt to integrate various application level authorization
mechanisms either locally, using OID or using the Government Security Gateway
authorization mechanism if available. The long-term vision is to have one common
repository for authorization of users accessing ITMB-hosted applications.
Secure Socket Layer (SSL)
The Secure Sockets Layer provides point-to-point security between OAS 10g HTTP
Server and client browsers. Security-related services provided by SSL include
authentication, authorization, confidentiality and data integrity.

SSL Confidentiality
The primary service provided by SSL is confidentiality: messages are encrypted so they
cannot be read and understood by third parties. SSL uses a standard set of cryptographic
mechanisms to encrypt data and distribute keys between communicating devices. The
specific set of encryption, integrity protection, and key distribution algorithms chosen,
together with encryption key length used, define a cipher suite. The OAS 10g SSL
implementation supports a wide range of standard cipher suites. In particular, OAS 10g
supports those cipher suites that use X.509 certificates for authentication and key
distribution (also referred to as PKI authentication).
Oracle HTTP Server allows SSL sessions to be cached, so that multiple message
interchanges between two IP addresses can be exchanged under one session. Session
caching is very important for performance reasons. Establishment of SSL sessions are
very CPU-intensive, and have been known to take up to 90% of available CPU resources.
SSL session caching is specified via the SSLSessionCache directive, whose parameter
specifies the file or shared memory segment where SSL session information is
maintained.

SSL Client Authentication

SSL can also be used to provide client authentication using X.509 certificates, as part of a
public key infrastructure (PKI) deployment. Oracle HTTP Server can be configured to
restrict access to files and services based on information in the client’s X.509 certificate.
Information that can be used in making an access decision includes the distinguished
name (DN) in a client certificate, profile information contained within the DN, and the
certificate trust point (that is, the Certificate Authority which issued the user’s
certificate). SSL can be configured to accept trust points it recognizes, or those signed by
trust points it recognizes, and so forth. Authentication can be based on lists of partial or
full distinguished names, or “wild-carded” versions of those names.
Once SSL authentication occurs, the information available in the certificate can be used
in directives such as <directory>, <files>, and <location>, as described above. SSL
authentication can be combined with Basic authentication and/or host-based access
control. In this way we can allow or restrict different combinations of SSL- and basic-
authenticated users’ access to files and services, and combine such restrictions with host-
based access control.

SSL Environment Variables

OAS 10g allows for security-related information about the SSL session, referred to as
environment variables, to be passed to web server applications such as CGI scripts,
Servlets, and Perl scripts. Applications can use these environment variables to perform
additional access control or authorization on user requests, based on information about
the user, or the type of SSL session established on behalf of the user.
Environment variables include such information as:
• The URL that arrived in the HTTPS request
• The size of cipher key used in SSL session
• The cipher suite used in the SSL session
• The distinguished name from the client certificate

SSL Logging
The Oracle HTTP server also provides for logging of SSL-related information. This can
be used to determine if intrusions were attempted, and if they succeeded. It can also be
used in determining the source of intrusion attacks, or for other purposes.
As described elsewhere in this document, the Ministry’s internal users will not need to
use SSL. Only the traffic between reverse proxy server and the external users should be
SSL enabled when the need arises.

PKI Support
PKI authentication is beginning to replace passwords in many applications. In web-based
applications, PKI authentication is typically performed through an exchange of X.509
certificates, as part of a Secure Sockets Layer (SSL) session establishment. PKI by itself
can be used to provide SSO, since a user with a certificate can authenticate to multiple
applications without entering a password. This capability is mentioned here for the sake
of completeness, since the current direction with GSG seems to be password based
authentication.
In OAS 10g R2, users can authenticate to the OAS 10g SSO Server via PKI. This will
provide SSO both to web-based applications supported by OAS 10g SSO Server, and to
other PKI enabled applications. Instead of providing an SSO username and password,
users will authenticate to the OAS 10g HTTP Server via SSL with client and server
X.509 certificate exchange. The OAS 10g SSO Server will obtain the user’s SSL-
validated certificate from the HTTP Server, and look up this certificate in Oracle Internet
Directory (OID). If the user is found, OID will return the user’s SSO identity to the OAS
10g SSO Server. The OAS 10g SSO Server, using the cookie-based approach described
previously will then perform authentication to partner and external applications.
The main benefits of this approach are that applications, which work within the OAS 10g
SSO Server framework, will automatically be PKI-enabled when the OAS 10g SSO
Server is PKI enabled. The OAS 10g SSO Server and OID assume responsibility for
name mapping. Moreover, since getting and checking a cookie is much less processing-
intensive than performing an SSL exchange, using PKI for initial authentication to the
SSO framework and cookies for authentication to partner applications should have better
performance than a PKI-only authentication approach. For web applications, which are
characterized by many short-lived sessions, this can lead to significant improvement in
server performance and throughput.
Directory-Enabled Security via OID
Oracle products use OID to manage enterprise security information, in particular that
which is shared among Oracle enterprise components. This information includes user
identities, authentication data such as SSO passwords, and authorization data such as
roles or group membership. In OAS 10g R2, OID is a core component of the OAS 10g
infrastructure, and is the common repository for user, authentication, and authorization
information. OID provides a common, LDAPv3 standard framework for representing
user privileges. Use of OID not only provides a common privilege management
mechanism for OAS 10g components, but also provides a vehicle for integrated
management of privileges between OAS 10g and other LDAP-compliant enterprise
components.
To manage privileges in OID, OAS 10g R2 also introduces Delegated Administrative
Services
(DAS), an application, which allows system administrators and, users themselves (where
appropriate), manage user information in OID. DAS includes both a web based GUI
application and a set of APIs for administration of OID data.
OID provides support for extensible authentication through a Password Verifier API.
This API provides support for a variety of custom and third party authentication
mechanisms.
To provide a single directory-based security framework across multiple applications,
organizations may need to integrate OID with other, third party directory products. OAS
10g R2 therefore introduces the Directory Integration Platform (DIP). The DIP provides a
framework for building connectors between OID and third party directories, and supports
referral and synchronization between OID and other directories.
Another approach to consider is to avoid duplication of information between Active
Directory (AD) and OID, by using OID’s plug-in capability to authenticate AD users
remotely without copying their information into OID. This will make the information to
be always up to date and avoid the problems associated with trying to get replication
access to Government Active directory.
In this approach, SSO refers to OID for authentication, however OID uses our plug-in to
remotely authenticate the user against the remote Active directory in which it resides,
once the authentication process is complete, it will communicate the success or failure of
authentication to SSO. As far as SSO is concerned, OID is doing the authentication.
What mechanism to use for the Ministry’s OID integration with other Government Active
directories (IDIR and BceID), will be determined when considering the integration
project with Government Security Gateway and then documented in this document.

Java Security
This is of great importance to the Ministry, since most of the future web applications will
be using Java, and in particular Java2 Enterprise Edition (J2EE).
Java2 Enterprise Edition defines a Java2 Security Model and a security framework
referred to as Java Authentication and Authorization Service (JAAS). OAS 10g
implements this framework through a fully-J2EE compliant JAAS provider. The JAAS
provider makes user authentication, authorization, and delegation services accessible to
application developers, and allows them to integrate these services into J2EE application
environments.
The OAS 10g JAAS provider implements the Java2 Security Model, allowing application
developers to obtain authenticated user (principal) identity from a set of standard
authentication services provided by JAAS, and to manage the privileges which principals
have for accessing objects. It also supports privilege delegation, for managing privileges
of methods invoked by principals.
The OAS 10g JAAS provider supports a flexible authentication framework. It provides
specific mechanisms for authentication, based on SSL and SSO, but also allows
developers to integrate custom authentication modules through the standard JAAS Login
Module API.
SSL authentication allows users who have client X.509v3 certificates to authenticate to
JAAS, and thus to J2EE applications, using these certificates. SSL authentication uses
mod_ossl in the Oracle HTTP Server to obtain an authenticated user identity from the
client X.509 certificate, as validated through an SSL exchange. This identity can then be
provided to Java applications through JAAS.
SSO authentication allows Java applications to use OAS 10g SSO for user authentication.
In this case, authenticated user identity is obtained from mod_osso, and made available to
Java applications through JAAS.
The OAS 10g JAAS provider supports the standard JAAS Login Module API, which
allows developers to integrate custom authentication methods into JAAS.

Secure Access to Oracle Database

Oracle Application Server 10g R2 provides a feature called proxy authentication. This
feature is designed to address a performance problem associated with three-tier
application design. Specifically, it allows OAS 10g to access an Oracle database and get
specific Oracle user privileges without having to logout and login again each time OAS
10g switches user contexts. Moreover, it addresses the security problem of granted
limited (but not complete) trust to the middle tier application server when accessing a
database on behalf of authenticated users. In the past, application designers either had to
grant the middle tier super user privilege (e.g., SYS or root) so that it could access the
database on behalf of any user, or else store database user passwords in the middle tier.
Both of these solutions are insecure.
Proxy authentication allows OAS 10g to establish a single authenticated session (e.g.,
using fat client JDBC or mod_plsql) with an Oracle server (9i or later), and act on behalf
of multiple Oracle users, without having to submit separate authentication credentials for
each user within the session. The application server must specify which user it is acting
on behalf of, and must have been granted privilege to act on that user’s behalf by
Oracle9i. Moreover, Oracle9i can use both the authenticated identity of the OAS 10g, and
the identity of the user on behalf of whom the OAS 10g performs proxy authentication,
when making access decisions or writing audit records of events. Proxy authentication
allows Oracle to delegate limited trust to a middle tier OAS 10g, without having to grant
it super user privilege on the database, or store multiple database user passwords in OAS
10g.
Appendix A - Hardware/OS Details

OAS 10g Migration PRD Cluster

2 Servers (x2), each:
Single Xeon EM64T processor
16GB RAM (expandable to 64GB RAM)
Three internal 36GB U320 15kRPM SCSI drives, hardware RAID
Two fibre channel HBA
RedHat EL 4.0 AS (Premium 24x7 Support)
Three Ethernet ports
Redundant power supply
Each Server Configuration:
Qty PN Description
1 364636-405 HP Proliant DL580 G3 Rack Chassis, Integrated Dual-port NIC, SA 6i
Controller, 1 Power Supply, Redundant Fans
1 399889-L22 64-bit Dual-Core Intel® Xeon™ 7040 (3.00GHz, 2x2M L2) 580 G3 FIO
2 404122-B21 8 GB RAM (2 x 4GB 2RANK) PC2-3200R 400MHz DDR2 memory
1 264007-B21 Slimline DVD-ROM Drive (8x/24x)
3 286776-B22 36.8GB 15K RPM U320 Disk Drive
1 346914-B21 SA 6i 128BM Battery-backed Write Cache
1 313881-B21 NC7170 PCI-X Dual Port 1000T NIC
2 281541-B21 StorageWorks 2 Gb, 64-bit/133 MHz PCI-X-to-Fibre Channel HBA
1 348114-001 910W (low line), 1300W (high line) Hot Plug Redundant Power Supply

Clustering Software (2 Node License):

1 305199-B26 HP Serviceguard for Linux A.11.16 for RHEL 3 & 4 (2 node cluster
license kit)

Red Hat License Subscription:

2 RedHat EL 4.0 AS (Premium 24x7 Support)

OAS 10g Migration DEV, TST, UAT, TRN, EFX

2 Servers (x2), each:
Single Xeon EM64T processor
24GB RAM (expandable to 64GB RAM)
Three internal 36GB U320 15kRPM SCSI drives, hardware RAID 1
Two fibre channel HBA
RedHat EL 4.0 AS (Premium 24x7 Support)
Three Ethernet ports
Redundant power supply
Clustering Software
HP Service Guard for Linux
------------------------------------------------------------------------------------------------------------------------------
Each Server Configuration:
Qty PN
1 364636-405
1 399889-L22
3 404122-B21
1 364639-B21
1 264007-B21
3 286776-B22
1 346914-B21
1 313881-B21
2 281541-B21
1 348114-001
Description
HP Proliant DL580 G3 Rack Chassis, Integrated Dual-port NIC, SA 6i
Controller, 1 Power Supply, Redundant Fans
64-bit Dual-Core Intel® Xeon™ 7040 (3.00GHz, 2x2M L2) 580 G3 FIO
8 GB RAM (2 x 4GB 2RANK) PC2-3200R 400MHz DDR2 memory
DL580 G3 Memory Board
Slimline DVD-ROM Drive (8x/24x)
36.8GB 15K RPM U320 Disk Drive
SA 6i 128BM Battery-backed Write Cache
NC7170 PCI-X Dual Port 1000T NIC
StorageWorks 2 Gb, 64-bit/133 MHz PCI-X-to-Fibre Channel HBA
910W (low line), 1300W (high line) Hot Plug Redundant Power Supply

Clustering Software (2 Node License):

1 305199-B26 HP Serviceguard for Linux A.11.16 for RHEL 3 & 4 (2 node cluster
license kit)

Red Hat License Subscription:

2 RedHat EL 4.0 AS (Premium 24x7 Support)

OAS 10g Migration SBX

OAS 10g Migration Sandbox Cluster

2 Servers, each (x2):
Dual 3.6GHz Xeon EM64T processors
12G RAM
Two internal 36GB U320 15kRPM SCSI drives, hardware RAID 1
Dual port NIC
Dual port fibre channel HBA
RedHat EL 3.0 AS
1 305199-B26 HP Serviceguard for Linux A.11.16 for RHEL 3 & 4 (2 node cluster
license kit)

OAS 10g Clustering Software

HP Service Guard for Linux (evaluation version)

EVA Storage:
One terabyte useable storage (for sandbox, DEV … PRD)

Appendix B - Architectural Review Forrester Research

1. “Giga estimates within three to four years there is high probability Linux will
overtake Windows to become the leading operating system on new server
shipments.” (Forrester Research)

2. “Aggressive action by Oracle during the past two years has moved the integration
capability of its application server platform from an afterthought to one of its
most significant features. This will serve the vendor well in its upcoming battles
against BEA Systems, IBM, Microsoft, and SAP.” (Executive Summary – Ken
Vollmer, Forrester Research Analyst)

3. “The integration enhancements are particularly important in the wake of Oracle's

recently finalized acquisition of PeopleSoft. Oracle will now have a broader
application portfolio that can be used to provide its expanded base of customers
with robust composite application development capability that, going forward,
will dominate the development environment in an increasing number of
organizations. A complete technology platform that includes the business
applications, an application platform (containing robust integration capability),
and integrated database technology will be one of the most efficient alternatives
for organizations that want to acquire the ability to create composite
applications.” (Ken Vollmer – Forrester Research Analyst).

4. Ken Vollmer, Forrester research analyst, recommends “Put Oracle as 10g on your
integration vendor shortlist.”

5. According to the Scorecard summary and Techranking Research Process

(Forrester), Oracle 10g ranked highest for Application Integration, Business
Process Management, Architecture, Development, and Administration when
compared to the top 8 Application servers.

6. “Shops committed to the Oracle database and that are using both the Oracle
application server and third-party J2EE servers should consider consolidating
their J2EE investments on Oracle to capture savings on license fees and skills
development.” (Forrester Recommendation)

7. “Application Server 10g strengthens Oracle’s position as a top alternative to BEA

WebLogic and IBM WebSphere.” Forrester.
 8. “The next major release is scheduled for late 2004. Oracle plans to offer the 10g
application server for the same prices it established for 9iAS: $5,000 per CPU for
the Java Edition, $10,000 per CPU for the Standard Edition and $20,000 per CPU
for the Enterprise Edition.” (Forrester).

Appendix C - Oracle’s Linux Support

1. “In October 2003, over 5,000 Oracle developers migrated over to use Linux as the
platform on which we build the Oracle E-Business Suite product.” Oracle
Technology Network (OTN)
2. “Oracle is fully committed to supporting the Linux operating system. In fact,
Oracle was the first commercial database available on Linux. By supporting
Linux with Oracle's industry leading products, we are enabling customers to
deploy enterprise-class solutions on the lowest cost hardware and operating
system infrastructure. We believe that Linux is more attractive today than it ever
was, as customers are looking for open, cost effective solutions.” Oracle
Technology Network (OTN)
3. “Over the past few years Oracle and its customers have learned a tremendous
amount about running Oracle on Linux for enterprise class deployments.
Combining this knowledge with the opportunity to drastically reduce IT
infrastructure costs has provided the catalyst for Oracle to move to the next step,
which is to provide Oracle customers with seamless and complete technical
support for the Linux operating system in addition to support for the Oracle stack.
Oracle's delivery of a complete solution including direct technical support of the
operating system is critical to our customer's success.” Oracle Technology
Network (OTN)
4. “With technical contributions to enhance Linux, with code-level support of the
key Linux operating systems, and with strategic partnerships, Oracle is offering
an Unbreakable Linux platform for customers to safely deploy Linux in a mission
critical environment.” Oracle Technology Network
5. “Red Hat Enterprise Linux AS and ES … are certified and supported by Oracle.”
OTN
6. “Oracle provides direct support to its customers for Red Hat Enterprise Linux
AS/ES.” OTN
7. “In an effort to streamline and lower the cost of our operations, Oracle has
deployed Linux in various ways to make our infrastructure more efficient and less
expensive. Oracle's internal IT organization has analyzed and found that Linux
based systems are one of the most cost effective ways to reduce costs for IT
infrastructure. We have a large number of Linux based pilots and operational
systems in use at Oracle today. In fact, all of Oracle's recently deployed and new
 outsourcing business runs on Linux. We run our Application Demo Systems and
Technology Demo Systems, which consist of several hundred servers, on Linux.
These systems are utilized by Oracle's worldwide sales organization to provide
Oracle E-Business Suite and Oracle Database with RAC demonstrations to
customers and prospects. In addition, several for our Global IT systems are now
running on Linux. In October 2003, over 5,000 Oracle developers migrated over
to use Linux as the platform on which we build the Oracle E-Business Suite
product.” OTN

Appendix D – Oracle Application server Port Numbers

Oracle recommends a range of port numbers for various middle tier and Infrastructure services.
Since such recommendations can change with the each version of the software, the current list is
included for ease of reference in the future.

We have tried to follow the recommendations as much as possible. However, there are cases in
which these port numbers do not conform to the preferences expressed by CITS or other
stakeholders. For example, there seems to be a strong preference for using HTTP ports in the
80xx range and not the suggested 7777-7877. In such cases, we will make and document our
own decision.

In general, Oracle’s recommendations can be divided into three categories:

a. Ranges that allow us to modify the last three digits (e.g. HTTP server port: 7777-
7877)
b. Ranges that only allow the last two digits to change (e.g. Java Object cache: 7000-
7099)
c. Ranges that provide 10 to 20 ports only (e.g. Application server control port: 1810-
1829)

We would like to partition each range with the following factors in mind:

a. Middle Tier vs. Infrastructure

b. Landscape (sbx, dev, tst, uat, trn, efx, prd)
c. Variations in service (HTTP or Secure HTTP (SSL))

In order to make the middle tier and infrastructure related ports consistent and easy to remember,
and in order to avoid port conflicts across various landscapes, we will apply the following pattern
when assigning ports:

1. When the range allows the last three digits to change: (this mostly applies to HTTP and
WebCache ports)

i. The third digit from right will identify the middle tier vs. infrastructure

• Middle tier will have the lower value

• Infrastructure will have the higher value

For example: the middle tier will use 80xx and the infrastructure will use 81xx
 ii. The second digit from the right will identify the landscape:

Landscape Middle-Tier Infrastructure

sbx 800x 810x
dev 801x 811x
tst 802x 812x
uat 803x 813x
trn 804x 814x
efx 805x 815x
prd 808x 818x
iii. The last digit will identify the variations of the service, for example 1 for http,
3 for SSL etc.

If a second instance of any of these landscapes is created, the last digit of the port
numbers will be assigned to the new instance.

2. When the range only allows the last two digits to change and the range is 00 to 99

iv. The second digit from right will identify the landscape (similar to the previous
case)

v. The last digit on the right will be assigned to Middle tier and infrastructure
and documented following these rules:

1. Even numbers will be assigned to the Middle tier

2. Odd numbers will be assigned to the infrastructure.

For example: DCM discovery port range is 7100-7199, in this case the
Landscape Middle-Tier Infrastructure
sbx 7100 7101
dev 7110 7111
tst 7120 7121
uat 7130 7131
trn 7140 7141
efx 7150 7151
prd 7180 7181

If a second instance of any of these landscapes is created, it will take on the

following ports:

Landscape Middle-Tier Infrastructure

sbx2 7102 7103
dev2 7112 7113
tst2 7122 7123
uat2 7132 7133
 trn2 7142 7143
efx2 7152 7153
prd2 7182 7183

3. When the range only allows the last digit to change or it only covers a range of 10 to 20
ports or any time the first and second rules don’t apply:

vi. The numbers within the range are assigned sequentially and documented

vii. Even numbers will be assigned to the Middle tier

viii. Odd numbers will be assigned to the infrastructure.

For example: for the Application Server Control range (1810-1829) we will use:

Landscape Middle-Tier Infrastructure

sbx 1810 1811
dev 1812 1813
tst 1814 1815
uat 1816 1817
trn 1818 1819
efx 1820 1821
prd 1822 1823

If a second instance of any of these landscapes is created, it will take on the

following ports:

Landscape Middle-Tier Infrastructure

sbx2 1824 1825
efx2 1826 1827
prd2 1828 1829

Port Numbers Recommended by Oracle(Sorted by Port Number)

Port
Number Service
21 Oracle Content Management Software Development Kit FTP
25 Oracle Content Management Software Development Kit SMTP
137 Oracle Content Management Software Development Kit NB UDP
139 Oracle Content Management Software Development Kit SMB
143 Oracle Content Management Software Development Kit IMAP (non-
SSL)
Port
Number Service
389 Oracle Internet Directory (non-SSL)
443 Oracle HTTP Server Port (SSL) (Windows only)

OracleAS Web Cache HTTP Listen (SSL) (Windows only)

548 Oracle Content Management Software Development Kit AFP
636 Oracle Internet Directory Server (SSL)
993 Oracle Content Management Software Development Kit IMAP
(SSL)
1098 Oracle Ultra Search RMI Daemon
1099 Oracle Ultra Search RMI Registry
1156 Oracle Enterprise Manager 10g Application Server Control Console
(non-SSL and SSL) (UNIX)
1157 Oracle Management Agent
1521 OracleAS Metadata Repository Oracle Net Listener
1810-1829 Oracle Enterprise Manager 10g Application Server Control Console
(non-SSL and SSL)
1830-1849 Oracle Management Agent
1850-1869 Oracle Enterprise Manager 10g Application Server Control Console
RMI
2049 Oracle Content Management Software Development Kit NFS
2550 - 2577 OracleAS Integration B2B Attunity Adapters (Legacy Adapters)
4180 Oracle Content Management Software Development Kit CUP
4443 Oracle HTTP Server Listen (SSL) and Oracle HTTP Server Port
(SSL)
4550 - 4599 OracleAS Integration B2B Actional Listener
4889 - 4899 Oracle Management Service (SSL and non-SSL)
5110 - 5119 OracleAS Integration B2B Adapter RMI
5500 - 5559 Oracle Enterprise Manager Console HTTP
6003 - 6099 OPMN ONS Request
6100 - 6199 OPMN ONS Local
6200 - 6299 OPMN ONS Remote
6600 - 6619 OracleAS Certificate Authority Server Authentication Virtual Host
Port
Number Service
(SSL)

OracleAS Certificate Authority Mutual Authentication Virtual Host

(SSL)
7000 - 7099 Java Object Cache
7100 - 7199 DCM Discovery
7200 - 7299 Oracle HTTP Server Diagnostic
7501 - 7599 Port Tunneling
7777 - 7877 Oracle HTTP Server Listen and Oracle HTTP Server Port

OracleAS Web Cache HTTP Listen

7890 - 7895 Oracle Application Server Guard
8250 - 8350 Oracle HTTP Server Listen (SSL) and Oracle HTTP Server Port
(SSL)

OracleAS Web Cache HTTP Listen (SSL)

8777 - 8900 OracleAS Integration B2B Integration Manager

OracleAS Integration B2B Adapter Framework

9100 - 9199 Wireless Notification Dispatcher Calendar
9400 - 9499 OracleAS Web Cache Administration

OracleAS Web Cache Invalidation

OracleAS Web Cache Statistics

9700 Oracle BPEL Process Manager

9901 OracleAS Integration InterConnect RMI port for HTTP

9998-9999 SOAP server
12401 - OC4J RMI
12500
12501 - OC4J AJP
12600
12601 - OC4J JMS
12700
Port
Number Service
13060 - Oracle Internet Directory (non-SSL)
13129
13130 - Oracle Internet Directory (SSL)
13159
13161 - Oracle Internet Directory (SSL)
13199
13301 - OC4J IIOP
13400
13401 - OC4J IIOPS1 (Server only)
13500
13501 - OC4J IIOPS2 (Server and client)
13600
14011 - OracleAS Reports Services bridge (RWBRIDGE)
14020
14021 - OracleAS Reports Services Discovery Service (RWNETWORK)
14030
14040 - OracleAS Reports Services SQL*Net
14049
16001 - OracleBI Discoverer Preferences
16020
18100 - Oracle Enterprise Manager 10g Application Server Control Console
18119 (non-SSL and SSL)
18120 - Oracle Management Agent
18139
18140 - Oracle Enterprise Manager 10g Application Server Control Console
18159 RMI
20300 - OracleAS Integration B2B Actional Agent
20350
44000 - Log Loader
44099
53140 - Oracle Content Management Software Development Kit Domain
53999 Controller

Oracle Content Management Software Development Kit Node

Guardian

Oracle Content Management Software Development Kit Node

Port
Number Service
Manager

Appendix E – Oracle Application server Instances

Note: Developers/administrators should connect with IPs rather than

physical host names, as a landscape (and its associated disks) are not tied
to specific machines. Unlike Tru64, disks are not visible across all cluster
hosts simultaneously

Middle tier Instances:

Instant / IP address
xyz
Environment Shorthand Root
Base Apache Server Application
/ code Directory
Accounts
Landscape

Sand Box 142.32.236.70 sbx2 http://oassbx2.educ.bc.ca:8000/ /oassbx1 xyz_sbx

Development 142.32.236.103 dev1 http://oasdev1.educ.bc.ca:8010/ /oasdev1 xyz_dev

Programmer 142.32.236.105 tst1 http://oastst1.educ.bc.ca:8020/ /oastst1 xyz_tst

Testing

User 142.32.236.111
Acceptance uat1 http://oasuat1.educ.bc.ca:8030/ /oasuat1 xyz_uat
Testing

Training 142.32.236.107 trn1 http:// oastrn1.educ.bc.ca:8040/ /oastrn1 xyz_trn

Emergency 142.32.236.109 efx1 http://oasefx1.educ.bc.ca:8050/ /oasefx1 xyz_efx

Fix

Production 142.32.236.101 prd1 http://oasprd1.educ.bc.ca :8080/ /oasprd1 xyz_prd

If a second instance of any of the above is created, they will be named as follows:

Instant /
Shorthand Root xyz Application
Environment / Base Apache Server
code Directory Accounts
Landscape

Sand Box sbx2 http://oassbx2.educ.bc.ca:800x/ /oassbx2 xyz_sbx

Development dev2 http://oasdev2.educ.bc.ca:801x/ /oasdev2 xyz_dev

Instant /
Shorthand Root xyz Application
Environment / Base Apache Server
code Directory Accounts
Landscape

Programmer
tst2 http://oastst2.educ.bc.ca:802x/ /oastst2 xyz_tst
Testing

User Acceptance
uat2 http://oasuat2.educ.bc.ca:803x/ /oasuat2 xyz_uat
Testing

Training trn2 http:// oastrn2.educ.bc.ca:804x/ /oastrn2 xyz_trn

Emergency Fix efx2 http://oasefx2.educ.bc.ca:805x/ /oasefx2 xyz_efx

Production prd2 http://oasprd2.educ.bc.ca :808x/ /oasprd2 xyz_prd

For the last digit of the port, The letter x has been used since a number of the ports in that
range may have been used by the first instance

For a second instance, the application accounts do not change.

Infrastructure Instances

Instant / Shorthand
Base Apache Server Root Directory
Environment / Landscape code

Sand Box sbx http://oaisbx1.educ.bc.ca:8100/ /oaisbx1

Development dev http://oaidev1.educ.bc.ca:8110/ /oaidev1

Programmer Testing tst http://oaitst1.educ.bc.ca:8120/ /oaitst1

User Acceptance Testing uat http://oaiuat1.educ.bc.ca:8130/ /oaiuat1

Training trn https://oaiprx1.educ.bc.ca:8140 /oaitrn1

Emergency Fix efx http://oaiefx1.educ.bc.ca:8150/ /oaiefx1

Production prd http://oaiprd1.educ.bc.ca:/8180 /oaiprd1

If a second instance of any of the above is created, they will be named as follows:

Instant / Shorthand
Base Apache Server Root Directory
Environment / Landscape code

Sand Box sbx2 http://oaisbx2.educ.bc.ca:8100/ /oaisbx2

Instant / Shorthand
Base Apache Server Root Directory
Environment / Landscape code

Development dev2 http://oaidev2.educ.bc.ca:8110/ /oaidev2

Programmer Testing tst2 http://oaitst2.educ.bc.ca:8120/ /oaitst2

User Acceptance Testing uat2 http://oaiuat2.educ.bc.ca:8130/ /oaiuat2

Training trn2 https://oaiprx2.educ.bc.ca:8140 /oaitrn2

Emergency Fix efx2 http://oaiefx2.educ.bc.ca:8150/ /oaiefx2

Production prd2 http://oaiprd2.educ.bc.ca:/8180 /oaiprd2