The JWarp architecture is mainly built around the idea of application contexts and services. Since we have at our customers sometimes the requirement to run several different web applications within one JAVA virtual machine, we needed a separate running environment for each application. This notion in JWarp is modelled through the Context class. Within a context there is an arbitrary number of services running. A service is some kind of a JWarp module handling a certain number of application tasks. Each service can be started, stopped, suspended and resumed. Starting or stopping a context also starts/stops all services contained in this context (Be aware that it is the service's responsibility to organize whatever threading is accurate. A JWarp service does not run as a thread on its own). Most services implement a kind of a factory-like interface providing an interface for instantiating and referencing (and also deleting) complex objects such as objectpools, threadpools, users, groups, security objects, access rights, persistence objects, web services and dynamic caches. It is even possible to wrap an EJB server (e.g. jBoss) or some CORBA services. Many features of a JWarp service strongly resemble the JAVA Connector API's released these days. However, the JWarp implementation and usage is far easier to deal with.
There are two services which have special responsibilities:
The security service implements the interface
org.jwarp.service.security.ISecurityService, which
manages an org.jwarp.service.security.ISecurity
environment. The ISecurity environment manages users, groups, system
objects and the corresponding access rights. What security
implementation you finally use, is your decision. You just have to
implement the org.jwarp.service.security.ISecurity
interface. As a sample a file-based security class implementation is
available (using simple serialization mechanisms). An implementation
based on relational database technology or an LDAP interface is
planned.
The reference module is a context module that works similar to the JNDI API (in fact it can be built upon JNDI). It is used for fast access to all important application resources through one object instance directly available through the context.getResolver method. By default all services that inherit from the AService class are automatically registered within this reference service.
Access to services (and the resolver) needs a
reference to the running context as well as a user ticket. If you log
in to a running JWarp system, you must provide the name of the
context to which you want to connect to. The context's security
service will then authorize your login request and return a valid
user ticket (or throw a SecurityException if access was denied). The
returned ticket then contains a reference to the context, so you can
access the application components and the context resolver. Each
access to the context methods depends on a valid ticket. The object
that finally creates the contexts will also be returned a system
ticket as the result of the context creation operation, which by
default allows free access to all system resources. Services
themselves can also use the security mechanism by implementing the
ISecurityAware interface.
The whole configuration of a JWarp application is defined in an XML file. A DTD is not released yet, but a sample configuration file is provided with an extensive set of explanations about what you can already configure. Basically there are some parts defining what kind of objects are effectively loaded and inserted into the application. Each application module has the possibility to read additional configuration information, since all subtags within a module's configuration can be accessed through the org.jdom.common.IConfigurable interface implemented by most components. Even the org.jwarp.service.IContext implementation can be switched that way.
After all components are loaded and configured, the context (and thus its services) is started and ready for access.
For a sample configuration choose one of the following:
JWarp contains a pluggable logging mechanism. Unfortunately it is not yet compatible to the Apache group's jLog package. But we are planning to integrate the Apache jLog package to the JWarp framework soon.