NetKernel/News/3/24/May_18th_2012
search:

NetKernel News Volume 3 Issue 24

May 18th 2012

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

  • lang-groovy 1.11.1
    • Updated to use latest stable 1.8.6 release of Groovy
    • Enhanced context classloader to enable JDBC Drivers to be loaded from the ROC domain - patched groovy.sql.Sql to workaround limitations of DriverManager classloading model. Thanks to Claude Nanjo for reporting this.

Tom's Blog

Tom has some big news...


We - the NetKernel community - write our own history. Today, there's a new page in that History, or rather a new book...

http://practical-netkernel.blogspot.com/2012/05/firsts.html

As always, your feedback and ideas for future posts are most welcome at practicalnetkernelgmailcom.

Verbal Debate

I intend to follow up on last week's somewhat esoteric discussion on resources, identifiers and state by providing some concrete examples. But already it seems to have sparked some valuable discussion. Jeff Rogers and Tom Hicks have an ongoing debate in the Forum...

http://www.1060.org/nk4um/topic/887/

... and, as I was intimating in the article, I think we, the ROC community, need to reach an agreement that allows us to pragmatically make design decisions when extending the tools and services we build on NK.

For the record, the current guidelines of the physical domain's expectation on use of verbs is in the docs...

http://docs.netkernel.org/book/view/book:guide:physicalreference/doc:physicalreference:request:verbs

...of course what's not there, is the "logical interpretation" or the "semantic interpretation".

Unfortunately I don't have the bandwidth to actively contribute to the discussion today, but shortly I promise to cover the following points in depth...

  • Why SOURCE tends to dominate even in cases where you're doing external updates (like, active:sqlUpdate)
  • Discuss the suggestion that "side-effects are tolerated" in ROC but not in REST. Actually ROC's extrinsic all-pervasive determination of state means that side-effects aren't side-effects, they're effects and so are deterministic.
  • How this leads to systemmic referential integrity and so systemmic-memoisation.
  • How the broader range of verbs is necessarily utilised in Endpoints which are state bearing. But since a design objective is for most endpoints to be stateless then naturally SOURCE-only endpoints proliferate. Not least in that, for any system there is "more middle than edges", so quite naturally there are more stateless transformational endpoints than state bearing "full-verb-range" data-endpoints.
  • Why NEW is new and not found in REST.
  • How we can get our heads around "potential state" and contextual representation.

Sorry for the brevity, but in the mean time, I really appreciate that the debate is taking place.

Letter from the Pacific: Weather Alert Appliance

Some of you will recall last year's post-Tsunami conversation with Mark Bradford, Chief Meteorologist of the Marshall Islands (highlighted region in diagram).

Mark's also a dedicated ROCer, and this week I got an update from him which he has kindly consented to let me share.

As the earlier discussion of the Tsunami impact attests, Mark's technology requirements can literally be matters of life-and-death...


I actually have a commercial NK app for the US Army here. It is a Mass Notification System using NK and the Common Alerting Protocol (CAP). I call it a Weather Alert Appliance. While there are many commercial MNS packages available, they are all very expensive, typically $10K US per node with a $250K minimum entry.

Our Army base relies on phone calls and sirens for warning notifications. When we issue a weather warning, we have a long call tree to go through, e-mail is not sufficient because we cannot ensure it was received in a timely manner. Real warning systems require warning acknowledgement, and have authentication and non-repudiation characteristics.

There have been severe budget cuts here, so there is no funding for a big commercial MNS, nor will there be. We have a forthcoming warning situation that is far more complex than our current warning requirement situation. To respond to that situation I have proposed a VLAN of "alert appliances", these are Asus Eee X101CH netbooks running Windows 7, with a JRE and NetKernel installed. The netbooks are stripped down so they only run NK, a browser, and our NK application. My application operates on CAP messages over XMPP. The CAP messages are stored in the file system, so the application follows the web server pattern. CAP is all XML, so NK is a fine match for this. The reason for using the X101CH instead of a less expensive netbook it that it can be operated as a WiFi hot spot and alerts communicated to mobile devices, which allows warning recipients to step away from the appliance and still receive and acknowledge a warning.

The core resource in this application is the CAP message. I have a NK application to create a weather warning (Warning Dashboard), which generates a CAP message and transports it to an Openfire Jabber server/Alerts server in a VLAN. The alert appliances all live in the VLAN and have no DNS resolution, they "know" only the Openfire server via host file. The appliances listen for jabber messages and receive them, if the geocoding in a CAP message matches the location of an appliance, the message is transrepted into an alarm (audible and several browser representations including Google maps). A status message is sent to all appliances every three minutes. Active warning messages are moved to an archive when they expire and kept locally for 24 hours.

Why not use ATOM feeds, e-mail, or a straight URL? We do all that, but none of those guarantee timely warning receipt. CAP over XMPP in NK allows me to verify that warnings reached an appliance in less than one second. I know the appliances are sounding the alarm, and the people at the appliance have 15 minutes to click a button for a human response to the warning.

The prototype is a NetKernel Standard Edition application, but the second generation will be NKEE on the alert server and warning dashboard server with NKSE on the appliances.

I'm also doing this in the nCoDE environment to teach my meteorological staff how to wrap their heads around the ROC model using simple composition via nCoDE. Since nCoDE is what I wanted, I try to use it as much as possible. This means nCoDE examples, examples, examples. These examples make the ROC abstraction real for my "students" and they can see the equivalence of the diagrams, lambda calculus, and XML.

Oh, what's the price for the prototype? $300 US per node, plus setup labor, add $150 US for an iPod Touch and you're mobile.

When I asked Mark if he'd mind me quoting this story he offered these further comments...


I would add this to my MNS project description:

NetKernel has an incredible range of powerful, sophisticated tools. However, the simplest ROC implementation, the basic Web Server pattern, using a single resource, aggregated into a resource set, with the simplest xslt transreption, can give a powerful result. We use a single transport, XMPP, and it works just as in the examples - keep it simple. Everything we really need for our application comes from vanilla NetKernel capabilities, no programs or languages are really needed, except when we're getting fancy with our resources. Just concentrate on the resource and simple transreption.

Thanks for posting the Cambridge ROC video, I've shown it to people here, the description of Slide 4, the ROC model diagram, is so very important. It really tells what NK/ROC is all about, and helps newcomers understand what NK does.

Mark

It makes me very proud to know that NK is supporting such an important service.

Incidentally, if you missed it, the video Mark mentions was posted two weeks ago here.

Plymouth ROC Pilgrimage

I don't know if Mark's any relation to William Bradford, leader of the Pilgrim Fathers colony, but like a Puritan departing England for the Colonies, I shall be heading West again next week to spread the word of ROC.

Which means you may be spared from enduring another newsletter next Friday.

If you're in the Beverly Hills area of LA and would like to meet up then "ping me a tweet".


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.

NetKernel will ROC your world

Download now
NetKernel, ROC, Resource Oriented Computing are registered trademarks of 1060 Research


WiNK
© 2008-2011, 1060 Research Limited