NetKernel News Volume 6 Issue 7 - Resource Oriented Computing Adaptive Systems (ROCAS)

NetKernel News Volume 6 Issue 7

May 28th 2015

Catch up on last week's news here, or see full volume index.

Repository Updates

NOTE: As announced previously, Java 6 is now end-of-life and since January 2015 all modules are built and target Java 7. Do not attempt to install updates if you are still running Java 6.

The following updates are available in the NKEE and NKSE repositories

  • hds-g2 1.6.1
    • Incremented mod-hds to version 1.1.1 to help maven dependencies in build tools
  • kernel 1.36.1
    • Added workaround to enable Thread management on Java 8 (see below)
  • layer0 1.111.1
    • Updated log message on Thread kill

The following update is available in the NKEE repository

  • nkee-architecture 1.15.1
    • Updates to the virtual host endpoint.

Kernel Update - Java 8 Thread Management

We released a one-line update to the kernel so that it can continue to manage rogue threads when running on Java 8.

Java 8 removed the method Thread.stop(Error) which, much to many peoples consternation, meant it was no longer possible to kill a rogue thread in Java.

We were particularly concerned about this since NetKernel is essentially an operating system and it has to be able to take ultimate accountability for threads when they are running widely varied code; code that is not necessarily well written, or even written by anyone that can be held to account (we've kissed a lot of open source library toads in our time).

Until recently we had assumed that Java 8 had simply eliminated our ability to kill errant low-level threads. However we came across this discussion...

Where someone with similar requirements was asking for the same thing: How can you kill a rogue thread (as a last resort)?

Well it turns out that hidden away in the Java 8 API documentation there is a small but important point...

Thread.stop(Error) - is no more - it will immediately throw an unsupported method exception. This is what the kernel called and so we had assumed that NetKernel could no longer manage threads on Java 8.



is still there and still enables you to kill a thread (only now you can't say why you killed it with an Error argument!!)

It can be seen in the javadoc that this method always throws a ThreadDeath exception - however it doesn't throw it until its killed the thread! We still have control in the last resort.

Today's kernel update changes that one method call. We've also changed the error logging to describe the reason (which was previously provided in the Error). So we are very pleased to say that low-level control and management of core threading is still possible on Java 8, and long may it continue - there are legitimate scenarios where killing a thread really is a necessary requirement.

Tony's Blog: Engineering the Artifact not the Process

Tony has been rattling the cage of Software orthodoxy. This time he's done it through Linked-In...

I am dissatisfied with the IT industry. From the outside people think it's all moving so fast and is full of relentless innovation towards the future. From the inside it feels at least in part like a stagnating pool with innovation increasingly confined to narrow niches.

Is this because we are focusing too much of our collective energy on the process rather than the artifacts we are creating?

Resource Oriented Computing Adaptive Systems (ROCAS)

DARPA, you know "the guys who invented the internet", have started to ask questions about why software is so poor. Here's the opening paragraph from the announcement of their new technical program Building Resource Adaptive Software Systems (BRASS)...

Modern-day software systems, even those that presumably function correctly, have a useful and effective shelf life orders of magnitude less than other engineering artifacts. While an application's lifetime typically cannot be predicted with any degree of accuracy, it is likely to be strongly inversely correlated with the rate and magnitude of change of the ecosystem in which it executes. This ecosystem typically comprises the clients of the application itself, along with a myriad of sophisticated libraries and middleware, managed services, protocols, models, drivers, etc. that, in turn, interact with the outside world using other complex artifacts like browsers, databases, storage systems, etc. Access to system components and the interfaces between clients and their applications, however, are mediated via a number of often unrelated mechanisms, including informally documented application programming interfaces (APIs), idiosyncratic foreign function interfaces, complex ill-understood model definitions, or ad hoc data formats These mechanisms usually provide only partial and incomplete understanding of the semantics of the components themselves. In the presence of such complexity, it is not surprising that applications typically bake-in many assumptions about the expected behavior of the ecosystem they interact with."

In other words, DARPA has identified what we felt all those years back: there is something fundamentally not right with our current model for software that leads to the saw-tooth of build-it-throw-it-away.

Furthermore, they are calling it out, taking a stand and pointing out how unnacceptable it is that software solutions have lifespans "orders of magnitude shorter than other engineering discplines".

At last!!!!!

After all this time, someone (a significant someone at that) shares our concern!

Its fantastic to at last be in such prestigous company and to no longer be a prophet in the wilderness.

Inspired by their call to arms, I decided it was time to bring together in a new whitepaper all our perspective and experience and show how Resource Oriented Computing solves the problem.

The paper is called "Resource Oriented Computing Adaptive Systems" (ROCAS).

It begins with a formal definition of stability and evovability before introducing ROC and shows how it generalizes from REST to a full computational abstraction. Having established the ROC abstraction it then presents a series of directly relevant consequences that ROC solutions exhibit - concurrency, systemic memoization, scale invariance, dynamic adaptive architecture, transrepresentation etc. It concludes with a short and sweet description of the implementation of the NetKernel platform.

I've been told its the most tightly argued and clearest explanation of ROC and NetKernel we've yet put together. I hope so. Its now high time that the classical "on-Tape" software paradigm be expanded to recognize that we have in our hands a more powerful and elegant dimension in which adaptive software is the norm.

Please take a look, we'd very much like to hear what you think of it, you can download it here...


BootCamp - London this Summer

We're still working on the logistics for the bootcamp and looking at late July or early August. If you would like to come along, or know someone who would like to get a fast track into ROC then please drop us a line and we'll get in touch when we've finalized the plans.

Demand will probably be high - we've already had several expressions of interest from the recent LJC meet-up.

SEO Help

These newsletters contain hundreds of articles with lots and lots of in-depth content on ROC and NetKernel. We've recently put quite a lot of effort into making them more search engine friendly - including ensuring that we're considered mobile friendly by Google.

One thing we need help with though is for this stuff to have good page-rank. We'd really appreciate it if you could link to articles you've found valuable etc. There's a partial list in the table of contents - even just tweeting links seems to get stuff more prominence in search results. Thanks we appreciate your help!

Have a great weekend!


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

© 2008-2011, 1060 Research Limited