NetKernel News Volume 7 Issue 2

March 24th 2016

• Repository Updates
• NetKernel Updates 5.3.1 / 6.1.1
• New: Polestar 0.2 Released
• Video: Resource Oriented Microservices - London Microservices Meetup
• Modelling Twitter with ROC

Repository Updates

Today sees a large release of updates that can be installed with Apposite. We will also soon release a new distribution which brings together all of the updates since we put out the 5.2.1 download over two years ago.

Provisionally we're calling this NetKernel v5.3.1 but you never know we might end up going for the psychologically significant 6.1.1 numbering!

Of course versioning of the distribution is pretty much meaningless since by its modular decoupled nature NetKernel has always used an evolvable and progressive update model (we were happy when Microsoft copied us in Windows 10 - better 14 years late than never).

The rule of thumb is that so long as you pull the latest updates from Apposite you'll be fully up to date with the latest stable system.

When you want to create a reference production instance you should use Gradle NetKernel plugin to snapshot your base image (exactly the same as containerisation but with the only requirement being a copy of a JVM to run it on - so you can use this with or without a microcontainer infrastructure).

What's New

The updates include general maintenance to tools and documentation but more broadly it provides a comprehensive update to the module management infrastructure after a thorough review.

Modules are still deployed either by editing etc/modules.xml or by adding a collection in etc/modules.d/ - however we've made it so that the default is now for tools to put entries in modules.d/ We recommend that you leave modules.xml for core system modules managed by Apposite.

Applications and any other user-side modules should be declared in modules.d/

To keep track of where things are, the module manager in layer0 has been updated and now provides the metadata to know where any given module is declared. (When you have 500 modules in your system and need to add a new module to a specific collection this is really useful).

A full review and update of the documentation now makes sure that discussion and recommendation for module management is consistent and fully explained with examples.

Below are some screenshots of the visible signs of the updates...

Polestar 0.2 has just been released one year after initial 0.1 release. This version features significant enhancements to functionality in addition to stability improvements after using in the field for year.

Polestar is an Internet of Things hub for NetKernel. It is perfect for monitoring sensors (or in fact any accessible resource!) it will store changes to the sensor values over time and triggers scripts on changes.

Visualisation of the data is also a big part of the capabilities - it can generate HTML5 charts and diagrams using inbuilt libraries.

Polestar is fully configurable through it’s web interface using dynamic groovy scripts.

The live Polestar demo site includes all the details of how to get the NK modules etc...

http://polestar.io

What’s New

• Multi-value sensors with named fields. (map) Sensors can now represent vector values. This is particularly useful for things such as storing the RGB levels of lights source, traffic decomposed into speed buckets and sound levels decomposed into frequency bands.
• Declarative errors on sensors. Sensors can now automatically report errors based upon their value by specifying declarative error checks. These checks include no updates within a period of time, value goes above or below threshold, value equals or does not equal a specified value. Currently these checks work with scalar numeric values and booleans.
• Sensor errors reported in header. When errors are present a red notification is present on the banner of every page. Clicking this notification takes you to a filtered view of sensors showing which sensors are in error.
• Improvements to stability. A low-level leak in the way groovy interacts with java.beans was discovered and worked around. This leak is still an issue with the latest Java8. In addition scripts executed periodically are not re-executed until all scripts from previous invocation are completed. This stops badly behaving scripts (usually due to long blocking IO) from causing thread starvation.
• Sensor last changed values are periodically persisted. This is so that they are recovered even if Polestar is ungracefully stopped.
• New icons. car, letterbox, river, server, sound.