A Note on proxy jar

We all know that after you have deployed a web service archive (typically webservices.war) to OC4J, the WSDL of the web service and the client side stubs can be generated on demand. 

To access the WSDL of the web service you have deployed, just point your browser to 

http://host:port//?wsdl. 

To access the client side proxy stubs, point your browser to 

http://host:port//?proxy_jar (proxy_source for source code). 

value is the element value you specified in the META-INF/application.xml of your web service archive

value is the element value you specified in the WEB-INF/web.xml of your web module in the web service archive. 

There is proxy jar file which contains a Java class to serve as a proxy of the web service implementation reside in the server, it must be included in the CLASSPATH of your client application. The OC4J web services proxy jar file handles the construction of the soap request, marshal and unmarshal the parameters,etc . For each method exposed on the web service, there is a correspondent method in this proxy class, all you need to do is creating a client proxy and invoke the methods as follows: 

MyWebServiceProxy proxy = new MyWebServiceProxy(); 

proxy.myMethod(); 

What is 64-bit computing and what are its benefits?

A 64-bit CPU system is the one, which has a 64-bit microprocessor & can directly address physical memory with a 64-bit address.

The key benefits of 64-bit computing are that it can perform high-precision computations faster than 32-bit systems, and it can directly address huge amount of physical memory.

64-bit microprocessors process 64-bit data in one clock cycle. All the registers associated with the microprocessors are 64-bit. This enables High- precision computations and 64-bit arithmetic to be performed in fewer clock-cycles as compared to 32-bit microprocessors. In certain cases like 64-bit multiplication, it is twice as fast.

32-bit microprocessors can directly address a maximum of 232 ~= 4 GB of memory, while 64-bit microprocessors have pushed this limit further and can directly address up to a maximum of 264 bytes = ~16 Exabytes = ~17.2 billion GB of physical memory. Practically speaking, this means that applications running on a 64-bit microprocessors have unlimited memory available to them. However, most of the 64-bit systems and operating systems available today pose a limit on the amount of RAM that they can recognize.

Sun first introduced a 64-bit version of Java for their Solaris operating system on SPARC processors with Java Development Kit (JDK) 1.4. The JDK 1.5 and JDK 1.6 releases introduced support for the x86-64 processors made by Intel, these processors are widely used by Windows, Linux, and Mac OS× operating systems today. The main implication of 64-bit in Java relates to the heap space used by Java applications and the algorithm used for garbage collection of the objects created on the heap.

When a Java application executes and creates objects, the objects are stored in a place called heap. The amount of heap space an application can use depends on the operating system, the amount of RAM available in the system, and the amount of memory that the hardware can address. A 32-bit system, as discussed earlier, can support a maximum of 4GB memory. But not all 4GB RAM space is available for use by a single Java application. For instance, an OS uses some of the RAM space. Assuming that the hardware has 4 GB RAM, the maximum heap space a typical application can use would be 1.2 GB to 2 GB. However, this limit is not true for Java applications on a 64-bit CPU system. The value that you can set for the maximum java heap space on a 64-bit CPU system is only limited by the limitations of hardware and the OS (as discussed in the previous section).

You can increase or decrease heap space for Java applications by changing the Xmx value in your Java command line arguments.

How to configure Indirect Password using Enterprise Manager Data Source?

In production environments, while configuring datasources in OC4J using Enterprise Manager, the credential password should not be exposed as clear text. To secure it, there is an option called "Use Indirect Password" while configuring datasources in Oracle SOA Suite 10.1.3.1.

Step 1:

As shown above, provide the "Indirect Password" such as "PwdForORABPEL" & save the data source. This updates the following file

ORACLE_HOME\j2ee\OC4J_HOME\config\data-sources.xml

Step 2:

Provide the actual Indirect Password in ORACLE_HOME\j2ee\OC4J_HOME\config\system-jazn-data.xml

Step 3:

Restart the OC4J. This encrypts the password like the one as shown below

How does URL sent to Web Listener reach OC4J?

An OC4J instance is a process running externally to Apache. The user’s entry point to an OC4J is, as for all Oracle Application Server components, a URL sent to an Apache web listener.

A typical httpd.conf file will include a line such as this

include "c:\oracle\ias9i\Apache\Apache\conf\mod_oc4j.conf"

which points to the file that configures the module modoc4j. The following is a simple version of this file:

LoadModule oc4j_module modules/ApacheModuleOc4j.dll

<IfModule mod_oc4j.c>

Oc4jMount /j2ee/* Oc4jMount /hrj demo

</IfModule>

This file first specifies the dynamic link library that is the modoc4j code and then creates two virtual paths with the Oc4jMount directive. This is a token that takes two values: the first is a virtual path; the second is the name of an OC4J instance to which to send URLs with that virtual path.

So if the Apache instance receives this URL

http://hostname.com:7777/hrj/helloworld?name=barani

Apache will pass it through to an OC4J instance called demo, which will load and run the Java class helloworld using the value barani for the argument name.The first Oc4jMount directive only has a single value: the virtual path /j2ee/*.All URLs that include this path will be dispatched to the default OC4J instance, which is known as the home instance.

There are various communications protocols used in the OC4J application environment.First, end users’ browsers use HTTP to send URLs to the Apache web listener.These requests are routed to modoc4j within the Apache executable, and then modoc4j uses AJP1.3 (Apache Jserv Protocol version 1.3) to send the request on to the appropriate OC4J instance. The OC4J instance will load and run the requested Java class, which is probably a servlet. The servlet may then use RMI to contact a Java bean, which could again be running in a different OC4J instance on a different machine. Then the bean might use Oracle Net to contact a database and LDAP to contact an OID.

How to Integrate OracleAS JAAS Provider with Basic Authentication?

Basic Authentication in J2EE Environments

In this environment, Oracle AS SSO is not used.A login module such as RealmLoginModule is used. 

An HTTP client attempts to access a Web application hosted by OC4J.Oc4J invokes the RealmLoginModule whenever user credentials are required. For e.g. when a user hits a protected page,OC4J will ask Oracle AS JAAS provider to authenticate the user.The RealmLoginModule will be invoked to authenticate the user, using the credentials sent by the user via browser over HTTP.

Then Oracle JAAS provider retrieves the user. The following sections speak about this in detail.

I.Authentication in the J2EE Environment

Authentication is the process of verifying the identity of a user in a computing system. In Oracle Application Server, authentication in the J2EE environment is performed by the following:

• OracleAS Single Sign-On (for OracleAS Single Sign-On environments)
  
• OracleAS JAAS Provider RealmLoginModule or other login module (for non-OracleAS Single Sign-On environments)

Retrieving Authentication Information

The following javax.servlet.HttpServletRequest APIs retrieve authentication information within the servlet.

• getRemoteUser() for the authenticated user name
  
• getAuthType() for the authentication scheme
  
• getUserPrincipal() for the authenticated principal object
  

II.Authorization in the J2EE Environment

Authorization is the process of granting permission & privileges to an authenticated user. Authorization is achieved through JAZNUserManager. The JAZNUserManager gets the authenticated user information (set by mod_osso) from the HTTP request object & sets the JAAS subject in OC4J.

Retrieving Authorization Information

• Servlet.service() in the servlet
  
• Subject.doAs() and Subject.doAsPrivileged() in the client
  
• SecurityManager.checkPermission() in the server
  

III.Security Role Mapping

Two distinct role types available to application developers creating secure applications in J2EE environment are J2EE roles & JAAS roles.

This section describes these role types and how they are mapped together.

• J2EE Security Roles
  
• Deployment Roles and Users
  
• OC4J Group Mapping to J2EE Security Roles
  

J2EE Security Roles

The J2EE development environment includes a portable security roles feature defined in the web.xml file for servlets and JavaServer Pages (JSP). For example, an application defines a security role called sr_developer:

<security-role> 

<role-name>

sr_developer

</role-name> 

</security-role>

You also define the access permissions for the sr_developer role.

<security-constraint> 
<web-resource-collection> 
<web-resource-name>access to the entire application

</web-resource-name> 
<url-pattern>/*</url-pattern> 

</web-resource-collection> 
<!-- authorization -->

<auth-constraint> 
<role-name>
sr_developer
</role-name> 

</auth-constraint> 
</security-constraint>

Deployment Roles and Users

JAAS roles and users are defined depending on the provider type, LDAP-based or XML-based.

For example, with the XML-based provider type, developer is listed as a role in the jazndata.

xml file:

<role> 

<name>
developer
</name> 
<members> 
<member> 
<type>user<type> 
<name>john<name> 
</member> 
</members> 
</role>

OC4J Group Mapping to J2EE Security Roles

OC4J enables you to map portable J2EE security roles defined in the J2EE web.xml file to groups in an orion-application.xml file. The roles and users defined in your provider environment are mapped to the OC4J developer group role in the orion-application.xml file.

For example, the sr_developer security role is mapped to the group named developer.

<security-role-mapping name="sr_developer">

<group name="developer" />

</security-role-mapping>

How to use Java Naming & Directory Interface (JNDI) in a J2EE application?

Naming Concepts

i.Naming Service
A fundamental facility in any computing system is the naming service-the means by which the names are associated with objects & objects are found based on their names.
For e.g, 

• when you use an electronic mail system, you must provide recipient's email address
  
• Internet Domain Naming System (DNS) maps machine names to IP addresses. For e.g www.oracle.com => 99.99.99.99
  
• A file system maps a file name to a file reference. For e.g c:\bin\text.txt => File reference

ii. Names
To lookup an object in a naming system,you must supply the name of the object. The syntax is called system's naming convention.
Naming System       Component Separator  Names
Unix File System       "/"                                /usr/Hello
DNS                         "."                               www.oracle.com
LDAP                        "," & "="                     cn=barani,cn=users, dc=company,dc=com

iii.Bindings
The association of a name with an object is called a binding. An LDAP name is bound to an LDAP entry.
iv. Context
A context is a set of "name-to-object" binding. A context always provides a lookup operation that returns the object.
What is a directory service?
Directory Service= Naming Service + Directory objects containing attributes

Java Naming & Directory Interface
It is an API that provides naming & directory functionality to applications written in Java. Some of the key interfaces available are

a) Context
The javax.naming defines a "Context" interface which is the core interface for looking up , binding/unbinding & creating/destroying sub-contexts.

b) InitialContext
In the JNDI, all the naming & directory operations are performed relative to a context. There are no absolute roots. Therefore, JNDI defines an InitialContext which provides a starting point for naming & directory operations.

c) DirContext
It represents a directory context. It behaves as a naming context by extending the getAttributes() to retrieve the attributes associated with the directory entry.

Java Naming and Directory Interface in OC4J
JNDI, in the form of jndi.jar, is available with OC4J. J2EE-compatible applications use JNDI to obtain naming contexts that enable the application to locate and retrieve objects such as data sources, local & remote EJBs, JMS services, and many other J2EE
objects and services.
i. Initial Context
The two most often-used JNDI operations in the J2EE applications are 

• Creating a new InitialContext object
  
• Using the InitialContext, looking up a J2EE or other resource
  

When OC4J starts up, it constructs a JNDI initial context for each application.
ii.Constructing a JNDI context
The environment that OC4J uses to construct a JNDI initial context can be found in several places. These include:

• System property values, as set either by the OC4J server or possibly by the application container
  
• A jndi.properties file contained in the application EAR file
  
• An environment specified explicitly in a Hashtable passed to the JNDI initial context constructor

The JNDI InitialContext has two constructors:

1.  InitialContext()
   
2.  InitialContext(Hashtable env)
   

The second form of the InitialContext constructor is normally used in client applications. The env parameter in the constructor is a Hashtable that contains properties required by JNDI. These properties are:

1. INITIAL_CONTEXT_FACTORY
2. PROVIDER_URL
   
3. SECURITY_PRINCIPAL
   
4. SECURITY_CREDENTIAL
   

INITIAL_CONTEXT_FACTORY
A value for the java.naming.factory.initial property that specifies which initial context factory to use when creating a new initial context object.

PROVIDER_URL
The URL that application client code uses to look up objects on the server.

SECURITY_PRINCIPAL
The user name. Required in application client code to authenticate the client.

SECURITY_CREDENTIAL
The password. Required in application client code to authenticate the client

There are three JNDI initial context factories that are available for use by application code. They are

1. ApplicationClientInitialContextFactory
   
2. ApplicationInitialContextFactory
   
3. RMIInitialContextFactory
   

The following sections describe each of these factories and their uses in OC4J applications

I. ApplicationClientInitialContextFactory
When an application client needs to look up a resource that is available in a J2EE server application, the client uses ApplicationClientInitialContextFactory as to construct the initial context.

Consider an application client that consists of Java code running outside the OC4J server, but that is part of a bundled J2EE application. For example, the client code running on a workstation and might connect to a server object, such as an EJB, to perform some application task. In this case, the environment accessible to JNDI must specify the value of the property java.naming.factory.initial as ApplicationClientInitialContextFactory.

Using the ApplicationClientInitialContextFactory to construct JNDI initial contexts means that the client can look up local objects using the java:comp/env mechanism, and can use ORMI to look up remote objects.

Example
...
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.ApplicationClientInitialContextFactory");
env.put(Context.PROVIDER_URL,"ormi://<hostname>/employee");
env.put(Context.SECURITY_PRINCIPAL, "admin");
env.put(Context.SECURITY_CREDENTIALS, "welcome");
Context context = new InitialContext(env);
//do the lookups...
...
II. ApplicationInitialContextFactory
Server-side clients need not specify an InitialContextFactory in order to look up resources defined within the client application. By default, serverside clients have InitialContextFactory set to ApplicationInitialContextFactory. 
Example

try {
InitialContext ic = new InitialContext();
ds = (DataSource) ic.lookup("java:comp/env/jdbc/OracleDS1");
...
}
catch (NamingException ne) {
throw new ServletException(ne);
}
...
III. RMIInitialContextFactory
Using either the default server-side ApplicationInitialContextFactory, or specifying ApplicationClientInitialContextFactory, will work for most application purposes.

RMIInitialContextFactory is used when doing a general lookup for external JNDI objects, that may or may not be part of a J2EE application. A generalized JNDI object browser would be an example of this usage.

What is Implicit Connection Caching in OC4J 10.1.3.1?

OC4J 10.1.3 Datasources: An overview

OC4J 10.1.3 has simplified the data source classification. Now there are only two types of datasources

• Managed data source
• Native data source

Managed data sources are the data sources managed by OC4J. Specifically, a managed data source is an OC4J-provided implementation of the java.sql.DataSource that acts as a wrapper to a JDBC driver or data source.J2EE components access managed datasources via JNDI with no knowledge that the data source implementation is a wrapper.OC4J provides critical system infrastructure such as global transaction management, connection caching, error handling, for managed data sources.

Native data sources also implement the java.sql.DataSource interface & are provided by JDBC Vendors such as Oracle. Native data sources are not wrapped by OC4J at all.

Key advantages of managed data sources over native data sources are summarized in the following table:

1. Managed Data sources connections retrieved from a data source can participate in global transactions
2. Data source makes use of OC4J's connection pool and statement caches

What is connection caching?

Connection caching, generally implemented in the middle tier allows a single database connection to be shared among different applications. The middle tier maintains a pool of pre-allocated physical database connections. When applications request a database connection, the middle tier first looks into the pool to see if there are any available connections that would satisfy the request;if so, the middle tier simply returns one of those connections.

If the connection cache does not have any free-pooled connection instances, new pooled connection instances are created. A "free-pooled" connection instance is the one that has no logical connection associated with it.

When applications close the connections, the middle tier would send the connections back to the pool thereby avoiding the resource-intensive task of opening a new database connection each time a connection request is made.

Connection Caching in OC4J 10.1.3 Datasources 

Implicit Connection Cache

Prior to Oracle 10g , Oracle's JDBC connection cache interface was named OracleConnectionCache & its implementation was named OracleConnectionCacheImpl. The cache only supported pooling of physical connections to a particular database for a specified username.In Oracle 10g JDBC, the OracleConnectionCache interface and OracleConnectionCacheImpl class are both deprecated.

Implicit Connection Cache is a new JDBC-3.0 compliant connection cache implementation for data sources.

The implicit connection cache works on the concepts of physical and logical connections. The physical connections are the actual connections returned by the database & the logical connections can be thought of handles used by the cache to manipulate the physical connections.

Implicit connection caching also provides a new class OracleConnectionCacheManager so that applications can use its rich set of administrative APIs to create,manage& maintain connection cache in an effective way.

How to configure Connection Cache Declaratively in OC4J 10.1.3.1?

In OC4J, navigate to ‘Administration tab’. Click on “JDBC Resources”. Now in the ‘Connection Pools’ division, click ‘Create’.

Besides the standard parameters such as maximum pool size, minimum pool size, maximum number of attempts, maximum period of time of inactivity, etc OC4J 10.1.3 offers various new parameters such as

• validate-connection
• abandoned-connection-timeout

Both the above parameters play a very important role in ensuring that DB connections never go stale. When set to true, validate-connection first validates the connection before giving it to the session bean.Similarly abandoned-connection-timeout is explicitly applicable for logical connections. The connection manager monitors the database-execute calls issued by each DB connection & based on the inactive time reclaims & recycles the connection.

How to secure J2EE application in OC4J by Basic Authentication?

Steps to do 

Step 1:

Create a Privileged group in OID by name "myTrustedUsers" by using OIDDAS. Make this group available as a role.

Step 2:Navigate to 

$ORACLE_HOME/j2ee/<OC4J_NAME>/applicationdeployments/<APPLICATION_NAME>/orion-application.xml

Add the following lines inside <orion-application>,

<jazn provider="LDAP" default-realm="DEFAULT_REALM_NAME"/>

A simple way to verify the default-realm from within this list is to login in to the OIDDAS application:

http://<infra_host>:<port>/oiddas as "orcladmin" then create a new user.

After creating the user, locate the user by clicking the "Users" tab and then entering a query for the name of that user. In the list returned, select the radio button to the left of the user entry then click on the Edit button.Scroll down to the botton of the page returned, where you will find the section "EditHistory" and information similar to the following:

Created By cn=orcladmin,cn=users,dc=realmname,dc=com

Created At March 24, 2004 6:23:50 PM EST

Last Modified By cn=orcladmin,cn=users,dc=realmname,dc=com

Last Modified At March 24, 2004 6:23:50 PM EST

Look at the distinguished name for the "Created By" entry. The value for the default realm should also be the value of the first "dc=" entry immediately to the right of the cn=users

Step 3:

Edit the following file to create a security role

$ORACLE_HOME/j2ee/<OC4J_NAME>/applicationdeployments/<APPLICATION_NAME>/<APPLICATION_NAM E>/orion-web.xml

Add the following lines inside ,

<security-role-mapping impliesAll="false" name="trustedUsers"> 

<group name="myTrustedUsers"/> 

</security-role-mapping> 

The <security-role-mapping> maps the *logical* role "trustedUsers" (used by the application) to the physical role "myTrustedUsers" which is available in LDAP repository.

Step 4:

Now provide the role created in Step 3 in the following file,

$ORACLE_HOME/j2ee/<OC4J_NAME>/applications/<APPLICATION_NAME>/<APPLICATION_NAME>/WEB-INF/web.xml

A) Add <security-constraint> under <web-app> as shown below

<security-constraint> 

<web-resource-collection> 

<web-resource-name>protected

</web-resource-name> 

<url-pattern>/ *</url-pattern> 

</web-resource-collection> 

<auth-constraint> 

<role-name>trustedUsers

</role-name> 

</auth-constraint> 

</security-constraint>

B) Provide the <security-role> under <web-app> as shown below

<security-role> 

<role-name>trustedUsers

</role-name> 

</security-role>

C)Add <login-config> under <web-app> by providing the default realm

<login-config> 

<auth-method>BASIC</auth-method> 

<realm-name>realmname</realm-name> 

</login-config>

How to secure J2EE applications in an OC4J by Oracle SSO?

JAAS Providers

To secure web applications OC4J leverages Oracle Application Server Java Authentication & Authorization Service (JAAS) which supports two types

1.JAZN-XML

This provider type maintains the repository of user information in an XML file in the file system. This repository may be maintained using text editors or JAZN Admin tool:

% cd $ORACLE_HOME/j2ee/home

% cd java -jar jazn.jar -shell

2. JAZN-LDAP

This provider type stores the user information as LDAP entries in Oracle Internet Directory (OID). The principals, roles & permissions can be navigated and maintained using the following

1. Oracle Directory Manager (ODM)

2. JAZN Admin Tool

3. OID Delegated Administration Services (OIDDAS)

Of the mentioned above, OIDDAS is the simplest one to use.

When using SSO, it is necessary to configure OC4J to use JAZN-LDAP provider as SSO engine authenticates users against LDAP directory.

Steps to do 

Step 1:

Create a Privileged group in OID by name "myTrustedUsers" by using OIDDAS. Make this group available as a role.

Step 2:Navigate to 

$ORACLE_HOME/j2ee/<OC4J_NAME>/applicationdeployments/<APPLICATION_NAME>/orion-application.xml

Add the following lines inside <orion-application>,

<jazn provider="LDAP" default-realm="companyname" location="ldap://hostname:portno" > 

<property name="ldap.user" value="cn=orcladmin" /> 

<property name="ldap.password" value="!welcome456" /> 

<jazn-web-app auth-method="SSO" /> </jazn>

• The hostname of the URL used for the "location" attribute should match the location of the OID Server used by the Infrastructure install
• The port value is provided in the file:$ORACLE_HOME/install/portlist.ini
• The value for "default-realm" also needs to be appropriate to the site. You can find out the default realm by the following way

A simple way to verify the default-realm from within this list is to login in to the OIDDAS application:

http://<infra_host>:<port>/oiddas as "orcladmin" then create a new user.

After creating the user, locate the user by clicking the "Users" tab and then entering a query for the name of that user. In the list returned, select the radio button to the left of the user entry then click on the Edit button.Scroll down to the botton of the page returned, where you will find the section "EditHistory" and information similar to the following:

Created By cn=orcladmin,cn=users,dc=company,dc=com

Created At March 24, 2004 6:23:50 PM EST

Last Modified By cn=orcladmin,cn=users,dc=company,dc=com

Last Modified At March 24, 2004 6:23:50 PM EST

Look at the distinguished name for the "Created By" entry. The value for the default realm should also be the value of the first "dc=" entry immediately to the right of the cn=users

Step 3:

Edit the following file to create a security role

$ORACLE_HOME/j2ee/<OC4J_NAME>/applicationdeployments/<APPLICATION_NAME>/<APPLICATION_NAM E>/orion-web.xml

Add the following lines inside ,

<security-role-mapping impliesAll="false" name="trustedUsers"> 

<group name="myTrustedUsers"/> 

</security-role-mapping> 

<jazn-web-app auth-method="SSO"/>

The <security-role-mapping> maps the *logical* role "trustedUsers" (used by the application) to the physical role "myTrustedUsers" which is available in LDAP repository.

Step 4:

Now provide the role created in Step 3 in the following file,

$ORACLE_HOME/j2ee/<OC4J_NAME>/applications/<APPLICATION_NAME>/<APPLICATION_NAME>/WEB-INF/web.xml

A) Add <security-constraint> under <web-app> as shown below

<security-constraint> 

<web-resource-collection> 

<web-resource-name>protected

</web-resource-name> 

<url-pattern>/ *</url-pattern> 

</web-resource-collection> 

<auth-constraint> 

<role-name>trustedUsers

</role-name> 

</auth-constraint> 

<user-data-constraint> 

<transport-guarantee>NONE</transport-guarantee> 

</user-data-constraint> 

</security-constraint>

B) Provide the <security-role> under <web-app> as shown below

<security-role> 

<role-name>trustedUsers

</role-name> 

</security-role>

Now,all URLs within the application accessed will first be redirected to the SSO server for appropriate authentication.

How to configure OC4J 10.1.2 to use JDK/JRE 1.5?

Step 1:

Create Separate OC4J Instance to use JDK 1.5 (OC4J_TEST as shown) on Oracle Application Server 10.1.2 using Enterprise Manager.

Step 2:

Install the JDK 1.5 or above in the Solaris in the different file system (for Example:

/appsrv/10.1.2/jdk1.5), the java executable path needs to be find out (i.e.

/appsrv/10.1.2/jdk1.5/bin/java) . This needs to be added as part of environment variable.

Step 3:

Click on OC4J_TEST container, it will take you to container home page. 

Step 4:

Click on Administration option, where you can find out Server Properties and click on this. It

will take you through next screen.

Step 5:

In the command line options (Please refer to the figure below),

Please type your java executable path obtained from Step 2 (i.e. /appsrv/10.1.2/jdk1.5/bin/java) and leave the OC4J options as it is.

Step 6: 

On the java options, Add additional line as follows 

-Xbootclasspath/p:/appsrv/10.1.2/jdk1.5/lib/tools.jar

Then press the apply button, if there is any syntax error then you will find error otherwise

the OC4J_TEST will be re-started after applying the changes.

How to improve J2EE Application performance running in an OC4J?

Tuning OC4J options lets you improve the performance of J2EE applications running in an OC4J.

The following are some of the ways of doing it

I. Setting the JVM Heap Size for OC4J processes

If you have sufficient memory available in the system, you can improve application performance by increasing the JVM heap size by specifying the following options

-XmsSIZEM -XmxSIZEM

If you know that application consistently requires a large amount of heap memory, you can improve the performance by setting the minimum size equal to the maximum heap size i.e setting 

-XmsSIZEm to be equal to -XmxSIZEm

For e.g.

-Xms512m -Xmx512m specifies a JVM heap size of 512 MB

II. Setting the JVM AggressiveHeap Option for OC4J processes

In the Java Virtual Machine 1.4.2, -XX:+AggressiveHeap option is optimized for long-running, memory intensive applications. Many applications will exhibit dramatic improvement in perfomance and scalability if the -XX:+AggressiveHeap option is specified.

III. Setting the JVM Stack Size for OC4J processes

This option sets the maximum JVM stack size for C code. The default C code stack size is 512k. You can try changing the value to 128k to improve the performance of J2EE applications as shown below

-Xss128k

IV.Setting the JVM Permanent Generation Option for OC4J Processes

The MaxPermSize option defines the size of the permanent generation  in the JDK. The default value is 64K.  However if your applications dynamically generate and load many classes that require a larger permanent generation size, you may see java.lang.OutOfMemory errors eventhough you have plenty of memory available in the Heap. If this occurs, change the Permanent Generation Size setting as follows

-XX:MaxPermSize=SIZEm

You should pay attention to the permanent generation size while deploying large applications to the OC4J since it may contain hundreds and thousands of EJB modules which may require JVM to load large number of classes. 

PermSize is in addition to the -Xmx value set by the user in JVM options. 

If you were to set both the PermSize & MaxPermSize to 256 MB, you would notice that the overall heap has grown 256 MB in addition to the -Xmx setting. You could check with 'pmap' command in solaris to see the memory the resulting process is taking up.

To set the total heap size to 768 MB, set the following at OC4J startup,

java -Xms512m -Xmx512m -XX:MaxPermSize=256m

To determine the MaxPermSize property, you can use visualgc to monitor OC4J JVM during application deployment.

How does a J2EE application explodes into an OC4J after deployment?

A typical application directory structure during development is as shown in the figure.

When you deploy your application, the following occurs:

1. OC4J opens up and parses application.xml that exists in the EAR file. The application.xml lists all the modules that are contained in the EAR file. OC4J notes these modules and initializes the EAR environment.

2. OC4J reads the module deployment descriptors of each modules. The J2EE descriptors & OC4J-specific deployment descriptors are read into memory. Then JAR & WAR environments are initialized.

3. If you do not provide OC4J -specific deployment descriptor, OC4J provides one with certain defaults.

4. Then OC4J writes out the new module deployment descriptors to the application-deployments directory. These are the descriptors that Oc4J uses for starting and restarting the applications.

5. The OC4J then copies the EAR file to the "master" directory. This defaults to "applications" directory.

6. Finally, OC4J updates the server.xml with the notation that this application has been deployed. Each existing application contains a line with an
'<'application name=... path=... auto-start="true" '/>' entry.

7. In default-web-site.xml, a '<'web-app...'>' entry exists for each Web application that is bound to the Web site upon OC4J startup.
For each Web application binding included in a WAR file, the following line has been added:
'<'web-app application="myapp" name="myapp-web" root="/myapp" '/>'

What is hot deployment?

The term "hot deployment" refers to the redeployment of archive files (WAR/EAR/JAR) and their associated XML descriptor files on a production environment without restarting or bouncing the server.

Some other important points to be noted in production environments are mentioned below

Deploying a new web module to an active OC4J instance has a negative impact on existing sessions. The HTTP sessions for every web application running within the server will be lost.

To avoid this issue on a non-clustered OC4J, define a "persistent directory" in each of web application's orion-web.xml . Existing HTTP sessions will be temporarily stored in this location.

How to define a persistent directory in orion-web.xml?

Specify a relative path to the persistent directory in the root orion-web-app element tag in orion-web.xml.

for eg.

How to handle post deployment modifications of J2EE applications in an OC4J?

The deployment, undeployment & redeployment of J2EE applications to OC4J can be easily done using Oracle Enterprise Manager 10g.

Impact of Undeploying/Redeploying an Application

During a redeployment, OC4J removes the existing application before redeploying the new EAR/WAR.

1. The application is removed from the OC4J runtime and is no longer accessible to clients
2. All application files are removed from applications/ & application-deployments/ directory
3. In an Oracle AS environment, Oracle HTTP server will be restarted to remove the mount point defined for the application. This will result in the loss of existing HTTP Sessions.

OC4J Communication

For HTTP applications, OC4J is pre-configured to execute behind Oracle HTTP Server (OHS). In other words, OHS acts as a front-end listener & OC4J acts as a back-end application server.

How does the HTTP communication to OC4J happens?

1. A browser accesses the OHS listener for all HTTP requests.

2. OHS through mod_oc4j passes the request to the OC4J server. The connection between OHS and OC4J uses Apache Jserv Protocol (AJP) on a port number assigned during OC4J startup. AJP is faster than HTTP through the use of binary formats and efficient processing of message headers.

What is the use of an OC4J in an Enterprise Environment?

Oc4J is a lightweight container which is installed as part of Oracle Application Server. The goal of OC4J is to manage J2EE enterprise systems.

Oc4J processes are configured & managed by Oracle Enterprise Manager 10g. So this means that you cannot locally manage your OC4J processes using admin.jar or by hand-editing the configuration files.

For those who want to use a standalone OC4J in a development environment, can download oc4j_extended.zip from OTN and manage the OC4J processes using oc4j.jar & admin.jar command-line tool.

In a typical production environment, all OC4J instances are controlled & managed by either Oracle Enterprise Manager 10g or command-line tools typically used for starting, stopping, restarting, configuring & deploying applications in an OC4J. Also, Oracle AS can manage multiple clustered OC4J processes.

What is an OC4J?

Oracle Container for Java (OC4J) is a complete Java 2 Enterprise Edition (J2EE) environment which provides containers, APIs and services that J2EE specifies. Oc4J is based on license from Ironflare Corporation which developed Orion Server.