News

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

NetKernel 3.3 Released Including Enhanced Dynamic Language Support

Posted by R.J Lorimer on Dec 19, 2007

Sections: Enterprise Architecture,; Development
Topics: Java ,; Languages ,; Programming ,; Enterprise Architecture ,; NetKernel

After eight months, 1060 Research, Ltd. has released the newest version of their NetKernel product, version 3.3. Enhancements and new features in this release include:

Request Visualizer - Provides a visual representation of the chain of resource requests occurring in an active NetKernel application, improving developer and administrator debugging.
Reorganized/Re-written Documentation - To make the concepts of resource-oriented computing easier for adopters, all documentation was re-arranged and reorganized, including book content, the getting started guide, and more.
Optimized HTTP Transport Layer - Support has been added for 'if-modified-since', 'eTags' and 'HTTP 304', allowing for HTTP clients to better manage cached data from NetKernel.
Image Resource Model - Full support for treating image data as a NetKernel resource has been added, allowing for advanced manipulation of image data via pipelines.
Enhanced Dynamic Language Support - The Ruby support has been upgraded to JRuby 1.0.1, and experimental PHP support has been added, allowing for more language alternatives for implementing NetKernel resources.

InfoQ spent some time speaking with Randy Kahle from the NetKernel team about their latest release of the NetKernel product. InfoQ asked Kahle what he felt was the most significant enhancement in the 3.3 release of NetKernel.

The focus of the release was making it easier to learn NetKernel and resource oriented computing. The concepts themselves are simple but they are very different from current approaches to software development. We reorganized the documentation, rewrote most of the chapters and added integrated demos to illustrate key points in the Getting Started Guide. We added the Request Visualizer tool, a "Time Machine Debugger", which visually presents logical resource requests and their mapping to physical code. In addition, we have our normal refresh of libraries and performance enhancements.

Kahle was then asked what he considered the biggest challenges with promoting resource oriented computing to developers that are unfamiliar with the concept.

The biggest challenge is leading developers away from APIs. NetKernel's logical model is focused on information processing and is cleanly separated from the physical level of objects and APIs by a microkernel. We initially explained ROC and NetKernel by starting at the logical level and working our way down to the physical level - but experienced developers found it hard to change their focus away from objects and even hear the explanation of a logical model. Now we start at the familiar physical level and explain how an Accessor is a simple object container with a server side similar to a Servlet. Once developers see this we show that an Accessor can issue sub-requests up into the logical level allowing them to create composite software systems. Soon they understand that an accessor is symmetrical, acting as both a server and a client. Once we reach this point we can head upwards to discuss the whole new world of patterns enabled in the logical level.

Another challenge has been explaining why we explored REST and how we discovered ROC. We did not set out to build new technology. We were focused on understanding the economics of the World Wide Web. The Web is the most successful information system ever devised primarily because of its economic properties, not the implementation details of a given subsystem. We found that the large scale economics of the web can be applied to the small scale of software itself. NetKernel applications are much less expensive to build, deploy and maintain. Applications can be ported from Java J2EE very quickly and they run faster and scale with CPU cores.

Lastly, InfoQ asked how NetKernel can help with the development of applications for the massively-multi-core computers of the future.

NetKernel scales. We have separated the logical level of information from the physical level of objects and APIs - making a request for a logical resource is completely separate from the physical threads and CPU resources required to compute the response. Just as a logical web site scales with the addition of servers in a server farm, NetKernel applications scale with the addition of CPUs and cores. The NetKernel 3 series was designed for today and tomorrow's multicore processors. We recently completed work on the 4th generation of NetKernel's core architecture anticipating future 512 core and larger systems.