1060 Research released NetKernel 3.1 last week. NetKernel is a resource-oriented software development and execution environment. It allows the integration of functions and services written in a variety of languages (including Java, JavaScript, Python, Ruby, XSL and others) through the use of URIs. New features in NetKernel 3.1 include Ruby support, JSON as a native resource type, and updated documentation.
InfoQ sat down with Randy Kahle of 1060 Research to discuss the new release. He describes the principle notion of NetKernel as all elements of the system are identified by a URI address, including resources, code, services, etc. Kahle describes the benefits of this architecture:
Requests for resources / services are processed by NetKernel's microkernel which resolves the address and schedules execution of the request on a thread from a tightly managed thread pool. Because each URI fully identifies a resource, the result of any computational work expended to create the resource's representation can be cached with the URI as the key. This means that mindless recalculations can be eliminated from an operational system and the system can self-tune as the character of work changes over time (hour, day, week, etc.)
He goes on to say that resources are at a higher architectural level than Java objects. Resource representations can be created by any of the languages supported by NetKernel. Kahle describes how all of these resources are organized within NetKernel:
Modules contain a private URI address space in which resource and services exist. Modules may expose a portion of their internal address space and be imported by other modules. Each module contains an independent Java class loader so modules can be viewed as containers of Java objects and libraries. NetKernel is carefully crafted to support hot installs, updates and configuration rollbacks of modules. By using module version numbers, NetKernel can even run multiple versions of modules simultaneously, keeping all library code, JAR files, etc. distinct.
Kahle described the driving motivation for Java development in NetKernel being the orchestration of an application at the resource level, so resource specific code is hidden behind the URIs. Among the other benefits listed by Kahle are:
- Each request is resolved at runtime by the microkernel. This allows AOP type constructs as a natural part of the application structure.
- Modules are fully independent of each other with their own classloader. Versioning of Java libraries is easy and natural.
- Intrinsic caching reduces mindless computations. We find that the caching more than offsets the cost of the indirection.
- The carefully managed set of work threads are allocated efficiently across cores and CPUs. Applications can be built in NetKernel that scale with cores and CPUs.
- Small size. NetKernel can run real applications in 12 Meg of heap and easily run enterprise applications in 64 Meg of heap.
Kahle went on to describe some of the different ways that NetKernel can be used within an architecture. While NetKernel is a general purpose environment, he said it has an emphasis on XML processing due to the research it grew out of at HP. Therefore current uses of the system are mainly in system integration, XML message processing, and pipelined applications. Other examples of current use include:
- Meta-level processing of information stored in various databases for information mining
- Workflow systems that supports easy adaptation of workflow rules and processing
- High performance server for Ajax clients
The conversation shifted to the future of NetKernel and Kahle mentioned some of the goals for the next release that were discussed last month at their Architect Conference, including reduction in size, speed improvements, and support of Java ME.
Kahle then discussed the REST model inside of NetKernel and how it differentiates NetKernel from other systems:
The REST architectural approach is handled naturally by NetKernel. One principle notion of REST - that state is provided with each request by the client - results in stateless systems that scale very well with additional cores. While NetKernel _is_ inherently a resource-oriented system (the RE part of REST or Representation), it does not require the ST part - the state transfer. For example, state capture and management can be layered on top of internal services. While NetKernel may be unique in supporting a REST approach at a fine-grained level, I don't think that is its core uniqueness. NetKernel is unique because it was designed according to a well-grounded philosophy about how software systems should be crafted. It uses a small set of key concepts and abstractions and does not compromise them. Because we had the time to fully explore the implications and implementation issues related to these concepts, the result is a strong, pure model not short-circuited by pressure to bring a product to market. This adherence to the core philosophy led to REST and other characteristics.
At the end the conversation moved to discussing the impact of the REST model on applications running on NetKernel. Kahle said that this model does not impose any constraints. Resources do not impose any type and implementation code is loosely bound behind the URI.