NetKernel News Volume 2 Issue 22

April 1st 2011

What's new this week?

• Repository Updates
• On Verb Translation & Pluggable Overlays
• *New* Math Runtimes
• April Fools Joke

Catch up on last week's news here

Repository Updates

The following updates are available in the NKEE and NKSE repositories...

• lang-math 1.1.1
  • NEW math language runtime library (see below)
• lang-xrl 1.8.1
  • Update to fix a doco bug in the xrl:include references. Thanks to Gary Sole at Findlaw.com for finding this.

On Verb Translation & Pluggable Overlays

I had an interesting conversation with Grégoire Colbert earlier this week. He is implementing a number of REST services and was playing with the VERB translation tutorial in the rest-web-services tutorial (installable with apposite).

He discovered something which I thought I'd highlight. In part4b of the tutorial there is a section which compares using the pluggable-overlay to implement an HTTP-to-ROC verb translation pattern, which contrasts with part4a's verb-router pattern. Essentially it shows how the overlay can examine the httpRequest:/method resource and reissue a request into the wrapped space with an ROC verb: GET -> SOURCE, POST -> SINK etc.

It turned out that Grégoire only required a POST interface to his service. He therefore implemented an endpoint in his overlayed space that only implemented the SINK verb in its interface. Unfortunately he discovered that this endpoint could not be requested through the verb translation layer.

The situation is that the HTTPBridge always issues its ROC request as a SOURCE...

I've explained this previously, but it really is correct from the ROC perspective that it is SOURCEing a resource in order to satisfy the external HTTP event. No matter what the HTTP protocol method/verb is. HTTP is outside, the bridge is inside and is requesting a resource so that it has the state to satisfy the external HTTP request.

...but since the request is a SOURCE, it will not resolve on a SINK-only logical endpoint presented through the pluggable-overlay - even though, in Grégoire's set-up, if it did go through the overlay it would end-up as a SINK request! (If the SOURCE verb is implemented on the the inner endpoint, which is the most common situation, the request will resolve and be translated! Try the demo to see it working this way).

This highlights a design property of the pluggable-overlay. It is transparent (only reflects the endpoints it wraps) and so it is only executed if the request you are issuing is resolved to an endpoint inside its wrapped space. In Grégoire's case his outer request didn't resolve (because it really was still a SOURCE) and so his pre-process verb translator would never run to turn it into an inner SINK!

I've said it before and no doubt I'll say it again, verb translation (especially wrt to HTTP->ROC) leaves me uneasy and is not a pattern I feel comfortable with. I guess its because REST doesn't have any concept of multi-dimensional spaces. For example REST has POST, but in ROC we don't need POST, to "pass-by-value" we just modify the contextual space and do a regular SOURCE. In fact in ROC there is no push-state-transfer, its all just-in-time lazy pull.

I've got a gut feeling, a conjecture, that we could normalize ROC still further and not have verbs at all. Just requests and spaces. Context alone can determine the action on state^†. I don't know if this would make things any better from the engineering practicalities perspective - but it does hint at a further unification and normalization of ROC. But don't hold your breath - I'm happy with our current normalized set of ROC verbs for the time being.

Back to practicalities, if you're doing REST services and want the convenience of automatically handling the HTTP verbs you can very easily implement an accessor by subclassing the HTTPAccessorImpl base class. Which gives you extra overridable methods to seamlessly implement a handler for a given HTTP method with no verb translation necessary...

  public void onGet(INKFRequestContext aContext) throws Exception
  { 
  }
  public void onPost(INKFRequestContext aContext) throws Exception
  { 
  }
  ...

This approach was discussed extensively in the newsletters last year here.

With all that I've just said, Tony and I have discussed the verb translation overlay pattern. I know I can get a bit hair-shirted about the boundary between true ROC and the HTTP world outside. As I said, the HTTPBridge is actually being consistent to the abstraction, but I can see that if all you want to do is implement REST services then why not make it simple to map the verbs?

Also there's nothing implicit to an overlay that says it can't implement verb-translation. Its just that the resolution model of the pluggable-overlay wasn't designed with verb-translation in mind.

After the conference is out the way we'll look into creating a dedicated REST verb translator overlay which will resolve all of the HTTPBridge's SOURCE requests and translate them to an appropriately verbed* inner request. Watch this space.

*New* Math Runtimes

I've got a new toy and you can play with it too...

The new lang-math package in the repositories provides a pair of Mathematics language runtimes.

A high precision active:calculate numeric engine provides the ability to numerically evaluate arbitrarily complex mathematical functions with variable arguments.

A powerful general active:math runtime provides both numeric and symbolic maths capability and includes a rich and powerful set of built-in functions including symbolic calculus, linear algebra, algebraic expansion, matrix operations etc etc.

The two tools may be combined in pipeline processes to create very powerful and rich mathematical systems. (More on this to come after the conference!)

The active:math engine is really very powerful and comes with a very large set of built-in functions. You can think of it as a Matlab-like maths CAD system.

active:calculate is a tool that lets you write symbolic equations and provide variable values as arguments and compute the numerical calculated result. Its a sub-set of the general tool, but is optimised with compiled AST expressions and Double-in/Double-out normalised argument transreption. Its an easy-to-use component that could be used for dynamic algorithms, dynamic control systems, or just as a desktop calculator!

Here's some usage examples taken from the docs...

x^2-2*x+3

Expand[(x+1)*(x-3)*(y+2)]

x^2*y-2*x*y-3*y+2*x^2-4*x-6

D[x^2*y-2*x*y-3*y+2*x^2-4*x-6, x]

2*x*y-2*y+4*x-4

Built-in Functions

The active:math tool is a nerd's paradise. It offers use of most of the functions of the Apache Commons-Math library, and the JAS symbolic maths library.

For example here's just a small selection of what you can do (examples from the unit tests of the individual libraries)...

check("Sin[0.5]", "0.479425538604203");
check("Sin[Pi/5]", "1/4*2^(1/2)*(-5^(1/2)+5)^(1/2)");
check("Sin[{a,b,c}]", "{Sin[a],Sin[b],Sin[c]}");
check("Rationalize[6.75]", "27/4");
check("Complex[2,1/3]", "2+I*1/3");
check("PrimeQ[997]", "True");
check("NextPrime[41]", "43");
check("D[2*x^2 + 1,x] ", "4*x");
check("D[Sin[x]^Cos[x],x]", "(-Log[Sin[x]]*Sin[x]+Csc[x]*Cos[x]^2)*Sin[x]^Cos[x]");
check("Eigenvalues[{{1,0,0},{0,1,0},{0,0,1}}]", "{1.0,1.0,1.0}");
check("Fit[{{1,1},{2,4},{3,9},{4,16}},2,x]", "x^2.0");
check("Expand[1/((x-1)(1+x))]", "(x^2-1)^(-1)");
check("Expand[(a+4*b+c)^2]", "c^2+8*b*c+2*a*c+16*b^2+8*a*b+a^2");
check("Round[Pi]", "3");
check("Trunc[42]", "42");
check("Ceiling[3/4]", "1");
check("Sort[{a^2,b^3,c,-2*a}]", "{(-2)*a,a^2,b^3,c}");
check("CartesianProduct[{a,b},{c},{d,e,f}]", "{{a,c,d},{a,c,e},{a,c,f},{b,c,d},{b,c,e},{b,c,f}}");
check("Log[Exp[1+2*I]]", "Log[E^(1+I*2)]");
check("Solve[{x+2*y==10,3*x+y==20},{x,y}]", "{{x->6,y->2}}");
check("Roots[x^3-3*x-2]", "{2,-1}");
check("Factor[x^5 - x^3 - x^2 + 1]", "(x+1)*(x^2+x+1)*(x-1)^2");
check("TrigReduce[Sin[x]^3]", "-1/4*Sin[3*x]+3/4*Sin[x]");
check("Simplify[D[Integrate[1/(x^2 + 2), x], x]]", "(x^2+2)^(-1)");

Work in Progress

These maths runtimes are ready to use and work very well - however there are some caveats to be aware of.

We have some open considerations about normalized transreption for the active:math engine. Currently it returns whatever object the engine spits out - which could be a String (math expression) or a Double or Complex type. Looking ahead we'd like to explore if its possible to provide a uniform "math representation model" that would seamlessly normalize I/O to the tool.

For this reason the package is located in the "multiverse" repository and is a work in progress provided for experimentation and evaluation and/or unsupported production use.

There's no obvious reason you shouldn't be able to use it in production - just be aware that future releases may well evolve the representation model possibly resulting in minor refactoring if you want to use newer releases.

Over the Shoulder view of the ROC Development Process

The next article in this series will resume once we're the other side of the conference. The previous articles are here and here.

April Fools Joke

April is here, and for us Northern hemispherites spring is in the air, life is good and its due to get a lot better...

Its no joke that there's only two weeks until NKWest2011, Fort Collins, Colorado, USA, 12th-14th April.

We're working flat out to get together all the material and exciting new stuff. And the best news is its still not too late to grab a place...

http://www.1060research.com/conference/NKWest2011/

You already know the conference is preceded by a one-day bootcamp - so I won't tell you about that.

You also know that we'll be revealing the NetKernel Composite Development Environment (nCoDE) - so I won't tell you about that either.

But did you know we'll be showing you how to do some outrageous distributed ROC patterns with a detailed discussion of the NetKernel protocol (NKP). You'll discover that general distributed-ROC is a step change from HTTP/REST...

Really, its that good. I repeat my advice from last week: beg, borrow or steal your way to Fort Collins. You'd be a fool to miss it.

Limited Edition ROC Soft Wear

Not crap, post-modern.

I know, you're hankering after one of these cult icons but are worried that you'll upstage your colleagues?

But don't worry. We've gone to extreme efforts to make sure that the powerful statement it conveys, of being a member of the elite ROC glitterati, is not going to alienate those around you who aren't down wiv d' ROC possy.

We've achieved this by using some incredibly naive and primitive graphic design, which to a casual observer will be passed off as "complete crap".

Rest assured that only the dedicated ROCers will recognise this as a deliberate "post modern" diversion to ensure the powerful message emblazoned on the front is not going to overwhelm them.

As you can see, the logo is in "tastefully" subtle shades and reads "NetKernel ROCit Scientist" in faded green, black, blue with the word "resourceful" in faded black beneath. There's a range of styles and t-shirt colours available.

These items will be available on a strictly limited basis, when one hundred representations have been reified they will be unresolvable forever more. Get 'em while they're still misunderstood.

Have a great weekend,