Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

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

JavaWorld.com > Java Enterprise Edition >

REST for Java developers, Part 3: NetKernel

A next-generation environment where SOA meets multicore

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

  • Print
  • Feedback
.

Page 2 of 7

Many people are starting to realize that REST can fit into this space to provide an information-based solution to a wide variety of integration needs. Information references can be converted into specific forms on demand. With tools like the Restlet API, you have the flexibility of logical bindings but the convenience of local object references. The next article in this series will tie together many of these ideas into a larger vision; in this article I'll focus on the benefits that you might accrue from pushing the ideas of REST into the inner environment, not just the boundaries between systems.

Object-oriented abstractions

Today, we are used to dealing with URLs for documents. http://javaworld.com, for example, is a logical name that resolves to the JavaWorld homepage. You do not (necessarily) know anything about what's involved with producing the page, nor do you care what technologies are used; you simply want to consume the content on the page. By default, when you input the URL to your browser, you get a nicely formatted HTML page back. As long as that contract is maintained, the folks behind the scenes at JavaWorld are free to change their underlying technology without breaking the site for you.

The industry is becoming comfortable with the same idea for information in general. The URL http://someserver.com/customer/012345 might produce an XML document such as: 

<customer id="012345">
      <name>Sue Jones</name>
      <address>
        <street>12345 Main St.</street>
        <city>Cleveland</city>
        <state>OH</state>
        <zipcode>44114</zipcode>
      </address>
    </customer>

As long as you get back what you expect from such a server, the information producers are free to support alternate representations (JSON, for example) for other clients, change their underlying technology, and so on.

In the object-oriented world, we approximate this behavior by using interfaces. But without some extraordinary gymnastics, we lack the freedom to return completely arbitrary object representations. Anything that satisfies the interface language binding can stand in, but it is difficult to substitute arbitrary resources (scripts, an alternate language implementation, raw data, and so on). We also can't easily identify the results of issuing arbitrary requests of our interface implementations. Because we can't identify a particular invocation explicitly, we can't determine whether a request has been processed already and whether it needs to be done again. Imagine a complicated XSL Transformation (XSLT) being applied to a document, or issuing a database query for a particular customer, or invoking a SOAP Web service. Sure, our implementations can cache at each level, but that becomes a nontrivial amount of work, and we lack the visibility behind the scenes to cache what is most useful to cache. There is no opportunity to optimize across these caches based on how the system is being used.

Objects do have their place in our software strategies, but there is room to consider other ways of building modern systems.

  • Print
  • Feedback

Resources

More from JavaWorld