Home Index Changes Prefs Log in »
Page Difference

Difference between version and version     

Back to GlassFishV2Architecture, or GlassFishV2Architecture Info


At line 1 changed 18 lines.
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type">
<title>GlassFish Architecture</title>
</head>
<body>
<div style="text-align: center;"><span style="font-weight: bold;">Cluster
support in GlassFish V2<br>
</span>
<div style="text-align: left;"><span style="font-weight: bold;"><span
style="font-weight: bold;"></span></span><br>
<font face="Times New Roman, serif"><font size="3">This document
describes the high-level concepts and architecture for Clustering
support in GlassFish V2<br>
<br>
An
installation of GlassFish consists of one or more <i>administration
!!! Cluster Support in GlassFish V2
<font
face="Times New Roman, serif"><font size="3">This document describes the high-level concepts and architecture for Clustering
support in GlassFish V2</font>
<font
face="Times New Roman, serif"><font size="3">An installation of GlassFish consists of one or more <i>administration
At line 24 changed 1 line.
of applications and configuration information. </span></font></font><font
of applications and configuration information. </span></font><font
At line 30 changed 5 lines.
MBeans. </font></font>
<p style="widows: 2; orphans: 2;" lang="en-US"></p>
<p style="widows: 2; orphans: 2;" lang="en-US"><font
face="Times New Roman, serif"><font size="3">Here
are some important terms and concepts:</font></font></p>
MBeans.
!! Overall Architecture
The architecture diagram below, showing a sample GlassFish
installation (a single domain), will be used to illustrate the basic
concepts.
<p>
[{Image src='cluster-arch.jpg' align='base'}]
</p>
The architecture consists of the following components:
At line 34 added 144 lines.
<p class="western" style=""><font size="3"><b>Domain Administration
Server (DAS). </b><span style="">The DAS, a fully functional Java EE 5
server instance, facilitates <span lang="en-US">administration </span>for
the Domain. All administrative operations (e.g. initiated via the CLI,
GUI, NetBeans IDE, and other tools) are routed to the DAS rather than
to server instances directly. For aggregate operations that encompass
more than one server instance, the DAS will be responsible for
broadcasting administration requests to instances. DAS is able to
administer instances running on remote hosts. When the DAS is not
running administative operations are not possible. No special efforts
are made to make the DAS highly available except for simple watchdog
and restart capability. Instances and clusters in the domain can
function normally even if the DAS is not running. </span></font> </p>
</li>
<li>
<p class="western" style=""><font size="3"><b>Administrative Client
Applications (CLI, JSR 77, AMX)</b>. Administrative clients include the
asadmin CLI (command line interface) utility, and modules that plug
into the Studio. These applications reside either inside or outside the
firewall and communicate exclusively with the Domain Admin Server (and
not server instances directly). All application deployment makes use of
the JSR 88 APIs. Configuration and application deployment are done
exclusively via<span lang="en-US"> JMX MBeans </span>(some of which
are standardized by JSR 77). These clients clients use JSR160 JMX
connectors to access the DAS. To cross firewalls, the protocol of
choice implemented in the connector is HTTP(S).&nbsp; There is also an
MBEan interface called AMX that exposes all the functionality through
API.<br>
</font></p>
</li>
<li>
<p class="western"><font size="3"><b>Browser Based Administrative
GUI. </b><span style="">The browser based administrative GUI
(graphical user interface) application is deployed in the Java EE 5
instance hosting the Domain Admin Server. This forms the administration
“console” of the application server. </span></font> </p>
</li>
<li>
<p class="western"><font size="3"><b>Web Client<span lang="en-US">
Applications </span>(web clients, web services clients). </b><span
style="">A web client communicates with the server instance using http
via a web browser or a web service invocation. In clustered
configurations all web clients are optionally routed through the load
balancing tier which performs load balancing and optionally some level
of failover (Failover functionality is under development for
GlassFish).&nbsp;</span></font></p>
</li>
<li>
<p class="western"><font size="3"><b>Rich client (RMI/IIOP)
applications. </b><span style="">A rich client runs in a process
remote from the server instances and communicates with the server
instances via a generated client stub over the RMI/IIOP protocol. The
rich client may be hosted in the server's Application Client Container
(ACC) in which case it has access to all JNDI resources defined in the
server, or it may be running as a stand alone RMI/IIOP client relying
purely on the client side ORB. Rich clients typically reside within the
firewall boundary, but the architecture should not limit this. Like web
clients, rich clients should be load balanced to lightly loaded server
instances and should be able to failover if the server instance to
which they are communicating fails.</span></font></p>
</li>
<li>
<p class="western"><font size="3"><b>Load Balancers (LB). </b><span
style="">The load balancer is responsible for directing new incoming
requests to the least loaded host machine, recognizing failed nodes,
retrying operations if necessary,<span lang="en-US"> and maintaining </span>affinity
<span lang="en-US">(stickiness)</span> with a particular host on
which a session has been<span lang="en-US"> established. </span>There
are a wide variety of load balancing solutions in addition to the
software load balancer. <br>
</span></font></p>
</li>
<li>
<p class="western"><font size="3"><b>Node Agent (NA). </b><span
style="">A lightweight agent (e.g. hosting a JMX runtime only) will be
needed on each node in the domain to facilitate remote lifecycle
management of instances. Its primary purpose will be to start, stop,
and create server instances as instructed by the DAS. The Node Agent
will also act as a watchdog and restart failed processes (e.g. in the
absence of web core). Like the DAS, the Node Agent should only be
required for certain administrative operations and should not be
expected to be highly available. However, the NA is an “always on”
component, and will be configured to be started by the native O/S node
bootstrap (e.g. Solaris/Linux inetd, or as a Windows service). A Node
Agent is not required for the DAS, and as such GlassFish installations
will not contain a Node Agent.</span></font></p>
</li>
<li>
<p class="western" style=""><font size="3"><b>Server Instance (SI).
</b>An instance is a<span lang="en-US"> Java </span>VM hosting a
Java EE 5 application server. Bi-directional communication between the
server instances and the DAS relies on remote MBean method invocations
via JSR160. The standard JSR 160 RMI connector is used for all server
to DAS communication. This means that the DAS will host two JSR160 JMX
connectors -- a proprietary HTTP connector for crossing firewalls for
use by the admin CLI and the standard RMI connector.<br>
</font></p>
</li>
<li>
<p class="western"><font size="3"><b>Administration API.</b><span
style=""> A subset of the administration JMX Mbeans in the DAS will be
exposed and made available to customers. These interfaces will
communicate with the DAS using the standard JSR 160 RMI connector.</span></font></p>
</li>
<li>
<p class="western"><font size="3"><b>Central Repository. </b><span
style="">There are 2 main repositories storing information shared by
all instances in the domain. The configuration repository contains
domain configuration information, and the application repository
contains deployed J2EE applications. The central<span lang="en-US">
repository </span>is maintained and written to only by the DAS using
an API (configuration MBeans) and persisted on the file system<span
lang="en-US">. The</span> central repository will typically be rooted
under a single directory and as such can easily be backed up and
restored.</span></font></p>
</li>
<li>
<p class="western" style=""><font size="3"><b>Local Repository
Cache. </b><span style="">To avoid forcing high availability
constraints on the DAS, and speedier startup, each instance maintains,
on its local file system, a cache of its configuration from the Central
Repository. The cache will be synchronized with the Central Repository
each time the instance restarts. The cache will be a subset of the
Central Repository (e.g. since an instance only needs the referenced
subset of applications in the domain).</span></font></p>
</li>
<li>
<p class="western"><font size="3"><b>JMX Runtime. </b><span
style="">The JMX infrastructure provides the administrative<span
lang="en-US"> infrastructure </span>used to carry out <span
lang="en-US">administration</span> and configuration operations. The
JMX runtime includes the agent services (MBean server, timer service,
monitoring service, etc.), the MBean instrumentation level, as well as
distributed <span lang="en-US">devices</span> such as connectors
(JSR160) that are used for virtually all inter-server and client
communication. All server instances, Node Agents, and the DAS itself
host JMX runtimes.&nbsp; </span></font> </p>
</li>
</ul>
!! Here are some important terms and concepts:
<ul>
<li>
At line 251 changed 151 lines.
<h2 class="western" style="margin-left: 0in;">Overall Architecture</h2>
<p class="western" style=""><font size="3">The
example below, showing a sample GlassFish
installation (a single domain), will be used to illustrate the basic
concepts.</font></p>
<font size="3">The
architecture consists of the following components:</font>
<ul>
<li>
<p class="western" style=""><font size="3"><b>Domain Administration
Server (DAS). </b><span style="">The DAS, a fully functional Java EE 5
server instance, facilitates <span lang="en-US">administration </span>for
the Domain. All administrative operations (e.g. initiated via the CLI,
GUI, NetBeans IDE, and other tools) are routed to the DAS rather than
to server instances directly. For aggregate operations that encompass
more than one server instance, the DAS will be responsible for
broadcasting administration requests to instances. DAS is able to
administer instances running on remote hosts. When the DAS is not
running administative operations are not possible. No special efforts
are made to make the DAS highly available except for simple watchdog
and restart capability. Instances and clusters in the domain can
function normally even if the DAS is not running. </span></font> </p>
</li>
<li>
<p class="western" style=""><font size="3"><b>Administrative Client
Applications (CLI, JSR 77, AMX)</b>. Administrative clients include the
asadmin CLI (command line interface) utility, and modules that plug
into the Studio. These applications reside either inside or outside the
firewall and communicate exclusively with the Domain Admin Server (and
not server instances directly). All application deployment makes use of
the JSR 88 APIs. Configuration and application deployment are done
exclusively via<span lang="en-US"> JMX MBeans </span>(some of which
are standardized by JSR 77). These clients clients use JSR160 JMX
connectors to access the DAS. To cross firewalls, the protocol of
choice implemented in the connector is HTTP(S).&nbsp; There is also an
MBEan interface called AMX that exposes all the functionality through
API.<br>
</font></p>
</li>
<li>
<p class="western"><font size="3"><b>Browser Based Administrative
GUI. </b><span style="">The browser based administrative GUI
(graphical user interface) application is deployed in the Java EE 5
instance hosting the Domain Admin Server. This forms the administration
“console” of the application server. </span></font> </p>
</li>
<li>
<p class="western"><font size="3"><b>Web Client<span lang="en-US">
Applications </span>(web clients, web services clients). </b><span
style="">A web client communicates with the server instance using http
via a web browser or a web service invocation. In clustered
configurations all web clients are optionally routed through the load
balancing tier which performs load balancing and optionally some level
of failover (Failover functionality is under development for
GlassFish).&nbsp;</span></font></p>
</li>
<li>
<p class="western"><font size="3"><b>Rich client (RMI/IIOP)
applications. </b><span style="">A rich client runs in a process
remote from the server instances and communicates with the server
instances via a generated client stub over the RMI/IIOP protocol. The
rich client may be hosted in the server's Application Client Container
(ACC) in which case it has access to all JNDI resources defined in the
server, or it may be running as a stand alone RMI/IIOP client relying
purely on the client side ORB. Rich clients typically reside within the
firewall boundary, but the architecture should not limit this. Like web
clients, rich clients should be load balanced to lightly loaded server
instances and should be able to failover if the server instance to
which they are communicating fails.</span></font></p>
</li>
<li>
<p class="western"><font size="3"><b>Load Balancers (LB). </b><span
style="">The load balancer is responsible for directing new incoming
requests to the least loaded host machine, recognizing failed nodes,
retrying operations if necessary,<span lang="en-US"> and maintaining </span>affinity
<span lang="en-US">(stickiness)</span> with a particular host on
which a session has been<span lang="en-US"> established. </span>There
are a wide variety of load balancing solutions in addition to the
software load balancer. <br>
</span></font></p>
</li>
<li>
<p class="western"><font size="3"><b>Node Agent (NA). </b><span
style="">A lightweight agent (e.g. hosting a JMX runtime only) will be
needed on each node in the domain to facilitate remote lifecycle
management of instances. Its primary purpose will be to start, stop,
and create server instances as instructed by the DAS. The Node Agent
will also act as a watchdog and restart failed processes (e.g. in the
absence of web core). Like the DAS, the Node Agent should only be
required for certain administrative operations and should not be
expected to be highly available. However, the NA is an “always on”
component, and will be configured to be started by the native O/S node
bootstrap (e.g. Solaris/Linux inetd, or as a Windows service). A Node
Agent is not required for the DAS, and as such GlassFish installations
will not contain a Node Agent.</span></font></p>
</li>
<li>
<p class="western" style=""><font size="3"><b>Server Instance (SI).
</b>An instance is a<span lang="en-US"> Java </span>VM hosting a
Java EE 5 application server. Bi-directional communication between the
server instances and the DAS relies on remote MBean method invocations
via JSR160. The standard JSR 160 RMI connector is used for all server
to DAS communication. This means that the DAS will host two JSR160 JMX
connectors -- a proprietary HTTP connector for crossing firewalls for
use by the admin CLI and the standard RMI connector.<br>
</font></p>
</li>
<li>
<p class="western"><font size="3"><b>Administration API.</b><span
style=""> A subset of the administration JMX Mbeans in the DAS will be
exposed and made available to customers. These interfaces will
communicate with the DAS using the standard JSR 160 RMI connector.</span></font></p>
</li>
<li>
<p class="western"><font size="3"><b>Central Repository. </b><span
style="">There are 2 main repositories storing information shared by
all instances in the domain. The configuration repository contains
domain configuration information, and the application repository
contains deployed J2EE applications. The central<span lang="en-US">
repository </span>is maintained and written to only by the DAS using
an API (configuration MBeans) and persisted on the file system<span
lang="en-US">. The</span> central repository will typically be rooted
under a single directory and as such can easily be backed up and
restored.</span></font></p>
</li>
<li>
<p class="western" style=""><font size="3"><b>Local Repository
Cache. </b><span style="">To avoid forcing high availability
constraints on the DAS, and speedier startup, each instance maintains,
on its local file system, a cache of its configuration from the Central
Repository. The cache will be synchronized with the Central Repository
each time the instance restarts. The cache will be a subset of the
Central Repository (e.g. since an instance only needs the referenced
subset of applications in the domain).</span></font></p>
</li>
<li>
<p class="western"><font size="3"><b>JMX Runtime. </b><span
style="">The JMX infrastructure provides the administrative<span
lang="en-US"> infrastructure </span>used to carry out <span
lang="en-US">administration</span> and configuration operations. The
JMX runtime includes the agent services (MBean server, timer service,
monitoring service, etc.), the MBean instrumentation level, as well as
distributed <span lang="en-US">devices</span> such as connectors
(JSR160) that are used for virtually all inter-server and client
communication. All server instances, Node Agents, and the DAS itself
host JMX runtimes.&nbsp; </span></font> </p>
</li>
</ul>
<br>
<h2 class="western" style="margin-left: 0in;">Configuration And
Central Repository</h2>
!! Configuration And Central Repository
At line 658 added 7 lines.
----
I thin it is better to show the architecture as a picture as such block diagram or any UML static diagrams.
--[Jagadesh|http://null], 21-Sep-2006
« Home Attachments Info Index Changes Prefs
This page (revision-9) was last changed on 12-Feb-07 11:43 AM, -0800 by ClaudioMiranda