Resource Models

Resources are the first class entities in NetKernel applications. Given their importance, it can be valuable to think in terms of categories of resources or resource models just as one thinks about classes and objects in object-oriented systems.

Before we examine NetKernel resource models, let's take a look at an historically significant resource model - the Unix pipeline processing model. With the stdin, stdout, and sterr "streams", one can chain various tools together with the Unix pipe command ("|"), for example:

>cat file.txt | grep LISTEN | more

will send the context of the file "file.txt" to the grep tool where it will search for the string "LISTEN". Lines that include a match will then be sent to the more tool for paginating the display. This program can be saved in a script and executed on request.

The reason this works and the tools can share information is that they use a common resource model - a binary stream containing text with lines terminated with a CR , LF pair. Based on this standard model, a wealth of tools emerged in the Unix community. Many operational programs are simply scripted collections of such chained tool invocations.

Binary Stream Resource Model

NetKernel also supports serialized binary streams as the lowest common denominator for resource representations. Therefore, NetKernel could be used to create the same category of scripted applications as is found on Unix. However, NetKernel can go further and is much more flexible. Because NetKernel runs on top of the Java virtual machine, the full capabilities of the Java object model are available to create various resource models.

XML Resource Model

One resource model that enjoys strong tool support in NetKernel is XML. Just as binary streams are passed between tools in Unix, NetKernel supports the scripting of programs that pass XML documents between various tools. XML is a lingua franca for information exchange between systems. XML is also valuable within a system because of its flexibility. XML message structures can be interpreted by common tools and modified to support multiple generations of a system. XML has proven value when used for internal communication since its inherent extensibility ensures system robustness and flexibility. This comes about since XML message structures can be augmented to include new information without disturbing existing clients.

XML Flexibility

To see how XML can create flexibility within a software system, let us look at an example. Imagine a simple contact manager application and within that system information about a person is available in an XML form:

Clients using this information would use the following XPath expression to extract the name:

select="/person/name"

Later the system is modified to also track birth dates. With this change the XML form is

Notice that the client code using XPath still works correctly. This generational decoupling would not be possible in an object-oriented system. In an object-oriented system a recompilation - at a minimum - would be required. Generally, a change to a class in an object-oriented system causes a ripple of changes to sweep across the system.

XML Support

NetKernel supports a rich toolset for XML processing: XQuery, XSLT, STM, XRL, and more. Because of the extensive support, it can appear that XML is somehow special on NetKernel. This is not true. Other resource models can be created and could become just as rich and powerful. NetKernel provides the infrastructure for defining, building, and using rich resource models. And, with transreption support, conversions between these models can be handled transparently by NetKernel.

Custom Resource Models

In NetKernel it is very easy to create other general purpose or application specific resource models. For example, the PingPong application uses a custom resource model. Custom resource models become increasingly valuable as the interaction efficiently of your application and the model becomes more important than communicability across a set of applications. However, even with custom resource models, it is wise to provide a serialized form with an XML to custom model pair of transreptors.

As NetKernel adoption grows, there is an increasing opportunity for innovation and with it the potential for standardization of custom resource models, for example, for vertical industry domains (e.g. RFID Tags etc) or for other horizontal domains (e.g. ASN.1, CSV, etc). With each of these resource models we see the potential for an ecosystem of tools dedicated to processing the resource model.