Application hierarchy in OC4J

This blog provides an overview of the application hierarchy within an OC4J instance.This will be helpful in understanding how the j2ee applications, bpel processes are able to access all the features like adapters which comes with the default application

The system Application – invisible parent

The system application is a new internal component in Oracle Containers for J2EE 10g (10.1.3.1.0). It is auto-deployed to the OC4J instance the first time OC4J is started.

This application was added primarily to address issues related to deploying or redeploying applications to OC4J. It sits at the root of the application hierarchy, and provides classes and configuration required at OC4J startup. For example, it provides the shared libraries imported by default by all other deployed applications, such as the Oracle JDBC driver and XML parser implementations.

The system application is an OC4J internal component only. Applications cannot be deployed to it, nor can it be declared the parent of another application. The default application continues to serve as the default parent of all deployed applications.

The configuration for the system application is defined in system-application.xml, which is installed in ORACLE_HOME/j2ee/instance/config by default.

Because system is a key internal component that is critical to OC4J startup, the system-application.xml file should not be modified except for the and tags.

The default Application –visible parent inheriting system Application

The default application sits just below system in the application hierarchy. Every application deployed into OC4J must have a designated parent application. The default parent is the global application packaged with OC4J, which is named default.

Designating an application as a parent enables classes and services to be shared among the child applications. A child application sees the namespace of its parent application, and inherits the set of shared libraries imported by the parent. Configuration data is also imported from the parent, although it can be overridden at the child application level

Standalone Web modules (WAR files) may also be deployed to the default application.

The configuration for the default application is defined in application.xml, which is installed in ORACLE_HOME/j2ee/instance/config by default.

J2EE Applications- inherits from default Application

By default, an application deployed to an OC4J instance inherits configuration parameters from its designated parent application or from the default application if no other parent is specified. However, a parameter value set in an application's orion-application.xml descriptor overrides an equivalent parameter inherited from the parent.

Courtesy:: Oracle® Containers for J2EE Configuration and Administration Guide

What happens during Deployment

When you deploy an application packaged within an EAR, the following occurs:

1. If the application is being redeployed, the existing installation is first undeployed from OC4J.
2. OC4J copies the EAR file to the master deployment directory, which defaults to the ORACLE_HOME/j2ee/home/applications/ directory.
3. OC4J opens and parses the application.xml file packaged within the EAR file. This file is a standard J2EE descriptor that lists all of the modules contained within the EAR file. OC4J notes these modules and initializes the EAR environment.
4. OC4J reads the module deployment descriptors for each module type - Web module (WAR), EJB module, connector module, or client module - into memory. The JAR and WAR file environments are also initialized.
5. OC4J reacts to the configuration details contained in both the J2EE deployment descriptors and any OC4J-specific deployment descriptors. OC4J notes any J2EE component configurations that require action by OC4J, such as wrapping EJBs with their interfaces.
6. OC4J writes out new OC4J-specific configuration files to the ORACLE_HOME/j2ee/home/application-deployments/app_name directory, according to the contents of the deployment plan. Note that if one or more OC4J-specific deployment descriptors were supplied, you may notice that OC4J added additional elements to the generated files.
7. Any generated classes, such as EJB interface wrapper classes, are compiled and put into new subdirectories of this directory. For example, EJB wrapper classes are generated within an archive named deployment-cache.jar within the ORACLE_HOME/j2ee/home/application-deployments/app_name/jar_name.jar/ directory, where jar_name.jar corresponds to the name of a deployed EJB JAR.
8. Finally, OC4J updates the OC4J server.xml configuration file with the notation that this application has been deployed.

Courtesy:Oracle Containers for J2EE Deployment Guide

What is Apache JServe Protocol (AJP)

While I was researching on SOA server administration I learned about a new protocol being used inside the server for its internal communication named Apache JServe Protocol . I would like to share some info on this protocol.

The Apache JServe Protocol (AJP) is a binary protocol that can conduit inbound requests from a web server through to an application server that sits behind the web server. It also supports some monitoring in terms of the web server being able to ping the application server. AJP is typically used in a load balanced deployment where one or more front-end web servers feed requests into one or more application servers.

The AJP 1.3 protocol is packet-oriented. A binary format was presumably chosen over the more readable plain text for reasons of performance. The web server communicates with the servlet container over TCP connections. To cut down on the expensive process of socket creation, the web server will attempt to maintain persistent TCP connections to the servlet container, and to reuse a connection for multiple request/response cycles.

Once a connection is assigned to a particular request, it will not be used for any others until the request-handling cycle has terminated. In other words, requests are not multiplexed over connections. This makes for much simpler code at either end of the connection, although it does cause more connections to be open at once.

Once the web server has opened a connection to the servlet container, the connection can be in one of the following states:

• Idle
  No request is being handled over this connection.
• Assigned
  The connection is handling a specific request.

Once a connection is assigned to handle a particular request, the basic request information (e.g. HTTP headers, etc) is sent over the connection in a highly condensed form (e.g. common strings are encoded as integers). If there is a body to the request (content-length > 0), that is sent in a separate packet immediately after.

Courtesy (Wikipedia & Apache-Dan Milstein)

AIA terminology

While I was researching on AIA I came across a nice presentation from Morten Karlsen Oracle Consulting .I hope these terminologies will help you all in getting a basic idea of components used to implement AIA

• Enterprise Business Service (EBS)‏

These are application-agnostic web services that are used by calling applications to interface with different applications. This helps the cross-application processes to be participating-application unaware. The EBM containing the canonical object is the payload of the enterprise service and contains business-specific messages.

• Enterprise Business Object (EBO)‏

A standard business data object definition used in the canonical data model. Enterprise business objects contain components that satisfy the requirements of business objects from participating application data models.

• Enterprise Business Message (EBM)‏

The EBM is the payload that is paired to an EBS. The response returned by the EBS will also be an EBM.

• Enterprise Business Flow (EBF)‏

A cross-functional BPEL flow is used to coordinate the flow of a single EBS operation that is complex, potentially long-lived, and spans multiple services. These flows only interact with EBSs to keep them agnostic of participating applications.

• Application Business Connector Service (ABC Service)‏

The name for APIs developed to transform application business objects into enterprise business objects, and vice versa. Components of this service include the ABC implementation service and the ABC interface service.

bulk delete of BPEL Processes using BPEL Console

Refer Marc Kelderman SOA Blog
http://orasoa.blogspot.com/2007/01/how-to-install-and-use-bpelconsole.html

Tips for AIA FP installation

1. In the installation folder you will find a file @ AIAFPackSetup\Disk1\install\oraparam.ini

As of now the installation is supposed to work till windows XP.(version 5.2). Vista being 6.0 will not allow AIA FP to be installed

The line will be like this

[Certified Versions]

#You can customize error message shown for failure, provide value for CERTIFIED_VERSION_FAILURE_MESSAGE

Windows=4.0, 5.0, 5.1, 5.2

So you need to edit and add 6.0 to the windows versions.

Windows=4.0, 5.0, 5.1, 5.2, 6.0

The same issue is there with other oracle SOA suite installation also.

2. AIA installation will extract all the installation files to the AIA home that we specify during installation. The executable file will be using ant scripts to complete the installation. So if your installation is failing at any point refer to AIA_HOME\logs\install.txt . If you are comfortable with using ant you can manually modify the ant scripts to complete the installation.

3. OSR and AIA installation will be deploying registry.ear and AIAApplication.ear respectively into Oracle application server. So easiest way to crosscheck whether your installation succeeded is to check whether these ears are deployed in the Application server.