I was at Oracle Open World in London this week and I had several questions about Application Server architecture. Seems as though there a lot of people who are unclear about how all the different layers interact. The following is a brief (simplified) summary to give people a feel of how the different layers work together for the J2EE components. Lets start at the top and work down.
An Application Server Farm is a management entity to allow multiple application servers to be administered from a single location. A farm may have one or more Application Server Instance. The management screen for the farm will give access to the managment screens for all individual application server instances. A farm is defined by a meta-data repository. Each farm has exactly one meta-data repository.
An Application Server Instance is best thought of as an Oracle Home. Tthe Oracle Home contains the software and configuration needed to run all the components of the Application Server. There are several flavours of an Application Server Instance.
There is always exactly one infrastructure instance per farm. There may be zero or more instances of other application server install types in a farm. The one component that runs on all Application Server instances is the Oracle Process Manager & Notification process (OPMN). This is responsible for starting and stopping all individual processes in the instance. It also monitors processes and restarts them if they stop responding.
The Application Server Instance is what you actually install from CD. All Application Server Instances apart from J2EE & Web Cache must be part of a farm. J2EE & Web Cache instances can operate without a farm.
This is a component of all Application Server instances. It does not have to run but is always installed. The Oracle HTTP server is based on Apache 1.3.xx. As such on Windows it runs as worker process and a watchdog whilst on Unix/Linux systems it runs as multiple processes. There is exactly one OHS configured per Application Server instance.
A key component of OHS, this provides connectivity between the web server and the J2EE processes. Each J2EE process that starts will be registered with OHS by OPMN. This allows OHS to balance traffic across multiple J2EE processes.with OHS
This is a component of all Application Server instances. It is best thought of as the configuration for a J2EE server. J2EE applications are deployed to a specific OC4J instance within an Application Server Instance. Resources such as database connection pools and JMS connections are also configured at the OC4J instance level.
There may be multiple OC4J instances within an Application Server instance. For example developers Fred and Mary could each have their own OC4J instances within a single Application Server instance.
An OC4J instance is just a set of configuration files. To be able to run a J2EE application it is necessary to execute a J2EE server on a JVM. Each OC4J instance may have one or more JVMs. Each JVM or operating system process within a given application server instance provides the same set of applications and resources as any other JVM within the same instance.
Each JVM will automatically take advantage of multiple processors on the machine. For example on a dual processor machine each JVM will use both processors.
Normally only a single JVM per OC4J instance is required. However if the applications in the JVM seem to have a high degree of synchronisation or there are large number of processors on the machine then it may be desirable to run multiple JVMs to improve throughput. Multiple JVMs may also be run to make application fail over more efficient, but that is a subject for another blog.
There is exactly one LDAP instance per Infrastrucuture Application Server Instance. It is used to hold some configuration information as well as holding the information for the Identity Management components of the Oracle Application Server.
OK, lets have a couple of examples to make it easier.
A single JVM is executing within an OC4J instance called Fred. It is running applications mapped to /appA and /appB.
A further two JVMs are executing within an OC4J instance called Mary. They are running applications mapped to /appC and /appD.
In addition a single OHS instance is running. URLs starting with /appA or /appB are routed to the JVM in the Fred OC4J instance. URLs starting with /appC or /appD are load balanced across the two JVMs in the Mary instance.
The OHS instance knows about the three JVMs because it was notified by OPMN (which has a single instance running) that there are 3 executing JVMs on this machine.
All the above processes are running from a single ORACLE_HOME (single installation).
All configuration is stored locally as there is no meta-data repository, the Application Server instance not being part of a farm.
This may be summarised as
Grey boxes are actual OS processes. Red boxes represent configuration.
This is the same as the previous example except that this time the configuation data is refreshed from the meta-data repository of the farm. In this configuration there is also at least one other ORACLE_HOME involved, the one that contains the infrastructure hosting the meta-data repository.
This may be summarised as
The discussion above is a simplified treatment. We haven't discussed other components such as Web Cache, Portal, Forms, Reports, Identity Management, Integration ... all of which form part of the Oracle Application Server 10g product and are delivered as a single install from the product disk. We also haven't discussed clustering and hish availability which add a few wrinkles to the description above. Maybe we can return to these another time.