A Resource Model is an ecosystem of interoperating tools and services organized around a particular form of information that allows you to work easily with that form of information. NetKernel provides many ready-to-use resource models and it is straightforward to create your own model to solve problems specific to you or your organization.

Before we dive into a tour of NetKernel's resource models it might be helpful to get a feel for what we mean by a resource model by looking at a very well known resource model: The Unix operating system.

Unix

Unix uses a resource model based on the File information structure. All resources in Unix are modeled as Files and the POSIX layer provides a common physical representation model (API) for File access. Above the core operating system services (such as mounting physical storage, networking, etc.) there is a broad toolset of small applications each of which accepts file inputs and generates file outputs. These simple tools can be readily composed together to solve problems. Some tools (such as gzip and md5sum) work directly on raw File streams. Others, such as ls and find, work with the resource address space.

Another set of tools reside above the binary tool level and processes files containing ASCII text. These tools, such as wc, grep, sed, etc., tend to treat a File as a set of delimited lines of text. Since these tools also produce Files they seamlessly interoperate with each other and with the lower level tools.

These tools can be orchestrated or composed together with languages. Some of them are general - such as bash. Others are domain specific - such as awk.

Together, the Unix toolset (its resource model ecosystem) provides a very powerful environment for building solutions.

NetKernel generalizes the ideas behind the Unix File resource model to provide a wide range of resource models. When it is useful to do so, NetKernel supports interoperation between resource models by using a lowest common denominator resource model - a binary stream.

Anatomy of a Resource Model

Starting with the lowest layer of the diagram, we see that a Resource Model provides a Physical Representation. Usually this is an Object Oriented datatype with an associated API. It is desirable that the physical representation API is designed to be separable into immutable (read-only) interfaces and mutable implementations, but this is not mandatory.

A resource model may have several physical representations (ROC doesn't care about the type, only the abstract resource). In this case it is useful to provide transreptors that losslessly convert one physical representation to another. It is also useful to provide transreptors that serialize and parse the representation to and from binary streams.

Above the physical representation layer a resource model provides tools that can process resources. These consist of services, including services for performing transformations. Transformations are usually concerned with outputing a resource of the same form and so are readily composed together to create solutions. However, it is perfectly acceptable for a transform service to produce a completely different form of resource.

Frequently a resource model will have languages that are specialized for processing a particular type of information. In Unix think of awk, or for XML think of XSLT or XQuery. In NetKernel it is simple to create a language runtime that accepts a program as one of its arguments which it applies to a given resource.

Some languages aim to be resource-centric and Turing complete. However, it is also very powerful to provide Domain Specific Languages which will accept a resource containing a set of processing instructions which it applies to another resource (for example, the Wiki processing service or the SOAP tools). Powerful DSLs often start as simple task specific transform tools and evolve and grow over time, as usage and feature requirements dictate.

You will see that these general features we have described are all present in the Unix file resource model we discussed earlier.

In addition to processing tools, a resource model frequently provides other resources. For example it might provide a domain specific set of assertion services for the XUnit testing system. It will almost certainly provide documentation, both for services, transforms and languages as well as guides and tutorials. Documentation is simple to add and will become searchable when integrated into the NetKernel documentation system.

Physical Partitioning

While it is possible to create a resource model in a single NetKernel module, it is frequently better to partition a model into separate modules. This will allow different parts to be developed by different teams, to evolve at different rates and be tested and deployed with any appropriate granularity.