REST for Java developers, Part 3: NetKernel

A next-generation environment where SOA meets multicore

1 2 3 Page 3
Page 3 of 3
main()
{
  req = context.createSubRequest("active:sqlQuery");
  req.addArgument("operand", "ffcpl:/scripts/customers.sql");
  output = context.issueSubRequest(req);

  req = context.createSubRequest("active:xslt");
  req.addArgument("operator", "ffcpl:/scripts/results.xsl");
  req.addArgument("operand", output);
  output = context.issueSubRequest(req);

  response = context.createResponseFrom(output);
  response.setMimeType("text/xml");
  context.setResponse(response);
}

You will continue to notice the same patterns, the same flexibility, and the freedom to choose the right language for the job. Investigating the implementation details is left as an exercise for the reader. Consult the NetKernel documentation (http://localhost:1060) for details. In order to get this code to run instead of the file-based version above, you simply change the rewrite rule in module.xml for active:fetch-customers to:

<rewrite>
  <match>active:fetch-customers</match>
  <to>active:beanshell+operator@ffcpl:/scripts/dbcustomers.bsh</to>
</rewrite>

This kind of change requires a NetKernel bounce (there are other ways to handle it, but this is the easiest way for now). CTRL-C in the terminal window where you launched NetKernel and restart it. Now, if you hit http://localhost:8080/customer, you should see some different data styled like the files were above.

One of the main benefits of logically connecting your components is that clients do not break when implementations change. If you point your browser back to: http://localhost:8080/xrlcustomers/index.html, you should see the new data styled via the old process. This is a powerful strategy for migration.

In conclusion

The benefits of REST for integrating systems are becoming quite well understood. The idea of taking the ideas inside your software architectures is quite revolutionary. NetKernel isn't necessary for building RESTful systems; it just makes it very easy to do. The beauty of an environment like this is that the same benefits apply inside as outside. The potential to cache, pick implementation languages, change implementation, and so on are all powerful and they're generally unavailable as easily in any other system. Orchestration across heterogeneous back-end systems is trivial. Changing a locally resolved call to a remote, distributed call can be done on the fly. You can leverage cloud assets if needed without having to design your system around the concept. You are also free to take advantage of modern languages such as Clojure, Groovy, and Scala; domain-specific languages such as XSLT; and legacy code that has been written in Java for years.

Dealing with your object representations is also a perfectly reasonable thing to do within NetKernel. It is not that objects are bad or useless; they remain good implementation tools. They simply do not represent a level of abstraction that works well for unifying everything that goes into modern systems. There have been valiant attempts to do so, but so far none have really taken off. The resource-oriented style embodied by NetKernel could be just such a successful attempt. Not only can you easily end up reusing most of what you have committed to in the past (Java, Hibernate, SOAP, JDBC, and so on), but you can start to build new types of systems as you go; it is not an all-or-nothing proposition.

Even if you cannot use NetKernel where you work, downloading it and playing with it will help you understand REST at a deeper level. You must be warned, however: once you start building systems the NetKernel way, your thinking about software is likely to change forever.

The next article in this series will tie up many of these ideas into a larger vision for building modern, information-driven architectures.

Brian Sletten is President of Bosatsu Consulting, Inc. a services company focused on using Web and semantic-oriented technologies to solve architectural and data-integration problems not handled by conventional tools and techniques. He has a background as a system architect, developer, mentor, and trainer, with experience in the online game, defense, finance, and commercial domains. Brian has a B.S. in computer science from the College of William and Mary and lives in Fairfax, VA.

Learn more about this topic

More from JavaWorld

1 2 3 Page 3
Page 3 of 3