Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

REST for Java developers, Part 3: NetKernel

A next-generation environment where SOA meets multicore

By Brian Sletten, JavaWorld.com, 02/03/09

Page 6 of 7

<mls>
    <module-uri>urn:net:bosatsu:jw-rest</module-uri>
    <filter>ffcpl:/data/.*xml</filter>
  </mls>

Note: This capability of fetching module-specific files can be reused and cached, just like anything else in NetKernel!

A listing of the sample XML files are returned and iterated over. Each document is fetched as a String:

cust = context.sourceAspect("ffcpl:/data/" + current, IAspectString.class);
  sb.append(cust.getString());

Then each document is appended to a StringBuffer to return the results. This one call to sourceAspect underscores NetKernel 's RESTful nature quite nicely. You have a logical request (ffcpl:/data/somefile.xml), a verb (SOURCE, equivalent to REST's GET) and content negotiation. Here, NetKernel is asked to convert the file on disk into a String representation known as a StringAspect. It would be trivial to convert the request to return a byte array, a JDOM Document, a DOM instance, or any other form you might want in a different context. An Aspect in NetKernel is an immutable view of a particular representation of a resource. Because it is immutable, the whole request can be cached until one of the input resources changes. If you do not care what form comes back, you can call the source method instead, which takes only the URI for the information resource you want.

Once the StringBuffer has all of the documents, the customer element is terminated, converted to a String and wrapped in a StringAspect. Based on existing mappings, if NetKernel is running and you installed the example module, you should get a list of customers back in plain XML when you hit http://localhost:8080/customer. Remember the HTTP request is rewritten to an active:fetch-customers request, which gets rewritten to an execution of ffcpl:/scripts/defaultcustomers.bsh.

Layering applications

You usually want a nicely formatted list of data, so now you will convert the XML that comes back from active:fetch-customers into some nice HTML. NetKernel has plenty of tools to help you do this. XRL is a recursive template mechanism not unlike Cocoon and similar tools. To keep you from getting confused, the module is configured to map external requests for http://localhost:8080/xrlcustomers to a BeanShell that will do the XSLT conversion of the data that is returned from the logically named customer persistence layer. Normally, you would use the same URL and content negotiation to decide whether to return XML or HTML. The module exports ffcpl:/xrlcustomers.* and then configures this behavior with a rewrite rule:

<rewrite>
    <rule>
      <match>(ffcpl:/xrlcustomers.*)</match>
      <to>active:mapper+operator@ffcpl:/links.xml+operand@$1</to>
    </rule>
  </rewrite>

This works because the sample module imports the XRL handling behavior:

<import>
    <uri>urn:org:ten60:netkernel:ext:xrl</uri>
  </import>

The XRL handler expects a file of links that customizes one or more rewrite rules. (It would get really old having to specify them all by hand!)

<links basepath="ffcpl:/xrlcustomers/">
    <link>
      <name>index</name>
      <ext>/index.html</ext>
      <int>active:xrl-html+template@ffcpl:/content/customers.html+content@xrl:customers</int>
      <args>links</args>
    </link>
    <link>
      <name>customers</name>
      <int>active:beanshell+operator@ffcpl:/scripts/customers.bsh</int>
    </link>
  </links>

A complete XRL tutorial is beyond this article's scope, but what is happening is that a request for ffcpl:/xrlcustomers/index.html is going to be rewritten to invoke the templating of the ffcpl:/content/customers.html file with whatever comes back from issuing the xrl:customers link. This currently points to the execution of ffcpl:/scripts/customers.bsh. The HTML template looks like Listing 2: