[Apache Geronimo Wiki] Updated: Architecture/WebContainer

[in...@apache.org]

   Date: 2004-01-27T13:35:53
   Editor: 203.45.72.167 <>
   Wiki: Apache Geronimo Wiki
   Page: Architecture/WebContainer
   URL: http://wiki.apache.org/geronimo/Architecture/WebContainer

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -2,58 +2,123 @@
 [[TableOfContents]]
 
 = Overview =
+The implementation of the Geronimo web tier will be guided by the use cases outlined below.  It is
+the intent of this project to meet these use-cases without resorting to implementation specific
+configuration.
 
-The notes on this page have been put together by gregw@mortbay.com, based on a posting to geronimo-dev, with a few notes added.
+= Use Cases =
+== Webapp Deployment ==
+A webapplication in either EAR, WAR or unpacked format is deployed by standard geronimo mechanisms into the default geronimo web container.
 
-I would like to see the container, the connectors and webapplications as all top level geronimo components (aka services).
+All filters, servlets and listeners will be able to be configured from the standard servlet 2.4 web.xml deployment descriptor.  EJBs deployed within an EAR that use link resolution should also be able to be resolved.
 
-[ NB. It looks like the initial geronimo code supports nested services - so perhaps the top level description is not valid and webcontainer component  can be the container for the webconnectors and webapplications ]
+An optional WEB-INF/geronimo-web.xml deployment will be required to configure any additional jndi resources and resource-refs.
 
-They would all have independant lifecycles - create, start, stop, destroy that can be controlled by the normal container mechanisms - with the exception that both connectors and webapps depend on having a container deployed.
+The context path will be set by the EAR application.xml, the WAR filename, the directory filename or by a geronimo configuration element.
 
-I would like to support multiple containers, so you can have isolated collections of connectors and webapps (eg for security and/or admin)
+Optional WEB-INF/"impl"-web.xml files may be used for Jetty/Tomcat/etc specific configuration, but their use will be discouraged for all but exceptional cases.
 
-The deployment would go something like as follows:
+== Connector Configuration ==
+The default and/or additional HTTP connectors for the default geronimo web container will be configured
+and managed via standard geronimo mechanisms.  The majority of common parameters, statistics and JSR77 lifecycle
+commands for HTTP connectors will be able to be managed without using implementation specific configuration or
+tools.  This will include:
 
-== A web container is deployed ==
+ * Protocol: http, https, ajp, etc.
+ * Ports: listening and security redirections)
+ * Interface: Optional host and/or IP interfaces to bind to.
+ * Threads:  Min, Max, aging, etc.
+ * Timeouts: Persist and Idle times.
 
-This should have no dependancies, but will lazily discover JNDI services etc as needed. The container configuration would include such things as a default web.xml to load for all webapps.
 
-== A web connector is deployed ==
+== Virtual hosts ==
+Virtual hosts must be able to be defined within geronimo web containers, defined by one or more
+host and/or domain names.  Virtual hosts may be configured for logging, security, statistics, etc.
 
-This will depend on a webcontainer being deployed.  The exact way one of multiple containers is selected is yet to be determined - but there will be a default method, plus an option to be specific in the configuration. The configuration of the web connector will contain many common parameters:
+A webapp may be targetted to a specific virtual host at deployment time. If a targeted virtual
+host does not exist, this may result in either a validation error or the creation of a
+dynamic virtual host with default configuration.
 
- protocol name:: http, https, ajp, etc.
- port:: to listen on
- interface:: optional interface to listen on
- max connection:: ???
- max idle persistance time:: ???
- required contexts:: names of contexts that must be registered and started with container before the connector accepts any connections
 
-But it will also need to allow configuration for connector specific parameters.  I assume this can be done by a getInitParameter style map - but maybe something more typed or verifiable can be used - I'll wait and see how the service configuraton mechanism develops.
+== Physical hosts ==
+The deployment of a web app may be targetted deploy against a specific subset of web connectors,
+so that it will be available only on specific physical interfaces, ports, protocols etc.
+Typically this will be to allow additional network security to be applied to administration
+and/or web services interfaces.
 
-I don't expect the webconnector service to actually implement the connector - as JMX is not really the right sort of bus to push HTTP requests/responses over.  Instead I see the webconnectors pushing their configuration at the webcontainer - which will create the actual connector.
 
-[NB. I fe people have expressed reservations about this- I belive this is just an implementation detail and if it become possible for a connector service to actually run the connector -then this architecture will support this]
+== Web Component Dependencies ==
+It will be possible to define dependencies between web components and web applications:
+ * A web connector may be dependent one or more web applications.  Thus until all the webapps are started, a dependent web connector will not be started. If the web application is stopped, then  the dependent web connector will also be stopped and the node will be unavailable. This will allow a geronimo node to enter/leave a web cluster based on application availability rather than connector availability.
 
-I would like to interpret the service lifecycle for a web connector so that a stopped webapp can continue handling connections, but will not accept any new connections.  Only when it is destroyed will any existing connections be terminated without due process.   This could be extended to work for sessions - ie a stopped connector would continue working for known sessions, but would reject requests without sessions (for gentle node in cluster shutdown - may not be required with mod_jk2?).
+ * A webapp may be dependent on another webapp, so that a webapp that uses the resources of another will only be started if the webapp on which it depends is started.
 
-== A web application is deployed ==
 
-It also depends on a webcontainer being deployed and will use the same mechanism as the webconnector to locate a specific container.
+== Web Services ==
+Other geronimo components may define a web service interfaces.  In order to deploy these components,
+some web infrastructure (connectors, SOAP servlet) may need to be initialized, perhaps dynamically.
+Ideally this will not be within the default web container, as this is unlikely to have desirable
+default security implications.
 
-A webapp should need no gerry specific configuration, but I would like to provide that as an option.  Specifically I would like to be able to configure overrides of webapp initParams without opening up a war and changing it's web.xml. Perhaps just a post web.xml to be applied after the webapps own?
 
-Again the webapplication service will not actually implement the webapp container - but it will call a deploy method on the webcontainer service.  Ideally it would provide a pre-parsed DOM (or whatever geronimo uses as standard in-memory xml tree) of the web.xml - to try to prevent multiple parsings of that file.   Any elements that can be handled by the webapplication service will be handled (population of JNDI context etc.)
+= Architecture =
 
-I would like to interpret the service lifecycle for a webapp so that a stopped webapp can continue handling requests, but will not accept any new requests.  Only when it is destroyed will any existing requests be terminated without due process.
+The following architectural points have are proposed to meet the above use-cases.
 
-All of the above will of course provide jsr77 mbeans where appropriate.
 
-All of the above is all implemented in gerry code.  It is not a facade to tomcat/jetty/orion/whatevers own lifecycle and jsr77 implementation. I think that this approach will allow the vaste majority of the web tier to be configured and deployed in gezza without any implementation specific configuration/file/etc. being used.
+== Components ==
+The geronimo web tier will be composed of JSR77 components that may be aggregated into
+various configurations.  These subservices will include:
+ * Web applications:  Directories, WARs, WARs within EARs, dynamically created
+ * Web connectors: HTTP, HTTPS, AJP, etc.
+ * Web request logs: NCSA format, file, DB, etc.
+ * Session Managers: In memory, persistent, clustered.
+ * Realms: JACC, Single sign on.
+ * Web container: A collection of other web components.
+ * Virtual host: A partitioning of a web container
+These components may be implemented as components only for the purposes of Geronimo
+configuration and management. The actual implementation may actually be decomposed
+differently (or not at all), but such details will be hidden from the average
+geronimo user.
 
-For example, the webconnectors components - being only configuration and lifecycle will be usable with any webcontainer implementation. They could even contain initParams (or whatever) for multiple webcontainer implementations.
 
-I'll then be providing a Jetty implementation of the AbstractWebContainer - but I hope that nobody will be able to tell what I have used (except by it's reliable and scalable operation :-)   Nobody will see any love-then-or-hate-them jetty configuration files (unless it is adopted for all of the big G-man :-)
+== Web Container ==
+A web container is the deployment target of a webapplication.  All webapplications that are
+deployed in the same web container will share the following services and configuration:
+
+ * Collection of web connectors.
+ * default web.xml that is applied to all web applications.
+ * optional web request log.
+ * realm
+ * session manager
+ * collection of virtual hosts
+A Geronimo server may have multiple web containers deployed. A single web container may
+be configured as the default web container for the server.
+
+All web components may optionally name (by ObjectName) the web container they are for. If
+a web component does not name a web container, then it is for the default container.
+
+Only ServletContexts deployed within the same web container are visible to the
+ServletContext.getContext() API.
+
+
+== Virtual Host ==
+A web container may be partitioned into virtual hosts, each which may be configured with:
+
+ * A primary host name. This is the name used to identify the virtual host within the container.
+ * optional collection of alias host and/or domain names.
+ * optional web request log
+ * optional realm
+ * optional session manager
+
+Web applications and  web components that may be associated with a virtual host may optionally name a
+virtual host (by primary virtual host name) in their configuration. If no virtual host is named, then
+the component is deployed at the web container level.
+
+
+== Configuration ==
+Web applications will use a geronimo-web.xml file for their geronimo specific configuration. They
+may also have impl-web.xml for implementation dependent configuration, but this is to be discouraged
+in all but exceptional cases.
+The other web components will be configured via the GBean mechanism which may use *-service.xml files.
 
-I also think that eventually other sub-components of the web tier should also be able to be made top level geronimo components/services. The SessionManager could probably do with similar treatment - so that session persistance, replication, statistics etc. etc. can be done as a reusable geronimo component rather than as tomcat/jetty etc. specific in implementation, configuration and behaviour.