History

NetKernel was started in Hewlett-Packard Labs around 1999. It was conceived by Dr. Russ Perry, Dr. Royston Sellman and Dr. Peter Rodgers as a general purpose XML operating environment that could address the needs of the explosion of interest in XML dialects for intra-industry XML messaging.

NetKernel was originaly called Dexter which stands for Declarative XML Transfrom Engine. It's emphasis on a declarative approach to manipulating XML has remained strong throughout.

In early 2002 HP rethought it's software strategy. We can't discuss the details but Peter Rodgers, the leader of HP Lab's XML research program, negotiated with HP to acquire the rights to the project and established 1060 Research with co-founder Tony Butterfield, a member of the HP Labs team.

1060 Research has refined and fully implemented the original concepts. These are now realised in the NetKernel architecture which has gone well beyond the original ideas, and now provides a general model for reconfigurable software development in addition to a comprehensive modular XML processing environment.

The version history shows the progress to NetKernel. Think of the early versions as mental scaffolding. You can't build a system with the power, elegance and architectural integrity of NetKernel without scaffolding.

Version History

Version 1 [HP Dexter]

• Abstraction of data sources as XML documents e.g. XML files, Relational Databases, System Introspection.
• XMLBean encapsulation of XML documents providing XPath-like editing interface (instead of using DOM), read-write locking inerface, and interface to support document caching.
• Definition of XML based workflow document for composition and chaining of XML operations like XSL-T. Execution of the workflow produces an XML document called the response document.
• Workflow lanaguage supports asynchronous requests for XML documents. Workflows can request execution of other worflows which are themselves just other XML resources.
• Form handling and XMLBeans to hold state information provided to support typical shopping cart applications/demos. Creating applications found to be more complex than hoped.
• Architecture of execution engine for a workflow is based on a Container model, and is multithreaded. XML manipulation languages e.g. XSL-T and XML-Query are abstracted as Processing Nodes. A round-robin scheduler provides each Processing Node with time to perform operations pending on its input queue. Internal caching of XML documents restricted to XML source documents.
• Workflow compiled into a fixed internal class structure. Complicated extensions to the workflow instruction set.
• No support for different transports so the container is deployed inside a servlet which provides mapping of HTTP requests to a workflow execution request.

Version 2 [HP Dexter]

• Introduced support for multiple transports and a transport manager to handle transport plugins.
• Refactored the container's internal queueing and threading model. The number of threads was given by 3 + N, where N was the number of threads allocated for XML document requests.
• Improved Caching and memory management (controlled by deployment metadata) rather than the LRU-based algorithm used in verions 1. Caching of transformed and source XML documents.
• The Universal Resource Accessor (URA) abstraction above transports and processors was developed. This removed the distinction between how an XML document was obtained either from a protocol request or as the result of an XML operation. It also introduced the need for an ActiveURI. This abstraction replaced the original XML Processing Nodes from version 1.
• Improved XMLBean abstraction for editing and read/write locking of XML documents. In conjuntion with (4), XMLBeans were then generalisable to encompass the processor-nodes from Architecture-1. Write locking for tranactions was still problematic. XMLBeans also enabled to reference other XMLBeans, but lead to some complications with caching.
• Allowed the workflow language to be pluggable, rather than fixed. Developer required to write an intepreter for whatever language they chose. Enabled workflow documents to be treated as XMLBeans like any other resource. Improvement from version 1, but the container architecture still influenced by a workflow execution flow pattern.
• A new workfow language was created named the idoc language. The idoc interpreter was called the RunnerBean.

An HP Technical Report on Dexter is published by HP Labs here

Version 3 [1060 NetKernel]

• More comprehensive XML technology support.
• Developed new XML technologies, STM (Simple Tree Manipulation)
• XPath XML API rewritten
• Universal resource Accessor module rearchitected. Cleaner abstraction, provide helper classes
• Performance enhanced for SMP and scalability.
• New workflow language specified called declarative processing markup language (DPML) which superceeds idoc language to provide semantics for exception handling, and xpointers and additional operator and operand types. The DPML interpreter replaces RunnerBean and provides support for conditional execution e.g. while, if, and choose and exception handling
• Realised true URI addressing model / Flat URI address space.
• Transport independence. Pluggable transport infrastructure.

Version 4 [1060 NetKernel]

• Comprehensive rewrite from ground-up, removed version 2 legacy.
• Rearchitected around true microkernel.
• Developed Representation/Aspect/Transrepresentation (RAT) Object Model
• Developed full dependency-tree caching architecture.
• XML Runtime moved out of kernel into Accessor
• Created independent extensible protected URI address space module architecture.
• URA concept refined - improved API with thread safety interlocks
• Optimized threading model.
• Extended from XML only processing to any resource type including streamed such as SAX, MPEG.
• Reduced memory footprint. Increased performance.