Modules

NetKernel uses modules to manage code and resources. From an architectural perspective, modules are the major building block for all applications and NetKernel itself. Because they are central to the NetKernel structure, modules play a part in several facets of a NetKernel application.

Physical Containment

Constituent module parts are located in a directory or a single JAR file.

Logical Containment

All code and resources in a module are located within that module's private URI address space. Each module also provides a mechanism to export a public address space and to map that public space onto the internal URI address space. The combination of a protected private address space, an explicit definition of the public exported space, and the mapping permits a clean decoupling of specification and implementation based on both single points as well as whole address spaces.

Address Space Relationships

Modules use a public address space definition to declare to potential clients all services and resources they provide. These publicly available facilities can be used by other modules when they import that module.

When using multiple modules, it is important to understand how the resulting address spaces are aggregated by NetKernel. When a module is imported, the address space that it exports becomes a part of the internal private address space of the importing module. The order in which the private internal address space is declared and modules are imported is significant because when a request is being resolved, it will be sent to the first address that matches. If a second module is imported subsequently and its public address space overlaps the first, then requests will never be sent to the second module.

When requests are issued, NetKernel considers all address spaces to be local and requests are resolved relative to the local context. Therefore URI requests issued within a module's private address space are resolved in the local context of that module. Because imported modules have their public exported address space integrated into the private address space of the importing module, requests that exist in the module can in fact propagate beyond their immediate context.

As an architect one of the key considerations is the partitioning of your solution into appropriate address spaces and to define and compose the address space relationships.

Deployment

Modules are the unit of code and resource management. Modules of the same name but different versions may exist simultaneously in an operational system. This important capability allows NetKernel to support live updating of systems to upgrade or downgrade portions of a system.

Partioning

When designing the architecture for a system, it may make sense to group similar capabilities into a module. The similarities may be temporal (items with a similar life time), logical (items that provide similar services), ownership (all code written by a development group), architectural (all code for a particular architectural layer), or share some other characteristic.

Java Class Package

Each module has a separate Java classloader that works with NetKernel's module management system to load and unload Java classes when required by the operational system.

The module's classloader will dynamically mount all JAR libraries contained in its lib/ directory. Modules may also selectively export Java classes on their public interface. This is an enhancement of the standard Java package since it allows careful selection of the key packages you wish to export without having to pollute the class package space with, for example, utility and test classes etc.

Modules as Java class packages also acquire the inherent version and lifecycle management of NetKernel.