Newsletter sign-up

View all newsletters

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

REST for Java developers, Part 3: NetKernel

A next-generation environment where SOA meets multicore

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

NetKernel is a URI-based microkernel environment that combines the best concepts from REST, Unix, and service-oriented architecture to build extremely productive, scalable, and maintainable systems. NetKernel not only makes it easy to build RESTful systems in Java and other languages that run on the JVM; it also changes the way you think about tying components together.

So far this series has given you an introduction to REST and a quick walk-through of Restlet, an API that makes it easier to build and consume RESTful interfaces in Java. You have seen that REST is only partially about URLs. At a deeper level, it is about logically connected components, late-binding resolution of representation, and linkage between related information resources. With all of this, you ought to feel that you know enough to successfully combine REST and Java; in fact, you do. But the story doesn't end there.

In this article, you will learn about NetKernel, a next-generation software environment that mixes what people like about REST, Unix pipes and filters, and service-oriented architecture (SOA). Not only can NetKernel make you more productive, but the abstractions also allow you to fully use modern, multicore, multi-CPU systems with little to no effort. At a minimum, if you understand NetKernel, you will understand REST at a deeper level.

Clashing abstractions and excessive coupling

The software industry has made great progress over the years, but there's still work to do. The clash of abstractions and excessive coupling between components remain some of the biggest problems needing to be solved. Countless efforts have been made in the object-oriented world to address the issue with interfaces, the Law of Demeter, separation of concerns, dependency injection, design patterns, remoting abstractions, interface definition languages, SOAs, and so on. At the end of the day, however, objects end up feeling like the wrong level of abstraction to bridge the worlds of software components, data, services, and concepts. They are fragile and break easily in the face of inevitable change. Modern languages like Ruby, Groovy, Scala, and Clojure can help, but at some point it feels like any language or object binding is too specific for all needs.

It is certainly possible to build good, running systems with the object-oriented mindset, but as requirements and technologies change, these systems become crufty and hard to maintain. Organizations end up committing to a combination of technologies and sticking with them. They settle on a particular language, a particular data model, a particular database schema, and a particular platform. Sure, you can change any one or more of these commitments over time, but it's still painful to do. This strategy of picking a small set of technologies can help minimize variance, and maintenance and training costs, but it also often prevents you from using the right tool for the job.

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.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.