Introduction

NetKernel provides a REST operating environment on top of the Java Virtual Machine. NetKernel is implemented in Java and resource object models must be written in Java. However most end-user and developer programming is done either with URIs or by high-level scripting using a wide choice of languages. Hence, Java is to NetKernel as C is to Unix - it is one of a choice of languages for developing solutions and is the language used for creating primary low-level components and resource models.

This document discusses the relationship between the higher-level world of NetKernel and the boundary to Java and they Java type system. The central object at the boundary is the Accessor.

Accessors and Java

NetKernel and the REST++ abstraction supports loose typing. However, Java is a strongly typed object-oriented language. At the boundary, bridging between the two, resides the Accessor. This section describes how the Accessor design uses various patterns to provide a bridge between these two worlds.

In the broadest sense, the Accessor may appear to be an object container and it does bear some similarity to other containers that you have used for Java development. Containers, such as the Servlet container for Servlet and JSP development, J2EE container, or even Java Swing GUI development, provide certain services and capabilities and have strictly defined APIs.

Compared to these traditional containers, the Accessor is very simple. An Accessor must simply provide a Value Object to clients in response to a resource request. A Value Object is an objected-oriented design pattern that is an immutable representation of state information. (For a general discussion about immutable objects see this article on Wikipedia)

The following diagram is a representation of the actors working at the boundary between NetKernel and Java code:

Three accessors are illustrated, the SMTP accessor (working with a Java SMTP library), the Customer accessor, and a Database accessor (working with the Java JDBC library). The diagram illustrates these accessors on the boundary between NetKernel and the Java substructure. Also on the boundary are Aspects (labeled "A", "B", "C", and "D") and their associated Value Objects. The "Rep" objects are Representation objects. In operational terms, NetKernel is very simple: client requests to the kernel are delegated to an appropriate accessor and the client receives a representation object as the response. The representation object can provide the appropriate Aspect depending on the type the client can work with.

The following sequence will clarify this mechanism as well as the role of the various objects. The first diagram illustrates a SOURCE request sent to the Database accessor resulting in the return of a JDBC ResultSet object from the JDBC library:

Next the Database accessor creates a Value Object from the information accessed through the ResultSet and builds an appropriate Aspect. Then the Database accessor creates a representation object and links it to the Aspect. The Representation object is returned to the kernel: and the kernel maintains the mapping between URI and the representation. (Not illustrated is the return of a reference to the representation object to the client)

As we mentioned, NetKernel is loosely typed and can support an unlimited number of resource models. This is illustrated in the first diagram where the top-most Representation object references two different Aspect objects. Each Aspect supports a specifically typed version of the resource information.

Concurrency and Threads

The scheduler at the heart of NetKernel manages low-level Java threads. A resource request will receive a Thread when scheduled by the scheduler. Threads are re-entrant to the kernel and will be assigned tasks so as to optimize system throughput.

NetKernel is fully asynchronous. However the APIs are written so as to present as much as possible a synchronous model for the developer - writing asynchronous code is not for the faint hearted. Using the Asynch methods on the API to explicitly issue requests asynchronously is NetKernel's equivalent of 'forking' a subprocess on Unix.

Requests made to the kernel will never block a thread - even if this is how it may appear from the API. A thread which re-enters the kernel with an apparently synchronous blocking request will be allocated tasks to work on whilst the response is pending.

Finally NetKernel will never concurrently schedule threads to a component that does not declare that it is safe for concurrent execution. This can be very valuable as a safety feature for less experienced developers.