NetKernel News Volume 1 Issue 44

September 3rd 2010

What's new this week?

• Repository Updates
• XMLDB / eXist module
• WiNK Update - Discussion of a resolution bug
• Independent Article: RoC Skool with NetKernel
• What's in a name?

Catch up on last week's news here

Repository Updates

The following updates are available in both the NKEE and NKSE repositories...

• lang-groovy 1.6.1
  • Updated the groovy-all-x.x.x.jar library from 1.7.1 to the latest stable 1.7.4 release. Incorporates many bugfixes by the Groovy project
• wink 1.13.1
  • Made the common library space private to prevent masking of other applications in the front-end fulcrum (see discussion below)

New: XMLDB / eXist Module

mod-xmldb is now available in the multiverse (early access) sections of the the NKSE and NKEE repositories. It provides the following services...

• active:xmldbQuery provides both XPath and XQuery access to an XML collection
• active:xmldbUpdate provides support for xml-update requests to an XML collection
• xmldb: URI scheme provides SOURCE/SINK/EXISTS/DELETE support on a collection referenced by URI.

mod-xmldb has been tested with eXist but uses the XMLDB API and should be able to connect to any XML content repository the provides XMLDB drivers (similar to the JDBC abstraction).

WiNK Update - Discussion of a resolution bug

I thought I'd share a little detail on the reason for the update to WiNK in the repositories.

Kevin Ansberry kindly alerted us to a problem trying to run one of the demos in the ROC Basics tutorial. He used the visualizer to capture a trace of the exception he was seeing from which it was clear that the demo was failing to be able to transrept a String to a BinaryStream.

The layer1 module provides most of these low level primitive type conversion transreptors and they are pre-configured to be imported into the front-end fulcrum space. It was therefore odd that we'd not seen this failure before.

Looking at the visualizer trace, it was apparent that the String-to-BinaryStream transreptor was being resolved into the WiNK application space. So WiNK was being sloppy and was inadvertently exporting the layer1 endpoints. The logical set of layer1 endpoints exported from WiNK were then masking the local import of layer1 in the fulcrum.

Ordinarily this would not have mattered much, since a transreptor is a transreptor, even if its not being resolved via the same route as you expected. However in this case there was a complication in that WiNK's endpoints were transparently overlayed by the security and session layers of the application. Therefore the resolved transreption request ended up terminating with a complex failure due to not being logged into WiNK!

Using the Space Explorer tool provided a detailed view of which endpoints WiNK was "leaking". The solution was very simple, just to add a <private/> tag to the import of WiNK's common library space in the WiNK application space. This made the library tools resolvable within the WiNK application but ensured that they couldn't be seen from any external application interfaces.

The circumstances are fairly unique and, as I said, ordinarily it really doesn't matter which way you route your resolution. But I thought I'd explain this in depth just in case you ever come across anything similar. And I suppose its a good lesson to use the Space Explorer to double check your assumptions about what you really want to expose from a public application interface.

Visualizer Showcase

Incidentally, this reminds me that its high time I delivered on my promise to give a hands-on showcase of the visualizer. Its a very powerful time-machine debugger tool and it captures absolutely everything that is going on. There are a few simple techniques to using the tool which make pinpointing exceptions very efficient.

Its more than just a debugging tool though. It can be used to perform very detailed analysis of performance, concurrency and architectural structure. And, as I showed the other week, it even lets you get a sense of the internal patterns of a complex algorithm.

Send me a note if you're interested and I'll arrange a web-meeting event.

Independent Article: RoC Skool with NetKernel

It's great to learn that another independent voice has been writing about ROC and NK.

Matt Pearce of Quest Software has written an article for The Monitor on NetKernel and ROC:

RoC Skool with NetKernel. Applying RESTful patterns inside software design

Here's a short quote...

ROC is a potentially disruptive technology that helps producers of
event-driven, high-volume, and data-rich applications
lower development and code maintenance costs.

Matt has included some independent comments from Scott Rehorn, an architect at Quest...

Those two platforms [Azure and Google AppEngine] are both old-fashioned by comparison to the way NetKernel does things

Shucks. Thank you Matt and Scott - very much appreciated.

What's in a name?

You'll no doubt be familiar with the famous quotation "A rose by any other name would smell as sweet". From which you would be forgiven for believing that Shakespeare is describing the beauty and scent of the rose, or even, if you know the play, the insignificance of family ties to the course of true love.

Not a bit of it. Shakespeare was no fool, he was talking about Resource Oriented Computing! Here's the full quotation...

What's in a name?
That which we call a rose
By any other name would smell as sweet.

"Romeo and Juliet", Act 2 scene 2

As you can see, Shakespeare is posing one of the fundamental questions in ROC. What's in a name?

To which he responds by stating the second axiom of ROC: a given resource ("That which we call a rose") may have any number of identifiers ("by any other name") and will resolve to the same representation ("would smell as sweet"). In so doing, he implicitly alludes to the first axiom of ROC (resources are abstract) by implying the existence of the Platonic abstract rose ("That").

Shakespeare, being rather good at his job, lays the foundations of ROC in 18 words.

So having got you warmed up with some pretensions to English Literature, I'm going to leave that can of worms there, and instead switch to Mathematics and to a "mathematical quotation" that deserves to be equally as well known.

Goldbach's Conjecture

Goldbach was an 18th Century German mathematician. A mate of Euler (of the famous "e to the i pi equals minus one" equation). In 1742 he sent this tweet to Euler...

@Euler: I reckon every even integer greater than 2 can be written as the sum of two primes

To which Euler retweeted:

@Goldbach RT: p1+p2=2n, n>2. You are almost certainly right but I can't think of a proof.

This is known as Goldbach's Conjecture. Here's the first few integers and their expression as the sum of primes...

4 = 2 + 2
6 = 3 + 3
8 = 3 + 5
10 = 7 + 3 or 5 + 5
12 = 5 + 7
14 = 3 + 11 or 7 + 7
... ???

As you can see, even for small n, it quickly becomes apparent that most n can be expressed by more than one pair of primes. In fact here's a beautiful diagram that plots how many possible pairs of primes can express "n" for the first million n.

It's called a "conjecture" because it remains unproven. We do know that, as of last time anyone edited Wikipedia, by numerical brute force methods it holds true for n<=1.609*10¹⁸ and, by statistical inference, its generally believed "there's a good chance it holds true" (ie the bigger n gets the bigger the choice of primes less than n).

What proving Goldbach's Conjecture would mean

So let's imagine that the Goldbach Conjecture is proved to be true. (Actually what follows broadly holds even if Goldbach is false thanks to an established "lesser" proof see ^† below).

The thing that jumps out at me is that Goldbach is saying that the primes constitute a normalized set of identifiers. To see this, lets forget our conventional Indian/Arabic numerals and give each prime number a unique symbol...

With this normal prime notation we can now write any even integer as a pair of such prime symbols...

So, now lets think about ROC. We know from Turing that any program in any Turing complete programming language can be expressed as a single integer (the binary pattern on the Turing tape encoding the program).

In ROC we also know that, even for non-Turing complete language runtimes, a resource identifier is simply an opaque token (usually implemented as a String) and ultimately expressable as an integer.

If Goldbach holds, then it follows that every resource can be identified with a maximum of two normalized symbols.

Implications

Before we get carried away, we can readily see that there is no unique symbol set. Nor, within any given symbol set is there even uniqueness of token pairs (see the chart again to see how any given n has increasingly many prime pairs). So breathe easy, I'm not suggesting we start a standards committee (although setting out to define a standard infinite symbol set for the primes might make more progress than most!)

It's just neat to know that it is possible to write any program in two symbols - which kills stone dead all future single-line coding challenges. But its never practically going to happen. Its a theoretical limit. You'll also appreciate, that by necessity, any minimization of identifiers leads to the need to expand the spacial context in which they are resolvable.

For me, the significance of this line of thought is to highlight that relativity and context are built-in to the fundamentals of "what's in a name".

ROC is an approach to information engineering that acknowledges this truth, and allows and indeed expects relativistic naming of information. Shakespeare knew it too...

What's in a name? That which we call a resource by any other symbols would resolve the same. Who's asking?

Talk: Resource Oriented Cloud Architectures

Don't forget, I'll be giving a talk on Resource Oriented Cloud Architectures at SkillsMatter in London on the 21st September. Here's the blurb...

As usual its a free evening event which usually ends-up down the pub. It requires registration, so book here now.

Have a great weekend.