ESSENTIAL KAURI THEORY

Kauri consists of a platform, called the Kauri Runtime, on which Kauri-based applications run. A Kauri application consists of one or more modules. A typical Kauri application will consist of at least one module, and will likely re-use a number of standard modules. Examples of standard modules supplied by Kauri are the templating module, the request-routing module and the forms module.

A module is typically packaged as a jar file (a zip file with extension .jar) but can also be loaded from a directory.

A module is started by instantiating its Spring bean container. Each module can have its own classpath configuration, describing what its classpath needs are, and can also push classpath entries onto the parent classloader common to all modules.

Modules don't live on their own, but they talk to each other, in two ways:

  • by making use of each other's Java-services.
  • by making use of each other's REST-services. REST-services are HTTP-like services (i.e. URI-identified resources supporting GET/PUT/POST/DELETE operations), but then without requiring the HTTP layer. REST-services can be called upon internally, and can optionally be mounted on a public path to be accessible over HTTP (or other protocols).

A module provides or exports a service and another module depends on or imports that service. Making the connection between the two is called wiring.

For basic Kauri usage, all you need to know is that you can make use of services offered by standard Kauri modules, and that your own code will also be packaged as a module. For more details about everything Runtime-related, see the Runtime documentation.

intro schema
Click to enlarge