1060 NetKernel Standard Edition, XML Application Server

Introduction

This document describes the general capabilities of 1060 NetKernel Standard Edition XML Application Server. For an interactive tour of it's capabilities take the XML technology tour.

XML Infrastructure

Experience indicates that XML processing requires detailed knowledge of complex and frequently inconsistent API's (cf DOM, SAX, JDOM, JAXP, XSLT, XQuery, XML Signature, XPath etc etc etc) many of which assume an implicit XML infrastructure (for example resource resolvers) which it is left to the developer to provide.

Since XML is declarative and code is procedural there is a natural mismatch which can mean that procedural code for XML processing is difficult to maintain and is often fragile. This innate fragility makes working with XML a challenge and often limits the manipulation of XML to simple object binding and XSLT transforms. In a rapidly expanding XML world where almost every system component can generate XML this is a severe limitation on the adaptability of an information system.

NetKernel's XML application server was designed to abstract the low-level XML infrastructure necessary to create XML applications allowing developers to concentrate on manipulating the XML document tree using standard XML technologies which can be easily combined. This enables the rapid development of robust and maintainable XML processes which manipulate diverse XML sources.

NetKernel's XML application server provides extensible high-level languages (DPML, XRL) for scheduling XML processes on URI referenced resources. The NetKernel component model is fully extensible with a clean API to incorporate new software components into the XML processing framework. The Application server intrinsically provides comprehensive guarantees of thread-safety and exception handling enabling highly robust, fault tolerant systems to be developed.

XML System

The NetKernel XML Application server takes care of almost all of the low-level XML infrastructure and in so doing provides a highly optimised system for processing XML.

Just-in-time Processing

NetKernel's underlying architecture means that all XML Application Server processes are evaluated Just-in-time. All processes are series of internal URI requests - compiled URI requests are only evaluated when a resource must physically exist in order for a processing decision to be made. What this means in practice, for example, is that an XML resource is only parsed when it is needed, in many cases the InputStream reference for an XML resource is all that exists in memory.

Furthermore the underlying object technology for providing an XML resource is transparent - a component may require SAX, DOM etc. The choice of representation is dictated by the invoked component and is only made Just-in-time therefore the system is highly efficient and very flexible .

The JIT architecture means that an XML developer does not need to think about parsing or serializing (unless of course they really want fine grained control, which is available). In addition the issue of what underlying object models a given technology requires are taken care of - the developer is assured that an optimal form is always used.

Caching

All XML resources, including intermediate processing results, are cacheable. NetKernel maintains a dependency tree for all cached resources. If a dependant resource is changed the cached resource is invalidated and rebuilt on-demand Just-in-time. This dependency model is extremely efficient and means that web-applications can be written that generate a complex resource from multiple sources but which, once built, run as fast as a static web-site.

The kernel computes the cost of generating all XML resources, the number times they are used and their age - this information is used by the cache garbage collector to manage the cache size. In fact, in all XML processes garbage collection is automatic and transparent.

The entire cache is transparent meaning the XML developer does not even need to know it's there. For embedded applications where memory footprint is more important than performance the cache-size can be reduced or removed entirely. No application code needs to be changed.

XML resource change detection is automatic and the detection period is configurable . This means that a developer can modify an XML file in their application and the change will be detected, all cached resources that depended on the modified file will be invalidated and rebuilt on-demand Just-in-time, all of this happens automatically and transparently.

XML Resource Resolver

NetKernel provides resource resolving for all standard XML technologies. This means that for example, if an XSLT transform uses an xsl:include the included resource will be discovered, parsed, cached and provided to the XSLT transform seamlessly.

The XML Application Server supports transparent use of Xpath to provide shorthand references into XML documents. XPath contexts are cached for optimum performance. The XPath implementation is fully namespace aware and automatically detects changes to namespaces and document paths to rebuild the XPath context. An optimized XPath engine is used transparently where an XPath does not specify complex operations which is typically 80% of the time.

All XML resources can be requested with Xpointers. Xpointer provides a powerful combination of URI and XPath. Any XML resource may be requested with an Xpointer qualifier. In addition a resource may also be targeted using XPointer URI's allowing an XML fragment to be inserted into an XML document in a single step.

The XML resource technologies are available at all levels including the URA API which provides utility resource resolution, request and management for custom components.

Standard XML Technologies

A comprehensive set of standard XML technologies are available. The implementations of standard technologies are optimized to take advantage of the NetKernel infrastructure.

Validation

Validation is an important class of technology. Since data and data-model are intimately bound there is by definition no one-size fits all validation technology. We support DTD, XSD, RelaxNG, Schematron and also XPath evaluation. Historically validation has been consigned to the parse-time pre-processing stage, all NetKernel validation technologies may be used within a process, ie at runtime. All validation technologies provide XML domain error reporting, many of them provide XPath error locations which are very valuable for post-validation error handling processes.

Generic Transformation

XML document transformation is any act of modifying a document. XSLT, XQuery and STM are the primary generic transformation technologies though referencing resources using XPointer can be used as a powerful transformation pattern.

XSLT is the most common XML processing technology to date. XSLT transforms can be applied with ease and, like any of the XML technologies provided, XSLT transforms can be pipelined. Each unique XSLT transformation instance is cacheable therefore frequently used transforms need never be rebuilt from the XSL document.

XQuery is a new W3C standard scripting lanaguage for creating, querying and combining (joins etc) XML documents. Whilst XSLT requires a developer to be fully immersed in the XML transform, XQuery will be more familiar to those with SQL knowledge and is powerful addition to the standard XML technology set. Like XSLT, XQuery queries are compiled and cached so frequently used queries do not need to be rebuilt from the source document.

STM is a simple but powerful document transform language which we have developed. It allows tree operations to be performed on a document using XPath contexts. It is a natural and often higher-performance complement to XSLT and XQuery for XML processes.

XML Processing Languages

Declarative Processing Markup Language (DPML) is the first XML processing language provided with NetKernel. It is a new XML process declaration language and runtime which makes writing powerful XML processes straightforward. It features a complete XML exception handling framework.

XML Resource Linker (XRL) is a XML pull runtime for recursively combining XML components. It enables XML documents to be structured into functional components - it's most frequent use is as componentized XHTML portal engine, thought it is generic and can be used to combine any XML resources.

A language on NetKernel is simply a URA component with the ability to sequence other URA requests. It is therefore straightforward to implement other languages.

Process Integrity

The NetKernel Application Server provides many low-level technologies for ensuring XML processes are robust.

Exceptions

Exceptions can be classified in two categories runtime and process-level exceptions. A resource request which produces an exception is returned to the requestor. The exception will percolate up the request chain until it is handled. Any process may choose to catch and handle an exception and continue with a post-exception process. A process may deliberatly throw a process-level exception enabling robust exception-based process patterns to be created.

Exceptions are XML resources. It is therefore common to catch an exception and use the exception as an XML resource in an exception handling XML process.

XML Transactions

NetKernel provides full support for resource locking. XML resources can be safely written to from within concurrent application processes. Full exception support allows applications to guarantee rollback and goes a long way to providing distributed transactionality.

Concurrency

XML technologies are plentiful but not often guaranteed to be thread-safe for concurrent access. All XML technologies provided with the NetKernel are made safe for concurrent access. NetKernel provides a thread-safety interlock mechanism that guarantees that if a URA component is not declared thread-safe it will never be scheduled for concurrent access.

Request Throttle

NetKernel provides a powerful configurable request throttle which ensures that external transport initiated requests can never overload the system.

Deadlock Detector

Sometimes legitimate processes can create Deadlock. NetKernel never lets a deadlocked process hang the system. It monitors all processes and if it detects deadlock it will kill a rogue process and issue an exception to the parent of the process.