I have discovered NetKernel at a very late date and I played with it about half a day last weekend. These guys have taken uniform semantics to a new level. Every service, local or remote, is represented by a URI, and you compose services using a declarative * scripting language. You invoke verbs like SOURCE and SINK (analogous to GET and POST) on these URIs, and the kernel understands dependencies and can cache results intelligently.
You create your own services and map them to addresses in the URI namespace.
They also put a lot of emphasis on their available XML pipeline service, and if used properly, there's your engine of application state.
I hope this product can get some attention from REST architects. It's really a unique, REST friendly way to build services.
*My first brush with that language leaves two impressions: a) looks kind of procedural to me, and b) XML is really too verbose to use as a framework for scripting language.
Hugh Winkler holding forth on computing and the Web
Subscribe to:
Post Comments (Atom)
1 comment:
*My first brush with that language [DPML] leaves two impressions: a) looks kind of procedural to me, and b) XML is really too verbose to use as a framework for scripting language.You're right DPML is a very basic language. It is really a simple syntax for constructing NetKernel URI requests. The reason for having an XML syntax is that it accommodates dynamically generated code - not always a good pattern, but a valid option within a service-oriented development environment.
In NetKernel a language runtime is just another URI addressable RESTful service. Code is just state transfered to the runtime for execution. It's very simple to add new languages or custom workflows.
For example, we also provide a recursive XML inclusion language that invokes services during a recursive traversal of an XML document. This is a powerful way to build web-applications - in this case, a service can be considered as a micro-portlet, a web-page is then just the plan view of a dynamically populated tree.
Declarative languages seem to work well with XML processes but procedural languages have there own power. So we have a 'Posix-like' abstraction around the kernel which is consistently presented to a bunch of dynamic languages (Beanshell, Groovy, Java, Javascript, Python). These can be used to manage and invoke services and again each language runtime is simply just another service.
Post a Comment