NetKernel Scripting Framework

The NetKernel Scripting Framework (NSF) enables, manages and optimizes the execution of scripting languages in NetKernel. Currently Javascript, Python and Beanshell (aka scripted Java) languages are provided. This guide provides a detailed discussion of the NSF and highlights important features relating to the supported languages.

Architecture

The NSF is a runtime accessor (org.ten60.netkernel.script.accessor.ScriptEngineNKFAccessor) which manages and executes scripts. The ScriptEngine services requests for active:beanshell, active:javascript, active:groovy and active:python and expects to receive an operator active URI argument with the script to be executed.

When a newly requested script execution is received the ScriptEngine sources the script and, using the underlying script implementation, generates a compiled and cacheable representation. The compiled script is then executed. Any subsequent request for the script will automatically retrieve the cached pre-compiled script which will execute without the overhead of parsing and/or interpreting. Using Netkernels dependency-based caching scripts are automatically recompiled if changed.

The ScriptEngine runs on the NetKernel Foundation API every script execution is provided with the INKFConvenienceHelper, which in the script is called the context object. The context object is used to obtain resources from the intiating request, to schedule new requests with the kernel and finally to issue a response.

At a higher-level it is easiest to think of a script execution in the Script Engine as simply equivalent to an accessor - that is, a script executing in the NSF is an NKF accessor.

To understand what is provided to a script by the context object read the NetKernel Foundation API guide.

Script Sources

The ScriptEngine will accept scripts either as text files or as an XML document with a <script> root element.

Classpath and Imports

A script will inherit the classpath of the host module from which it is invoked. This includes the classpaths exported by any modules which are imported into the host module. In addition the kernel and layer1 classpaths are always accessible.

Whilst the modular classpath is available to the script, it is still necessary to explicitly provide language dependent import statements in your script when you wish to script a certain object type - the following table shows how the org.ten60.netkernel.layer1.representation.ByteArrayAspect class would be imported to a script in each specific language.

Language	Import Statement
Beanshell	import org.ten60.netkernel.layer1.representation.ByteArrayAspect;
Javascript	importPackage(Packages.org.ten60.netkernel.layer1.representation.ByteArrayAspect);
Groovy	import org.ten60.netkernel.layer1.representation.ByteArrayAspect;
Python	sys.add_package("org.ten60.netkernel.layer1.representation") from org.ten60.netkernel.layer1.representation import ByteArrayAspect

Thread Safety

The ScriptEngine is marked as thread safe and scripts may be safely executed concurrently. However, for example in Beanshell, if you create local threads in your scripts you are responsible for their management and local thread safety considerations.

Reference

We are using the following versions of language runtimes - links are to the language reference documentation.

• Beanshell v1.3.0
• Rhino Javascript v1.5 R5
• Groovy v1.0 beta6
• Jython v2.1

Performance Tips

• With Beanshell it is important to wrap your script in a main() method (see trailmap for examples). The main method is necessary for the ScriptEngine to perform pre-compilation and then execute the script. Without main() performance is reduced approximately 5x.)

Known Limitations

The Jython resource loader is not aware of the NetKernel resource resolution infrastructure - this means that Jython modules can only be imported from the real filesystem paths specified by the python.path property. (For more details on Jython paths see here)

In future we would like to enhance the Jython package manager to use NetKernel as a resource resolver.