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:

FIRE WALL

Middle Tier Architecture

APPLICATIONSERVERS(OAS 10g)

DMZ

DATABASESERVERSDATABASE SERVERS

FIRE WALL

INTERNET

INTERA-NET

PUBLIC WEBSERVERS(Apache)

Desktop Laptop PDA

TUNNEL

Figure 1 – Middle Tier Architecture – High level view

TUNNEL

Gateway TierGOLD Cluster

Middle TierDean Cluster

Database TierWhite Cluster

Application ServerTier

Public GatewayTier

OLTP Tier

Forms Service

OAS 10g

mod_ proxy

Apache

Reports Server

OC4J

Portal

Oracle RDBMS

Intranet Client

Data

Application

Generic User

Headstart

GAME

Corporate

Subject Area

HTTP Server

mod_plsqlmod_ sm

mod_ssl

Internet Client

DMZ-Firewall

Firewall

Client Tier

Named User

LEGENDGeneric User = xxx_web

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/server :/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"></destination>

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 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 3 404122-B21 8 GB RAM (2 x 4GB 2RANK) PC2-3200R 400MHz DDR2 memory 1 364639-B21 DL580 G3 Memory Board 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 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 Infrastructuresbx 800x 810xdev 801x 811xtst 802x 812xuat 803x 813xtrn 804x 814xefx 805x 815xprd 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 Infrastructuresbx 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 Infrastructuresbx2 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 Infrastructuresbx 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 Infrastructuresbx2 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 - 12500

OC4J RMI

12501 - 12600

OC4J AJP

12601 - 12700

OC4J JMS

Port Number Service

13060 - 13129

Oracle Internet Directory (non-SSL)

13130 - 13159

Oracle Internet Directory (SSL)

13161 - 13199

Oracle Internet Directory (SSL)

13301 - 13400

OC4J IIOP

13401 - 13500

OC4J IIOPS1 (Server only)

13501 - 13600

OC4J IIOPS2 (Server and client)

14011 - 14020

OracleAS Reports Services bridge (RWBRIDGE)

14021 - 14030

OracleAS Reports Services Discovery Service (RWNETWORK)

14040 - 14049

OracleAS Reports Services SQL*Net

16001 - 16020

OracleBI Discoverer Preferences

18100 - 18119

Oracle Enterprise Manager 10g Application Server Control Console (non-SSL and SSL)

18120 - 18139

Oracle Management Agent

18140 - 18159

Oracle Enterprise Manager 10g Application Server Control Console RMI

20300 - 20350

OracleAS Integration B2B Actional Agent

44000 - 44099

Log Loader

53140 - 53999

Oracle Content Management Software Development Kit Domain 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 / Environment / Landscape

IP address Shorthand code Base Apache Server Root

Directory xyz Application Accounts

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 Testing

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

User Acceptance Testing

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

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

Emergency Fix

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

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 / Environment / Landscape

Shorthand code Base Apache Server Root

Directory xyz Application Accounts

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

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

Instant / Environment / Landscape

Shorthand code Base Apache Server Root

Directory xyz Application Accounts

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

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

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 / Environment / Landscape

Shorthand code Base Apache Server Root Directory

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 / Environment / Landscape

Shorthand code Base Apache Server Root Directory

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

Instant / Environment / Landscape

Shorthand code Base Apache Server Root Directory

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