NetKernel News Volume 4 Issue 12

April 19th 2013

• Repository Updates
• Space Runtime Example
• A Dynamic NKP Fulcrum

Repository Updates

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...

Specification

• 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.

Download

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...

• urn.com.1060research.demo.dynamic.nkp.fulcrum-20130419.zip

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!).

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...

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...

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...

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.

Follow-on

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.