Rick asked me on IRC what I meant about different approaches to web container integration, especially when it came to exposing entry points as web services. I'd said I'd post it to the list.
There are two ways we can run as part of a web application: 1) Using pure J2EE APIs and running as a portable web application 2) Running as SCA module within an SCA aware web container == Portable Web Application == In this mode we want to run as a self-contained application in a stock web container - all we can rely on are the J2EE APIs and that we have been granted sufficient privileges to run. In this mode all classes need to be bundled with or made available to the web application - all JAR files will be included in WEB-INF/lib or WEB-INF/classes, made available as references to JARs in a containing EAR file, or added to the application classpath using some container-specific mechanism. Application isolation will make it difficult/impossible for different web applications to share information so each web application will be a standlone unit, either a subsystem with all module components present in the application or a single module component. The runtime can be booted on application startup from ServletContextListener. This listener will boot the runtime, load the system definition, and load the application modules. It can bind the system or module definitions as attributes in the ServletContext. Each request needs to be associated with the module context for the invoked servlet (in the subsystem case different servlets could map to different module components). This can be done by a Filter that binds the appropriate ModuleContext to the Thread for use by CurrentModuleContext.getContext(). Each web-service entry point must be bound so a web-service endpoint, which if we are using the Axis transport, done by configuring the Axis servlet. The configuration of the Axis engine can be built during the bootstrap above and passed to the servlet as a ServletContext attribute. Finally, session expiration needs to be detected and a notification sent to the runtime. This can be done using a HttpSessionListener and may be combinable with the ServletContextListener above. All of this must be configured by the user in their web.xml file - a little configuration here being the price for portability across container. Specifically, the following entries must be added: * A <listener> configured to boot the runtime * A <filter> configured for the request filter * A <filter-mapping> for each path associated with a module * A <servlet> for the axis servlet * A <servlet-mapping> for the axis servlet * A <listener> for session expiration (if not combined) In this configuration, RuntimeContext is a non-priviledged API (it runs with the permissions of application) but although it is exposed for use by these infrastructure artifacts there is still no need for the application to use it. We can't stop application code from doing so but this is not harmful as everything is running with application-level permissions. == SCA Aware Container == To avoid the need for users to explicitly configure their web applications to enable SCA, we may be able to integrate the runtime directly with the web container. In this mode, the runtime would run as a privileged extension to the container and would automatically configure the SCA environment for a deployed web application. We have started to do this with Apache Tomcat. All classes for the runtime would be placed in the appropriate location for the container (e.g. Tomcat's server/lib) and would not be exposed to the application. The only access the application would have would be via the standard SCA APIs. The runtime would bootstrap with the container, before any applications were deployed. How this is configured is container-specific - with the current Tomcat integration we have a specialized implementation of Host that is activated by specifying the appropriate class name in server.xml When an application is deployed, the container extension detects this, inspects the application to see if it requires SCA and if so configures the container as necessary. The user only place the sca.module file in the application for this to happen - there are no SCA-specific entires in web.xml The container will need to configure the same sort of entry-points as described above but may do so in container-specific ways. For example, the Tomcat integration adds a Valve to the processing pipeline instead of a Filter as a Valve has access to internals that a Filter does not (for example, it is able to attach notes to the request). For web-services, the extension code needs to examine the SCA module and make sure all the entry-points are bound. One way it could do this is to configure a single Axis servlet with a engine configuration that maps each request to the appropriate entry-point; another is to define a separate servlet (or internal equivalent e.g. in Tomcat's case a custom Wrapper) for each entry-point that is attached directly to the entry point's context in the runtime. In this type of configuration, the RuntimeContext is a privileged API which should not be (and does not need to be) exposed to the application. == Where we are == Up until now we have had a hybrid solution where all implementation classes run with container priviledge but are fully exposed to and shared by every application. This has some serious issues. Supporting the first mode (portable web app) requires documentation for the application assembler and the implementation of a couple of listeners that are very close to the current implementations. These are not Tomcat specific (by definition) and can be placed either in core or in a new webapp module. We have the bones of a Tomcat container extension that covers SCA modules but which does not support the auto-configuration of web-services. This should be quick to implement as part of the Axis2 work. It also does not support sessions yet (see TUSCANY-51). -- Jeremy
