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.
--
Jeremy
