Virtual Filesystem Guide

Introduction

The 1060 NetKernel Filesystem is implemented by URAs and so is very flexible and modular and can be replaced or customized easily. The default filesytem accessors are provided by the layer1 module and offer a flexible solution to support dynamic module resource discovery and an override mechanism to enable module state.

The layer1 accessors support file:, http:, ftp:, jar:, data: and ffcpl: URI schemes. file:, http: and ftp: should be familiar as the standard IETF URI schemes. jar: allows access to Java jar resources and is similar to file. data: is an IETF standard scheme for encoding a resources in a URI (see below). ffcpl: is a convenient new scheme for allowing access to a module's resources and provides the ability to override a resource with a resource sink request.

New filesystems and URI address schemes can be added on an application basis. For example it is possible to produce an RDBMS or XML database backed filesystem.

Modules

Application resources, transports and libraries are all uniformly managed in Modules. The 1060 NetKernel supports dynamic installation of modules. Modules may contain XML resources, XML applications, Transports, Transreptors, URAs or any other resource/file type.

Module's are usually located in the <install>/modules/ directory. Module's may be either JAR archives or normal expanded files and directores. Expanded directories can be convenient during development and can be zipped up for distribution or deployment. The module development guide shows how to create and install a new module.

The NetKernel system.xml config file sets the poll interval at which the ModuleManager will detect changes in expanded module resources - typically during development this interval should be short so that changes to a module's resources are picked up immediately. A deployment system will want to make this value large as changes are not likely to be made and resource change detection is an overhead to the Kernel.

Modules encapsulate a private URI address spaces behind a public URI interface. They may be linked together to form applications. A request for a module resource is resolved by the Module Manager which will attempt to discover the resource for a given URI by traversing a virtual URI address space provided by the current set of linked modules within which the request was made. A guide to modules and applications is available here

FFCPL

The ffpcl: URI scheme is a scheme for accessing module resources. FFCPL stands for File First ClassPath Later - though this is not really relevant to it's use. It provides a convenient resource access model which allows a resource held in a module to be overridden.

FFCPL is a two-layered filesystem. A first layer is the scratch filesystem, a real directory located below <install>/scratch/. The second layer is the module filesystem, which is based on the Java Classloader mechanism. ffcpl: first tries to find a resource in scratch and falls back to the module java classloader if it doesn't discover it.

The figure below shows a request, sink and re-request using the ffcpl: scheme - for this illustration we will assume the resource is in the same module as the request was issued and will not discuss the Module Manager's resource resolution process.

1. SOURCE: A request is made for a resource using URI ffcpl:/resource.xml. The resource is sought in the scratch directory, it is not found so the module is checked. The resource is found in the module and returned.
2. SINK: Another request is made to write a new resource to URI ffcpl:/resource.xml. The new resource value is written to the scratch filesytem. By default scratch is a real directory located at <install>/scratch/. The resource is therefore written to the file <install>/scratch/resource.xml. Module resources are never directly overwritten they are only overridden.
3. SOURCE: Another request is made for ffcpl:/resource.xml. The resource is found in scratch and returned.

FFCPL is very useful as it allows default module resources to be overridden by local copies and so allows modules to hold state.

FFCPL is generally the scheme by which the public interface of a module is defined. Therefore ffcpl: can also be used as a REST-like service interface for a process which generates resources.

file:

Resources in the filesystem of the operating system can be accessed using the standard file: URI scheme.

The file scheme will be familiar to anyone who has used a web-browser to view local resources. As you will also be aware there are operating system specific issues with using file:

The unix system is very similar to a general URI. Windows requires a drive letter and backslashes - though forward slashes will work just fine.

data:

The data: URI scheme was proposed as a way of declaring a resource inline within a URI and was conceived as a client-side technology for web-browsers. It was never adopted by browser manufacturers but it turns out that it can be very valuable as a server-side technology. data: URI's are fully supported by NetKernel and can be used as the URI in any request, including in active: URIs.

Net Accessor

The Net accessor is similar to file: only it allows networked resources to be accessed. Net accessor supports http: and ftp: schemes. Any web-based resource can be accessed by using a URL such as http://someserver/some/path/to/resource.xml

For firewalled systems an proxy can be configured here.