NetKernel News Volume 4 Issue 12 - Dynamic NKP Fulcrum, Space Runtime Example

NetKernel News Volume 4 Issue 12

April 19th 2013

Catch up on last week's news here, or see full volume index.

Repository Updates

The following updates are available in the NKEE and NKSE repositories

  • http-server-2.21.1
    • Optimisation to eliminate redundant dependencies generated during system boot.
  • lang-dpml-1.21.1
    • added support for <varargs/> tag in DPML requests
  • layer0-1.97.1
    • fix to declarative requests to allow passing of null representations
  • module-standard-1.57.1
    • fix to prevent excessive memory use by dynamic spaces
  • nkse-control-panel-1.28.1
    • NKSE style now provides the jquery-UI css
  • nkse-docs-1.21.1
    • Fixes to javadoc generation to prevent NPE if module has no Java classes
  • nkse-search-1.19.1
    • Indexing requests now use "Forget-Dependencies" to eliminate redundant memory footprint.
  • pds-core-1.10.1
    • Fix to In-Memory PDS implementation to prevent NPE on DELETE request if resource does not exist.

The following update is available in the NKEE repository

  • cache-ee-1.6.1.nkp.jar
    • fix to stop rare race condition that could cause concurrent modification exception

Update Notes

The updates this week are focused on minimising initial boot memory footprint. Notably a tweak to the HTTPBridge ensures that transient bootstrap dependencies are released early. In a similar vein dependencies generated during a full system index are also ignored. The changes mean booting NK on very small systems will have minimal heap requirements.

FYI, we'll tweak the NKEE/NKSE downloads so that this minimal boot footprint is available out of the box. This will make automated installation to small devices possible. We'll make a follow-up announcement when these new jar builds are available.

Space Runtime Example

Last time, after a deliberately long winded attempt to set a smoke screen to distract the uninitiated, we announced the release of the Space Runtime.

The space runtime is extremely simple, extremely powerful and if you don't watch out, extremely hard to get your head around.

Its simplicity is that it "evaluates space resources" - it is a "space runtime". The resource which provides a declarative description of a space is SOURCEd and the space is instantiated.

That's the simple part.

The difficult part is that a Space is the entity within the ROC abstraction which manages the lifecycle and resolution of endpoints. That is, it is the mechanism by which the dynamic logical resource oriented world is embodied.

So by freeing the instantiation of the Space from the physical module we're stepping into the clouds. With the Space Runtime, the dynamic logical resource world of a space is now logically associated with the dynamic resource that declares it. We have left the physical world.

To paraphrase John Lennon: loose coupling's got nothing on this baby.

A Dynamic NKP Fulcrum

OK, with a big warning sign flashing: "Beware, this is the second order differential calculus of ROC". Let's work through a real example...


  • Let's create a Fulcrum address space using an NKP Transport.
  • We will make the NKP Transport appear and disappear from the fulcrum based on the state of a switch.
  • We will enable a configurable set of spaces to be imported and exposed to the NKP transport.
  • Unlike with the Dynamic Import pattern, the imported spaces will require no configuration state - they will be automagically imported and exposed to requests from the transport.


Here's a solution to this specification. To follow along you might want to download and install it. When you install it just expand the zip file and add a reference to it as an expanded directory in modules.xml, that way you can play with the configuration as we go...

Discussion / Demo

If you look at the module.xml you'll see that there is <rootspace> that is providing an initial framework. It consists of an <endpoint> that instantiates the DynamicSpaceAccessor using a <prototype> reference. The DynamicSpaceAccesor (the space runtime) will therefore request the resource active:dynamicFulcrumConfig as the declaration for the space it is to instantiate.

The <rootspace> also imports mod:architecture and xml:core to provide the infrastructure for the DynamicSpaceAccessor.

Finally it imports urn:com:1060research:demo:dynamic:nkp:fulcrum:impl which is a space that is providing an implementation of active:dynamicFulcrumConfig. Here's what the framework <rootspace> looks like (this is the first order space!).

<rootspace name="NKP Fulcrum Demo - Dynamic Fulcrum">

If you bring up the space explorer and view the static structure diagram for the space "urn:com:1060research:demo:dynamic:nkp:fulcrum" you'll see a diagram like this...

The front rootspace is as we've described. Looking along the lower channel you'll see the "fulcrum:impl" rootspace that is providing active:dynamicFulcrumConfig using a mapper. If you look at the second "fulcrum:impl" <rootspace> in the module.xml you'll see this mapping...

    <argument name="operator">res:/resources/configToSpace.xsl</argument>
    <argument name="operand">res:/resources/dynamicFulcrumConfig.xml</argument>

So requests for active:dynamicFulcrumConfig will actually be mapped to an XSLT transform applied to res:/resources/dynamicFulcrumConfig.xml.

If you look in the resources/ directory of the module you'll find there is a file dynamicFulcrumConfig.xml (which is resolved via <fileset> endpoint), you'll also see the XSLT transform configToSpace.xsl.

If you open the file dynamicFulcrumConfig.xml, it looks like this...

  <!-- <import>urn:org:netkernel:xml:core</import> <import>urn:org:netkernel:lang:groovy</import> -->

So now, if you go to the request trace tool in the developer tools tab you can make a request for active:dynamicFulcrumConfig into the space urn:com:1060research:demo:dynamic:nkp:fulcrum:impl. You'll see the result of the XSLT transform looks like this...

<space name="THE Dynamic NKP Fulcrum Space">
  <!--Infrastructural Imports-->

So now we see that the active:dynamicFulcrumConfig is a standard module space declaration - the dynamic space that will be instantiated by the Space Runtime (this is the second order address space).

Going back to the static structure diagram, lets switch our attention to the top channel - the one routed through the DynamicSpaceAccessor. We can see that the DynamicSpaceAccessor has "magically" created a space which looks like this...

Which is exactly as we'd expect based upon the current state of active:dynamicFulcrumConfig which we saw a second ago with our trace request for active:dynamicFulcrumConfig.

We saw that it declared an NKP transport and the imports that are needed for the NKP transport to be instantiated.

So we have an NKP fulcrum with a live transport in it. But at the moment there is nothing there for a request coming in on NKP to resolve to.

Now go in and edit dynamicFulcrumConfig.xml. Uncomment the two commented <import> lines (note this is just a list of spaces to be imported - notice that it's not the usual form for a standard module <import>). If you take a look at the space explorer static structure diagram you'll now see this...

We suddenly got some imported spaces to make NKP requests to.

OK now try commenting out the <nkp>true</nkp> line. If you look at the logs you'll see that the NKP transport gets shut down. If you look at the space explorer you'll see this...

The NKP Transport wasn't just shutdown, it was completely removed. It doesn't exist at all now.

Now try commenting out the <import> list again. Now you have this...

An empty address space.


So now you can experiment with the XSLT transform and the syntax of the config. You might want to set the port number, the security and other configuration properties for the NKP transport. You might want to import other infrastructure if certain imports are specified. You might want to optionally throttle the imports?

It took five minutes to create this framework.

In another five minutes we'll have a Control Panel admin tool that provides a list of all the spaces in the system with a selection checkbox to have any of them be imported to the new NKP fulcrum. We'll have another "master" checkbox to enable and disable the NKP transport.

Next time I'll talk you through the full implementation and discuss some of the finer details of using the Space Runtime. Hopefully, in the meantime, this gives you sufficient breadcrumbs to customize and start your own experiments.

Have a great weekend.


Please feel free to comment on the NetKernel Forum

Follow on Twitter:

@pjr1060 for day-to-day NK/ROC updates
@netkernel for announcements
@tab1060 for the hard-core stuff

To subscribe for news and alerts

Join the NetKernel Portal to get news, announcements and extra features.

NetKernel will ROC your world

Download now
NetKernel, ROC, Resource Oriented Computing are registered trademarks of 1060 Research

© 2008-2011, 1060 Research Limited