
NetKernel News Volume 2 Issue 22
April 1st 2011
What's new this week?
Catch up on last week's news here
Repository Updates
The following updates are available in the NKEE and NKSE repositories...
 langmath 1.1.1
 NEW math language runtime library (see below)
 langxrl 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 restwebservices 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 pluggableoverlay to implement an HTTPtoROC verb translation pattern, which contrasts with part4a's verbrouter 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 SINKonly logical endpoint presented through the pluggableoverlay  even though, in Grégoire's setup, if it did go through the overlay it would endup 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 pluggableoverlay. 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 preprocess 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 multidimensional spaces. For example REST has POST, but in ROC we don't need POST, to "passbyvalue" we just modify the contextual space and do a regular SOURCE. In fact in ROC there is no pushstatetransfer, its all justintime 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 hairshirted 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 verbtranslation. Its just that the resolution model of the pluggableoverlay wasn't designed with verbtranslation 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.
†Its interesting that in linguistics we're increasingly seeing nouns used as verbs. For example "To google", or "I tweeted"  recent examples of an old pattern with the archetype "To hoover". But even old established nouns are being verbified, eg "to parent". I know I know, "Pete's gone all Wittgenstein"! But to me this is just evidence that the distinction between noun and verb is really just a matter of context (ie same identifier different spacial location), and reinforces my gut sense that ROC would still work with no verbs at all. (Obviously REST couldn't  its got no spacial context).
*New* Math Runtimes
I've got a new toy and you can play with it too...
The new langmath 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 builtin 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 builtin functions. You can think of it as a Matlablike 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 subset of the general tool, but is optimised with compiled AST expressions and Doublein/Doubleout normalised argument transreption. Its an easytouse 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...
active:calculate
The active:calculate runtime evaluates numeric expressions and produces doubleprecision numeric results.
operator
The operator argument is a mathematical expression to be parsed and numerically evaluated. This must be transreptable to a String.
Example
100*10.60
Variable arguments
Any additional arguments will be sourced as java.lang.Double and will be provided as variables to the operator expression.
Example
Suppose you invoke the service with
active:calculate+operator@[ ... ] + x@[ ... ]
If the operator is
x^22*x+3
and the x argument is 1.0
the expression "1^22*1+3" is evaluated and the value 2.0 is returned.
Any number of named arguments may by supplied and referenced in the calculation expression.
active:math
The active:math language runtime provides a rich symbolic and numeric mathematics engine.
operator
The operator argument must be transreptable to java.lang.String and is the mathematical expression to be evaluated.
Example 1
The operator
Expand[(x+1)*(x3)*(y+2)]
is evaluated to the symbolic expansion...
x^2*y2*x*y3*y+2*x^24*x6
Example 2
This is an example of calculating the symbolic derivative (with respect to x)...
D[x^2*y2*x*y3*y+2*x^24*x6, x]
is evaluated to the symbolic expression...
2*x*y2*y+4*x4
Variable arguments
Arbitrary named arguments may be supplied. Numeric arguments will be provided as numeric variables substituted into the operator expression.
For example:
operator: x^23*x+1
x argument value: 2
will return the numeric result 1.0
Alternatively if the named argument is a String it will be parsed to an expression and substituted into the expression...
For example:
operator: x^23*x+1
x argument value: y*z+3
will return the symbolic result (y*z+3)^23*(y*z+3)+1
Builtin Functions
The active:math tool is a nerd's paradise. It offers use of most of the functions of the Apache CommonsMath 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/((x1)(1+x))]", "(x^21)^(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^33*x2]", "{2,1}"); check("Factor[x^5  x^3  x^2 + 1]", "(x+1)*(x^2+x+1)*(x1)^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, 12th14th 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 oneday 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 distributedROC 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.
The best April Fool I've found so far is this: http://www.thinkgeek.com/interests/looflirpa/e8bb/ I hanker after the "Steve Jobs Keynote Theatre".
Limited Edition ROC Soft Wear
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 tshirt 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,
Comments
Please feel free to comment on the NetKernel Forum
Follow on Twitter:
@pjr1060 for daytoday NK/ROC updates
@netkernel for announcements
@tab1060 for the hardcore stuff
To subscribe for news and alerts
Join the NetKernel Portal to get news, announcements and extra features.