|
|
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
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.
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.
Read the series:
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.