Introduction

Server-side Kauri will be based on a small kernel called the Kauri Runtime. The kernel will be responsible for bootstrapping a number of 'modules'.

A module in the Kauri runtime can expose functionality in two ways. Or put in another way: a module can be accessed in two ways. These are:

  • a module can expose Java services (and depend on Java services)
  • a module can expose URL-addressable resources

This combination is somewhat unique: if we look in the Java landscape, we see on the one hand component frameworks focussed on Java services, and on the other hand Servlets which only focus on URL-addressable resources.

The Kauri Runtime will reuse ideas and code from the Daisy Runtime. For people familiar with that one, you could say that: Kauri Runtime = Daisy Runtime + ROA (addressable resources).

For those who want some more technical details:

  • a module will be able to contain Spring container definitions, and certain beans from those can be exported to make them available to other modules.
  • a module will be able to express its classpath needs
  • a module will contain a mapping definition for specifying which URLs should be handled by which code. Next to manually specifying this mapping, there will be some conveniences such as automatically serving static files from a 'public' directory, possibly also for JAX-RS, and other techniques.

A lot of the functionality offered by Kauri (e.g. templating & XML-pipelining, forms, ...) will be provided in the form of a module, which you are free to use or not use in your project.

Exit Servlet, enter Restlet

An important decision we took is not to go for the Servlet API, but instead for the Restlet API.

Reasons for choosing for Restlet include:

  • The API better supports HTTP and ReST concepts
  • Responses are returned as Representation objects. This allows for returning non-stream representations (e.g. for in-VM requests), and for better NIO support.
  • It's both a server and client API. One could see the Restlet client API as a replacement for the Cocoon SourceResolver.

Restlet also provides powerful URL-to-handler routers as part of the API, though this is a part which will solve as part of Kauri ourselves.

Modules: use cases

Modules serve multiple purposes:

  • Modularising an application into multiple parts. For simple applications this might be overkill. A split-up can be done in various ways:
    • data-oriented backend, presentation-oriented frontend
    • or a functional split up: user-management module, ...
  • Package optional system functionality. This is similar to the blocks in Cocoon (2.1): things like templating, pipelining, forms, etc. can be provided as modules.
  • To extend Kauri-based applications: cfr. Daisy Wiki extensions or xReporter report-format types.

Modules: definition versus instance

It should be possble to deploy the same module multiple times in the same Kauri Runtime. Each module can then have its own configuration. Think of datasource-module, or even two different configurations of the templating module.

As a consequence, modules will not be uniquely identifiable by their name (group ID + artifact ID + version) but will need some 'module instance name'.

This module instance name is of importance for the module-wiring, for error messages (logs), ...

Kauri Runtime scope

The Kauri Runtime only provides a low-level platform, higher-level aspects of webapp development will be supported by optional libraries and modules.

Besides the very general "modules exposing Java services and URI-addressable content", what webapp-related things will be part of the Kauri Runtime?

Here's a list of web-app development aspects and where they fit in the Kauri Runtime:

  • mapping a request to code that handles it (a "controller", "resource implementation", ...): yes, this is part of the Kauri Runtime.
  • Controller or whatever it's called: something supporting Restlet's Uniform interface. What about scripted controllers?
  • View: technology to render the view is not part of the Kauri Runtime. Restlet Representation. Some frameworks automatically find template based on controller name.
  • Redirect and internal redirect: Restlet Redirector class, see http://www.restlet.org/documentation/1.0/tutorial#part10
  • Authentication
    • we need at least ability to block part of URI space to internal-only requests
  • Exception handling: runtime as a whole, module specific, part of uri space within a module. Actual rendering of error page will need to be supported by other libraries/modules.
  • Stateful interactions: sessions, continuations, and the like. Not sure yet where this fits: probably need an interface for this and module-supported implementations.
  • Everything related to models, higher-level request handling such as forms support, ajax: completely unrelated to the Kauri Runtime
  • Caching of resource responses (things to consider: cache key, expire techniques (incl. dependencies between cached items), eviction techniques, what is cached: only binary streams or also arbitrary java objects, ...). Technically speaking this might be implemented as a Restlet filter?