NetKernel News Volume 1 Issue 23

April 9th 2010

What's new this week?

• Groovy 1.7.1 available.
• Extensive updates and revisions to the documentation.
• How do you prove the value of ROC?

Repository Updates

lang-groovy: Updated to use the latest Groovy 1.7.1 release.

nkse-doc-content: In anticipation of an upcoming NKSE 4.1.0 build there has been ongoing refinement and review of the documentation with enhanced coverage of changes since the original 4.0.2 distribution release. Notable new content include:

• Identifier arguments - how the opaque identifiers may be parsed into sub-parts (arguments). How to reference and dereference arguments.
• Declarative requests - ehanced detail and a new section describing how to use the RequestBuilder to programmatically construct requests from declarative request resources.
• Standard Overlay base classes - new content describes the base classes you can use to create your own overlays if you need to go beyond the pluggable overlay.
• Request construction and issuing - explains the 3 different ways you can issue requests: by-reference, by-value and by-request. The latter was added relatively recently and allows you to pass requests as arguments, which when requested in the invoked endpoint cause that request to be evaluated. (Think pointer dereferencing but generalized to arbitrary requests and so enabling f(g(x)) functional patterns).

Extensive cross-referenced linking has been added.

nkse-docs: refinement to internal link resolution to support fragment hrefs. nkse-cron: Documentation updates.

jabber-xmpp-extra: An add-on package that offers an extension library for extended message types, file transfer, chatrooms etc. Module exports the smackx.jar classpath as a companion to jabber-xmpp.

[To make sure you're system is fully up-to-date use the apposite client http://localhost:1060/apposite/ - "admin", "synchronize", go back to "packages" and "Select all updates", "apply selection".]

NKSE 4.1.0 Build Plan

You might have inferred from the recent efforts to update and refine libraries and documentation that we're preparing the ground for the first 6-monthly point-release of NKSE.

Since 4.0.2 was released in October there have been many incremental package updates released through the apposite repository. We will very shortly issue a new NKSE 4.1.0 build which will incorporate all of the updates, together with a corresponding 4.1.0 repository.

How do you prove the value of ROC?

Last week I got hot and bothered about linked resources. This really was a symptom of my wider issue of how to convey the meaning and value of ROC to a world that is only in the early stages of embracing the subset of ROC which REST embodies.

So what is the value of ROC? The easy things to point out are the first order facets: like performance, scaling etc. The recent scaling analysis and nk-perf tools we published provide some concrete evicence of how ROC yields first-order benefits, being impedence matched to multi-core processing architectures and the way ROC caching provides systemmic extrinsic memoization...

http://www.1060research.com/netkernel/scaling/

All very nice. But to focus there is to almost entirely miss the point - since with an underperforming conventional system you can always throw more compute power at problems. So performance is nice, but not sufficient of itself.

To explain where I think the killer value of ROC is, I need to tell you a short story. Back in the mid-90's I was working in HP Labs. I'd joined HP straight after finishing my PhD in quantum mechanics and had had a lot of fun dipping my toe into all sorts of technology areas. I'd come to realise I wanted to really dig into researching the Web as the basis for software systems beyond just, what at the time was, browsers and HTML content.

Because I'm lazy, the thing that appealed to me was that the Web was (still is!) an address space of potential reifiable state. And that was home territory, since that is very very similar to quantum mechanics: until you make a measurement all you have is a (Hilbert-) space of potential state. Measurement causes the collapse of the infinite potential state to a concrete information value. Pretty much exactly what happens when you resolve a resource identifier of an abstract Web resource to a representation value. REST was a no-brainer (or it would have been if there was a word for it back then).

So having cockily thought 'I "really get the Web" now to push it to the limits'. I wanted to build Web-scale information architectures that could tap these insights into the conceptual equivalence between the Web and QM. But to do that I could only build stuff with the software technologies that were available at the time, J2EE, EJB, Servlets etc etc. I got the shock of my life. It was terrible. The intricacies of language and higher order APIs meant that you just drowned in irrelevant detail. That or the effort to build even relatively simple systems just didn't justify the cost.

Someone in the real world with a business imperitive and a deadline would have pushed on, maybe created a higher order abstraction to solve for the problem domain. Maybe even have gone down the Spring route of stepping away from J2EE to an API model that was actually useable.

But being in a research environment I had the very rare luxury of being able to step back and consider the situation. What I'd hit was not a technical problem. I'd hit an economic one. The things I wanted to do just weren't economically viable. Another factor that was on the horizon ruled out building higher and higher order abstracted object models. Flexible data formats were starting to emerge, especially in the, then, brave new world of XML - look at the number of vertical industry domain working groups creating schemas left, right and center in the late 90s. This effort was all very worthy, but then you realise that each dialect needs a software embodiment and you are looking at the birth of the "million bastard offspring of EDI". Even worse, if you could afford to club-together and build an implementation (for example Rossetta net - the technology industry's supply-chain and procurement standard and implementation system), almost sure was that you'd never be able to afford to change it. What good are a million protocols that are locked in the late 1990s because the economics of embodying them in software dominate.

(I'm nearly at the original point about the true value of ROC! Honest.)

Armed with this perspective, we started thinking about the fundamentals of software. Why did the Web succeed? How could we bottle the essence of it and apply it more generally - both in the large and the small scale?

I updated our NetKernel page this week. I tried to succinctly answer the question "How do you prove the value of ROC?" see...

http://www.1060research.com/netkernel/

Here's a direct quote...

"Strangely perhaps, but less so when you've played with NetKernel and explored some of the concepts behind ROC, our most compelling evidence is the World Wide Web; the most successful software system ever created. The Web succeeds because of its fundamental economic property: All information systems are compelled to change. For the Web, the value added by a change is greater than its cost.. More concisely, the Web is a software model in which change is cheap.

You might not have realized it but the Web is an ROC system. We demonstrate this in the first NetKernel tutorial, where it shows that the Web is an instance of just one basic ROC pattern using a single ROC address space.

Its cheap to create, modify, augment and evolve solutions in the Web. The Web is an instance of an ROC system, it follows that it is cheap to create, modify, augment and evolve solutions in ROC. The existence and success of the Web demonstrates this over the long term. NetKernel is a generalization of the ideas behind the Web, for the first time it allows the Web's economic values to be applied to any class of software problem both Web and non-Web."

Maybe I should have updated the "Are you crazy?" section with "Yes".

Maybe, maybe not. Actually, and here's the spin, Randy told me about a conversation he had yesterday with an established customer. They have an NK production integration solution that glues together mainframes with workgroups with you name it. One guy maintains it. While the rest of the organization is scheduling a month or more to implement new features, when a change request comes to our NK customer he can implement the features in a day or so. The rest of the organization still hasn't caught on to his secret so he is the superhero in the group.

(Thinking of changing the title of the NetKernel Newsletter to "Rodgers' Believe it or Not")