|
NetKernel News Volume 2 Issue 36
July 8th 2011
What's new this week?
Catch up on last week's news here
Repository Updates
The following updates are available in the NKEE and NKSE repositories...
- demo-resolution 1.1.1
- New demo to accompany the resolution tutorials (see below)
- nkse-dev-tools 1.33.1
- Update to request trace tool to make a probe-request a root-request for clarity in visualizer.
- nkse-doc-content 1.33.1
- Added resolution tutorials to documentation (see below)
The following update is available in the NKEE repository...
- nkee-apposite-1.25.1
- Sychronization speed enhancement and higher cadence on repo checks to find updates faster.
ROC Resolution
At the end of last week Gary Sole of Thomson Reuters got in touch on the forum with a very important question. The summary of which is: "Where's the detailed documentation for request resolution?"
The reason this was important was that whilst there is coverage of resolution in the ROC basics tutorial and, for example, as a general concept in the ROC principles book, it brought me up short and made me realise we were sitting too close and had been rather taking this for granted.
It was a double wake-up call, since Gary has a very solid grasp of resource oriented architecture (having been on NK3 for years) and recently having shown us some of the details of a seriously cool "Corporate Services on Rails" framework he's putting together on NK4.
So, I started to think about how best to make up for this pretty serious shortfall. It didn't feel like it would be particularly useful to write a set of detailed documentation. Resolution is something that's really quite new and different to classical software. Even though we're somewhat familiar with it in the Web, with the interaction between browser, DNS, network routing and load balancing, we still mostly take it for granted because it "just works".
To some extent ROC resolution, like with the Web, "just works", but its also much more general than is seen in the Web. And, actually, it's the basis by which the architectural power of ROC is accomplished and which enables a broad superset of patterns beyond what you see in some classical software models (eg, aspect orientation and inversion of control are just small subsets).
Video Tutorials
Resolution is a dynamic just-in-time process. All requests for all resources are instantaneously resolved and bound for each and every request.
It follows that the best way to really get a sense of it, when you're learning ROC, is to see it in realtime. So I've prepared a series of short-video tutorials. Each one explores a particular basic resolution pattern and the set progressively builds to cover the whole subject.
The first one is embedded below. It also provides some introductory context and, by using the Web as analogy, explores the nature of general resolution as a concept unique to ROC...
This video might be useful to watch just as an introduction to the concepts. If you're wanting to get a real developers practical background then the rest of the series can be found here.
They're also provided in the system documentation with the new update shipped in the repos today. Also shipped in the repos today is a new package demo-resolution which is the module which is used in the demos and allows you to follow-along and use the tools to get your own sense of the resolution process.
Why Resolution is Possible
The funny thing about resolution is that if your mindset is in the classical software world, you'd think about it and quickly dismiss it as a crazy idea. Surely a system which dynamically couples itself for every call between every software function would be impractically slow? This is not loose-coupling, this is no-coupling!
You might think that. But then think about the Web. That's exactly what it does. The Web works efficiently because DNS can be locally cached so the lookup time of any physical endpoint is a one-time hit and subsequently is effectively free.
Guess what? The same is true for NetKernel and ROC.
Inside NetKernel we treat resolution in the resource oriented domain, the result of the resolution process is a representation! It can be cached and, just like the regular representation caching, it can have a consistency model associated with it based on the spacial scope that is used during the resolution.
The net effect is that the resolution cycle in NetKernel is a one time cost. You get the benefits of completely decoupled dynamically configurable architecture, with the equivalent of statically-linked operational efficiency.
I've said it before, but maybe after you've watched the videos it will make sense, but, in NetKernel we are JIT compiling architecture.
NK4UM v1.2
Chris Cormack has released v1.2 of the nk4um application.
We've migrated our production system over and its running nicely. You can tell its 1.2 as its now showing a list of recent posts on the front page.
Apparently Chris is migrating Delta XML's customer forums from the old NK3 to the new NK4(um) today. So we're glad to have been the guinea pigs - its certainly production ready and very fast and efficient.
Belgium Bootcamp
Keep you diaries open for October in Brussels. This will definitely happen. We need to fix a date and sort out logistics but be ready for a ROC Fall (Autumn geddit?) in Brussels.
Have a great weekend,
Comments
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.