REST for Java developers

Sky-Tiger · 发表于 2009-2-4 23:25

ava developers who look at all these rewrites are surely thinking this looks obnoxious, inefficient, or insane. The hardest part of transitioning from an object-oriented to a resource-oriented perspective is to let go of your preconceived notions about how things should work. The steps I've shown you so far link a few things together logically. It is easy to change where the content comes from for the templating by changing a rewrite rule. Very large refactorings can be integrated into existing systems by making a change this small. To understand the power and beauty of REST on the inside, you must try to go with the flow!

The ffcpl:/scripts/customers.bsh script is quite straightforward: Go get the customer information and then style it:

main()
{
  req = context.createSubRequest("active:fetch-customers");
  customers = context.issueSubRequest(req);

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

  response = context.createResponseFrom(output);
  context.setResponse(response);
}

By now, you will not be surprised to see that applying XSLT to XML content looks like anything else in NetKernel. Under the hood, the module that handles this stuff uses Saxon, but again you do not really care. In Listing 3, we convert any <customers> elements into a table and populate it with rows filled from every matching <customer> element.
Listing 3. Transforming XML with XSLT

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:template match="customers">
<table class="customer">
   <tr class="header">
      <th>ID</th>
      <th>Name</th>
      <th>Street</th>
      <th>City</th>
      <th>State</th>
      <th>Zip</th>
   </tr>
   <xsl:apply-templates/>
</table>
  </xsl:template>

  <xsl:template match="customer">
<tr>
   <xsl:if test="position() mod 2 != 0">
      <xsl:attribute  name="class">d0</xsl:attribute>
   </xsl:if>
   <xsl:if test="position() mod 2 != 1">
      <xsl:attribute  name="class">d1</xsl:attribute>
   </xsl:if>
   <td><xsl:value-of select="@id"/></td>
   <td><xsl:value-of select="name"/></td>
   <td><xsl:value-of select="address/street"/></td>
   <td><xsl:value-of select="address/city"/></td>
   <td><xsl:value-of select="address/state"/></td>
   <td><xsl:value-of select="address/zipcode"/></td>
</tr>
  </xsl:template>
</xsl:stylesheet>

Pointing your browser at http://localhost:8080/xrlcustomer/index.html should yield the content shown in Figure 1.

Styled customer data
Figure 1. Styled customer data (Click to enlarge.)

Ruby on Rails and Grails scaffolding can produce this much content by running a few scripts. Once you get some more NetKernel under your belt, however, you will be able write efficient, flexible, cached scaffolding too that should perform extremely well. NetKernel is not necessarily a replacement for these MVC frameworks (although it could be). Instead, you can easily imagine using a NetKernel backend with Rails via Active Resource. If you like Ruby, NetKernel supports it as one of its implementation languages. Groovy is supported nicely too.

Sky-Tiger · 发表于 2009-2-4 23:25

Migration

The power of what you have seen so far is efficiency, productivity, maintainability, and the ability to use the right tool for the right job. The XSLT style sheet concisely expresses an efficient conversion of XML to XSLT in a language designed for that purpose. Trying to handle the conversion in Java would be ugly, error-prone, inefficient, and hard to maintain. NetKernel makes it extremely easy to move between the right tools. It also makes it possible to change technology choices without having a huge impact on dependent code. Again, interfaces kind of allow you to do this in languages like Java, but logical connections are much more flexible.

With working code to display customer information in place, it is now trivial to migrate the active:fetch-customers handler from the file-based prototype to an actual database-backed engine. This example uses HSQLDB, but it is easy to support other RDBMSs by modifying the driver configuration in etc/ConfigRDBMS.xml. First, seed the database by pointing your browser to: http://localhost:8080/jw-rest/db-init. This gets rewritten to a DPML script (another NetKernel language) that will populate the relational database. If you modify the example to use something other than HSQLDB, you will likely have to modify the SQL syntax as well. With the database initialized, it is now easy to come up with a new BeanShell that issues a SQL database query and then styles the results as XML:

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.