In NetKernel the functional building blocks, the units of deployment, are called modules. Modules can hold any or all of the extensible components: static resources, java classes, accessors, aspects, transreptors, transports, fragmentors and caches. Let's first examine the types of resources that a module may contain:

Universal Resource Accessors

Universal Resource Accessors provide a mechanism by which a resource request access the actual resource. This could for example be a request for a file or network hosted resource, it could be a request to process one or more resources into another resource, it could generate a resource from encapsulated private data sources. Accessor development is discussed in detail here. Here we will simply state that all accessors are located within modules. NetKernel being based on a Java VM accessors are typically, though not exclusively, created from Java classes.

Transports

A transport can be characterized as an external-to-internal request translator. An external request could be for example an HTTP request, a JMS message, an email, a SOAP message or even a GUI event. A transport's role is to take an external request, interpret it and issue a kernel request for a resource. The resource could be the result of an application execution, for example this documentation is generatated dynamically, or it could simply correspond with a static resource held in a module. A detailed guide to developing transports is available here.

We will see below that typically an application may only require one transport. Therefore a module will generally not need to host a transport - of course this is entirely down to the application.

Resources

We've intimated already that a module can contain pretty much any type of resource: Java classes, images, static XML, PDF documents ... anything you like. We'll show below how general resources are exported so that other modules or transports can access them.

Transreptors

A transreptor changes the interface on a representation of a resource. The best way to describe transreptors is by example. Suppose a request is made to the NetKernel for an XML DOM version of a file-based xml resource. The NetKernel will issue the request to the File URA, however the File URA is general purpose and can only return a binary stream. NetKernel is aware that the request was made for a DOM version and so it looks in the Module Manager to see if a BinaryStream to DOM transreptor is registered. The NetKernel finds just such a transreptor, the binary stream is parsed to DOM and the result is returned to the requestor. A detailed guide to developing transreptors is available here.

Transreptors can be created for mapping from almost anything to anything. Typical exmamples are the DOM parser and serializers in the ext_xml module. It would be straightforward to provide a Java image to PNG binary transreptor. One important rule to stick to though, is that transreptors do not fundamentally process or transform a resource's content, they simply make the same abstract entity available in another form. Therefore generative transformations or processing should always occur in accessors.

Fragmentors

A fragmentor provides a transformation on a resource defined by a fragment identifier on a URI. A fragmentor in many ways operates like a transforming accessor; the key differences are in the way that they are invoked and their flexibility. A fragmentor can operate on only a single resource and it should use the fragment identifier as a kind of operator to determine what transformation to apply.

Cachelets

Each module can host a single cachelet. A cachelet is a cache component that is responsible for providing caching of any module resource. Cachelets are resolved hierarchically and a single module can provide a cachelet for a whole set of modules. Alternatively every module can provide it's own module specific cachelet. In general a single cachelet for any given application is sufficient, this is usually hosted in the module which is providing a transport. A detailed discussion of the NetKernel dependency-based caching architecture is provided here.

Java code libraries

An important location (not shown in the diagram) is the /lib directory of a module. Jar libraries placed in the /lib directory will automatically be picked up by the Java ClassLoader for the module. A module is fully encapsulated and has it's own classloader therefore any java libraries required by classes in the module must be provided here.