
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...
 langgroovy 1.6.1
 Updated the groovyallx.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 frontend fulcrum (see discussion below)
New: XMLDB / eXist Module
modxmldb 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 xmlupdate requests to an XML collection
 xmldb: URI scheme provides SOURCE/SINK/EXISTS/DELETE support on a collection referenced by URI.
modxmldb 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 preconfigured to be imported into the frontend fulcrum space. It was therefore odd that we'd not seen this failure before.
Looking at the visualizer trace, it was apparent that the StringtoBinaryStream 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 handson showcase of the visualizer. Its a very powerful timemachine 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 webmeeting 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...
eventdriven, highvolume, and datarich applications
lower development and code maintenance costs.
Matt has included some independent comments from Scott Rehorn, an architect at Quest...
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...
That which we call a rose
By any other name would smell as sweet.
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...
To which Euler retweeted:
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^{18} 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...
⊘ = 3
⊙ = 5
⊚ = 7
⊛ = 11
...
With this normal prime notation we can now write any even integer as a pair of such prime symbols...
6 = 3+3 = ⊘⊘
8 = 3+5 = ⊘⊙
10 = 7+3 or 5+5 = ⊚⊘ or ⊙⊙
12 = 5+7 = ⊙⊚
14 = 3+11 or 7+7 = ⊘⊛ or ⊚⊚
...
2^{1234567890} = ⊜⊞
...
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 nonTuring 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 singleline 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 builtin 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...
† Actually for our purposes, it was proved by Olivier Ramaré in 1995 that any even integer can be expressed as the sum of at most six primes. By which the implication for ROC is the same, there exists a normalized set of identifiers.
Incidentally, here's a bit of computer science history that tickles me...
"The primary purpose of the Data statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable Pi can be given that value with a Data statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change.", Fortran manual for Xerox Computers
I guess someone out there is still waiting for "the value of pi to change".
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...
In this talk Peter Rodgers will show how the Resource Oriented approach enables the clean separation of concerns of "code" from "system architecture". He shows that a small set of core "Resource Oriented Computing" building blocks are all that is required to create elegant nondistributed "serverside architecture". Showing how "ROCInside" offers a wealth of powerful engineeringled patterns such as concurrency management, systemwide caching, fault tolerance, longterm absorption of change etc.
After introducing the localized features of ROCdesign it is shown that a natural consequence is that ROC solutions are scaleinvariant. It will be demonstrated how, with no further modifications, a solution can be seamlessly scaled out across a distributed cloud platform.
As usual its a free evening event which usually endsup down the pub. It requires registration, so book here now.
Have a great weekend.
Comments
Please feel free to comment on the NetKernel Forum
Follow on Twitter:
@pjr1060 for daytoday NK/ROC updates
@netkernel for announcements
@tab1060 for the hardcore stuff
To subscribe for news and alerts
Join the NetKernel Portal to get news, announcements and extra features.