Wednesday, November 12, 2008

[Arch] RESTful applications with NetKernel

The architectural style REST has gained some popularity and is often brought up against SOAP for interoperable web services. REST stands for Representational State Transfer and has some characteristics that distinct itself from other architectural styles:
  • Resources such as a person, an order, or a collection of the ten most recent stock quotes are identified by a (not necessary unique) URL.
  • Requests for a resource return a representation of the resource (eg. an html page describing the person) rather than an Object that IS the resource. A resource representation represents the current state of the resource and as such is immutable.
  • Representations contain typically links to other resources, so that the application can be discovered interactively.
  • There is typically a fixed and rather limited set of actions that can be called upon resources to retrieve or manipulate them. HTTP is the best known example of a RESTful system and defines eg. GET, PUT, POST and DELETE actions.
Applications based on REST are typically very extensible, provide good caching support, and can be easily mashed up to bigger applications.

NetKernel

Using the RESTful application pattern in non web based applications is currently not very well supported by programming languages and frameworks. NetKernel is an open source framework designed to provide a simple to use environment to program RESTful applications.

Its architecture is rather simple: Programmers write Modules and register them with the kernel. Each module registers its address space that that states which logical addresses (URIs) the module will handle and which java class, script (Python, JavaScript, Groovy, …), or static resource will act upon the request and return a resource representation. A module can also register rewrite rules that translate from one address to another.

Accessing resources within NetKernel from outside is via Transports. Each module can have Transports that monitor for external system events (eg. JMS events, HTTP requests, CRON events, etc), translate these events into NetKernel requests, and place these requests into the NetKernels infrastructure that will route the request to the appropriate resource.

NetKernel supports a wide range of scripting languages uses resource representation caching to speed things up transparently for the developer. The internal request-response dispatching is done asynchronously so callers can easily state that they do not care for an answer after 10 seconds, are not interested in the response at all, or place several request first and then wait for the responses coming back. REST is most often associated with HTTP – with NetKernel one can apply the REST architecture style also to applications that do not use http; it is completely decoupled from the http stack.

Compared to other REST frameworks such as Restlet, NetKernel is extremely well documented and several large sample applications can be downloaded from their homepage to get started quickly.

Related Links
  • http://www.1060.org – the homepage of net kernel.
  • A recent article on TheServerSide.com about resource oriented computing with NetKernel that provide a more thorough introduction.
Benedikt Eckhard (edited by Alexander Schatten)

Sunday, November 02, 2008

[Arch] Mule 2 and Beyond

For anybody who doesn't know the Open Source ESB Mule, I can recommend the presentation from Ross Mason hold on the Java Polis conference. In this presentation Ross gives an overview about Mule, including the component architecture and new features in Mule 2. Other relevant topics are:
  • Develop services in Mule
  • Dealing with web services in Mule
  • Exception strategies
  • Transaction Management
  • Scalability
  • Projects around Mule: Mule HQ and Mule IDE
He also points to the projects on MuleForge, which provides Mule users interesting enhancement modules and connectors, like LDAP or SAP.