2013/02/08

reuse

As happens so often at the start of the new year, at least a couple of the good intentions are quickly moved aside under the pressure of reality. In this case under the pressure of absolutely crazy (in a good way) things happening in the NetKernel space.

So let me talk a bit about reuse while you wait just a bit longer on the second episode of Pinky and the Brain. I'll start with a quote from Frank Boddeke
Most of our products are re-shuffles of modules we already have.
Sounds crazy ? Well, did you look at the periodic table recently ? I had to learn it by heart in secondary school and my knowledge is still - largely - relevant today. It was already largely relevant in 1896. I was in secondary school in the (nineteen)eighties. The number of new molecules that has been build with those same elements since then is huge (not the mention the number since the days of Mendeljev himself).

NetKernel works the same way. And the simile continues, for just as you can also compose molecules, everything is a resource and the composition of a resource is also a resource which can be use in a composition ...

Not convinced ? Well, recently I quickly required a set of resources, let us abstract it as res:/nameproject/resourceid. Now, as these things go, this is an infinite set of resources. A couple of these resolve to actual data, most do not. I needed a sensible default for those that don't.



Didn't I recently read about just that pattern ? Yes, I did ... in the Tic-Tac-Toe series. Here's the relevant bit of mapper configuration :


    <endpoint>
        <verbs>SOURCE,SINK,DELETE,EXISTS</verbs>
        <grammar>
            <simple>c:{x}:{y}</simple>
        </grammar>
        <request>
            <identifier>active:cell</identifier>
            <argument name="x">arg:x</argument>
            <argument name="y">arg:y</argument>
        </request>
    </endpoint>
    <endpoint>
        <verbs>SOURCE,SINK,DELETE,EXISTS</verbs>
        <grammar>
            <active>
                <identifier>active:cell</identifier>
                <argument name="x"/>
                <argument name="y"/>
            </active>
        </grammar>
        <request>
            <identifier>fpds:/ttt/cell/[[arg:x]]-[[arg:y]]</identifier>
            <representation>java.lang.String</representation>
        </request>
    </endpoint>
    <endpoint>
        <grammar>
            <simple>res:/ttt/cell/{x}-{y}</simple>
        </grammar>
        <request>
            <identifier>res:/ttt/cell/default</identifier>
        </request>
    </endpoint>


Still not convinced ? Well, recently (did I mention times are crazily busy ?) I was asked to design a central logging component for NetKernel. Not a problem, you just provide a java.util.logging.SocketHandler handler in your logging configuration. But where do the logs go to ? Well, you could surely use something like Splunk, but there are NetKernel patterns/molecules for it too !




The Enterprise Edition users could do it with NKP and seamlessly log straight on a (or multiple) central server(s). For the Standard Edition users ... remember Camel ?  In fact I blogged about it myself here.


 from("mina:tcp://0.0.0.0:" + vPort + "?textline=true&sync=false")
 .to("class:org.elbeesee.logging.consumer.endpoint.LogMessageHandler?method=onMessage");


And that's it. Five minutes to pull together a module that provides a central logging server.

Enjoy and watch this space for more soon !