NetKernel News Volume 1 Issue 50

October 15th 2010

What's new this week?

• Repository Updates
• HTTP Updates
• The Art of Engineering
• Durable Scope: Resource Oriented Modelling Language

Catch up on last week's news here

Repository Updates

The following package is available in both NKEE and NKSE repositories...

• http-server 1.15.1
  • Adds httpRequest:/postParam/ resources and new HttpAccessorImpl base class (see below).

HTTP Updates

A couple of updates to the HTTP transport module contributed by Chris Cormack and Kim Foo-Jones.

The first is in the HTTP Bridge address space a new set of resources httpRequest:/postParam/....

This is specialization of httpRequest:/param/... and provides strict enforcement to guarantee that the returned parameter value was specifically from a POSTed application/x-www-form-urlencoded form and not from any possible URL query parameters. This is a convenience resource set and means you don't need to check for duplicate entries in the general set of httpRequest:/params if you have concerns over checking for possible parameter override security attempts on sensitive form submissions.

The second is a simple HttpAccessorImpl base class...

org.netkernel.http.transport.HttpAccesorImpl

This class extends NKF's StandardAccessorImpl to provide a high-level convenience base class for responding specifically to HTTP initiated requests.

By extending this base class you can override the following methods with specific handler code for each of the possible HTTP verbs GET, POST, PUT, DELETE, PATCH and HEAD...

  public void onGet(INKFRequestContext aContext) throws Exception
  { 
  }
  public void onPost(INKFRequestContext aContext) throws Exception
  { 
  }
  public void onDelete(INKFRequestContext aContext) throws Exception
  { 
  }
  public void onPut(INKFRequestContext aContext) throws Exception
  { 
  }
  public void onPatch(INKFRequestContext aContext) throws Exception
  { 
  }
  public void onHead(INKFRequestContext aContext) throws Exception
  { 
  }

When an HTTP request is resolved to your accessor the HTTP verb will be SOURCEed from httpRequest:/method and the corresponding onXXXX method is invoked.

If a specific HTTP onXXXX is not implemented, the accessor will automatically sink a 405 response to the HttpBridge and set the HTTP Allow header with the supported methods.

While this is a Java base class it can still be used with Dynamic languages, for example here's how you could use it from a groovy script...

import org.netkernel.http.transport.*
import org.netkernel.layer0.nkf.*
acc=new MyHttpAccessor()
acc.onSource(context)   //Delegate handling of request

class MyHttpAccessor extends HttpAccessorImpl
{
    public void onGet(INKFRequestContext context) throws Exception
    {   context.createResponseFrom("GET")
    }
    public void onPost(INKFRequestContext context) throws Exception
    {   context.createResponseFrom("POST")
    }
}

The Art of Engineering

Whilst implementing httpRequest:/postParam/... was a no-brainer (its just a constrained subset of the existing resources), we debated over adding the HttpAccessorImpl base class.

The discussion hinges on the tension between convenience and purity of abstraction. You see if you use this base class you are getting the convenience of some automatic handling and binding based on HTTP verb, but the cost is that whatever you implement in this endpoint is no longer a general resource accessor. It can only 'access' specialized HTTP-specific resources.

From the larger perspective, the tension is in seeing that, without care, this is the start of the route to larger and larger monolithic components. Whereas our belief has always been that the Unix tool chain philosophy is a natural complement to the ROC approach; light-weight composable tools that are combined to create value greater than the sum of the parts.

For example, the same functionality* could be implemented with a pluggable-overlay and a declarative routing resource. The overlay impl would look at the httpRequest:/method and then lookup a corresponding declarative request in the routing resource, and issue that request. If there was no possible routing for the HTTP verb it would do the 405 stuff. With this approach the HTTP specific world is decoupled and impedance matched to a general resource set.

The problem is that I'm schizophrenic on this. On the one hand I'm pragmatic and am happy that "if it works, the problems solved". On the other I have an instinctive sense that composability should be sought when possible as its this that makes large scale systems work and evolve over time.

Well neither Tony or I have a hair shirt - in fact I get bloody wound up with some of the angel on the head of a pin debates that go on in technology communities. We're ultimately pragmatists and we can see this base class might be useful and does little to encroach on architectural purity. So its there if you need it.

The Sermon

Judging the tradeoffs, the efficiencies and the long-term implications when creating complex systems is the essence of the art of engineering.

When you commit to a framework you are locking yourself into a prefab environment where freedoms are restricted, and in the worst case you may get to a point where all you can choose is the colour of the paint.

What drives me is the conviction that to build real, large scale information engineering systems, you have to retain architectural freedom. This is the philosophical foundation of Resource Oriented Computing. This is why NetKernel is not a framework, it is the embodiment of a general universal abstraction.

Step away from the APIs.

Durable Scope: Resource Oriented Modelling Language

It is pure coincidence, so please do not infer any correlation* between the release of the Chilean miners and the news that Tony has posted a new blog entry. In it he talks in-depth about the progress of the architecture explorer tooling and seeks feedback on the emerging Resource Oriented Modelling Language; ROC's UML.

Image by David Shrigley, linked from http://www.davidshrigley.com.

Have a great weekend - I'm off for a glass of Chilean red.