I’ve been interested in Netkernel for a while. It offers a decarative development approach, like using SQL to query a database instead of writing the code that performs the actual query processing. Netkernel also gets extra bonus points for embracing REST (but I digress).
Netkernal lets you focus on logical resources that are loosely coupled. You can use declarative and imperative languages where they make sense.
As a simple example, I set out to build the simplest possible application that could accept an HTTP GET request, query a database, and return the results of the query as an XML document. Here’s the core application, minus the configuration of the module and database connection:
<idoc>
<seq>
<instr>
<type>sqlQuery</type>
<operand>
<sql>
SELECT id, name
FROM items;
</sql>
</operand>
<target>var:queryResult</target>
</instr>
<instr>
<type>xslt</type>
<operand>var:queryResult</operand>
<operator>ffcpl:/resources/style/get-item-list.xsl</operator>
<target>this:response</target>
</instr>
</seq>
</idoc>
This is a Declarative Process Markup Language (DPML) document. It contains a <seq>uence of three two <instr>uctions. The first instruction queries the database and stores the result in the variable “queryResult”. If you view an XML representation of the query result it looks like:
<results>
<row>
<id>1</id>
<name>Foo</name>
</row>
<row>
<id>2</id>
<name>Bar</name>
</row>
</results>
This could be returned as the response document, but elements named results/row don’t exactly describe the sematics of the data. Therefore, the next instruction uses a small XSL stylesheet to change the document structure to:
<itemlist>
<item>
<id>1</id>
<name>Foo</name>
</item>
<item>
<id>2</id>
<name>Bar</name>
</item>
</itemlist>
<pre>
The third instruction “casts” the result to a MIME type of text/xml. As Peter pointed out in the comments, if I use the stylesheet to define the output method as XML, using <xsl:output method=“xml”/>, I don’t need the third instruction, which was:
<instr>
<type>cast</type>
<operand>var:serviceResult</operand>
<operator>
<cast>
<mimetype>text/xml</mimetype>
</cast>
</operator>
<target>this:response</target>
</instr>
Notice that I haven’t had to worry about object types. Netkernel takes care of that for me.
Production Ready
The use of a declarative development approach means that if it works as desired it’s ready for production. There is no imperative code in this application so there isn’t a whole lot to test. The only optimisation would be to use Netkernel’s built in caching to minimise the load of the database.
This example plays to Netkernel’s strengths, but contrast it with the imperative code required to build this application in Java or C#.Net.
The Backstory
A while ago I ran some code metrics on a Java servlet Web application that I’d written. I was surprised at just how much code was involved. 5,500 non-comment source statements (NCSS) for an application that had about 20 data entry forms. That seemed like a lot.
Stripes had been used for the Web framework and Hibernate was used for the database layer. These two tools had reduced the amount of Java code that had to be be written, and about 500 NCSS were to manage an archaic interface with another system. That leaves 5,000 NCSS for user interface logic and domain model.
This exercise prompted me to start looking at alternative ways of developing applications. What’s that? Ruby on Rails, Django, and friends. Sure, they are options, but I was looking for something different. I wanted something declarative, not imperative. Netkernel fits that requirement.
Update: A simple Netkernel Spatial application
