NetKernel News Volume 3 Issue 24

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 practical<dot>netkernel<at>gmail<dot>com.

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.

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