NetKernel News Volume 4 Issue 25

November 1st 2013

• Repository Updates
• Hello World from First Principles
• Resource Oriented State Machine Runtime

Repository Updates

Tom has questioned all his assumptions and gone right back to basics. In this blog entry he tries to cast aside assumptions and take you through a step-by-step Hello World guide...

http://practical-netkernel.blogspot.be/2013/10/back-to-beginning-hello-world.html

Great stuff Tom

Resource Oriented Computing (like REST) is fundamentally about the computation of the state of resources. We create solutions by working with representations of the state of a resource.

We engineer the computational efficiency by managing the computed representation state by holding on to it (caching) and assigning deterministic expiration constraints - so that the Nyquist sampling rate for the representation provides a sufficient approximation to reality.

If you are coming to the generalised world of ROC with a REST perspective then it would be easy to assume that external requests are the events that drive this "sampling of the computational state space". Of course they often are, especially if you're creating RESTful services (or even REST-style services with other protocols).

However it has been clear for a long time that richer, more advanced systems, comprise the interplay between many state transitioning events. Think for example of a database trigger, a JMS message, an NKP super-stack request, a cron event, an async throttle transition, a metadata driven architectural configuration change etc etc... The degree of complexity increases when we understand that the transition events can be both independent and dependent and that the computational context is also dynamic.

Usually our first thought when things get complex is to start writing code. But the problem with going down to the metal of code is that you can easily lose site of the big picture: our purpose is to "determine the state of resources" not to run code.

There's got to be a better way of elegantly dealing with complex state transitions which allows us to keep working at the high-level?

Of course, you know the answer, the title says it already, what if we had a true Resource-Oriented state machine runtime?

Actually credit is due to Brad Jones, one of the very earliest NK evangelists, since he first made the observation (about eight years ago!) that partnering NetKernel with state machines would be a very natural fit.

After some careful engineering, Tony has been able to integrate a standards-based SCXML hierarchical state machine engine and (no mean feat) extricate it from its default attempts to go down to the coding metal. In so doing he has delivered a pure ROC state transition engine embodied as an ROC runtime.

In his blog this week Tony provides a detailed introduction to the capabilites of the lang-scxml state machine runtime...

http://durablescope.blogspot.co.uk/2013/10/practical-state-machines-in-netkernel.html

I think, if my introduction made sense and you can recognise that NetKernel/ROC solutions are always purely about managing the computational state space, then the power and elegance of an ROC-enabled state machine is like moving from the long-bow to gun-powder.