In this article, Peter Rodgers discusses the 1060 NetKernel system, an open-source URI Request Scheduling Microkernel which provides the foundation for the 1060 NetKernel XML Application Server. NetKernel provides a Web operating system upon which Web apps can be developed which can in turn be used as the basis for Web-like XML-services, regardless of the chosen application protocol.
- Posted by: Nate Borg
- Posted on: March 16 2004 11:12 EST
Read 1060 NetKernel - A new Abstraction for Web-systems
- TSS Article: Introducing 1060 NetKernel by Gal Binyamini on March 16 2004 14:16 EST
- Interesting by Daniel Selman on March 17 2004 02:59 EST
- Interesting by Peter Rodgers on March 17 2004 04:32 EST
- Re: Interesting by Michael Jouravlev on March 17 2004 12:22 EST
- Errata by Peter Rodgers on March 17 2004 04:01 EST
- Executive Summary by Peter Rodgers on March 17 2004 12:42 EST
- Let me bite the bullet :) by Web Master on March 17 2004 12:48 EST
"Open source", "Microkernel", "XML Application Server", "Web operating system", "Web apps" "Web-like XML services". Is it just me or does this paragraph looks as if it was produced by an IT FUD generator? ;)
"Open source", "Microkernel", "XML Application Server", "Web operating system", "Web apps" "Web-like XML services". Is it just me or does this paragraph looks as if it was produced by an IT FUD generator? ;)GalKnowing some of the engineers involved and the impetus behind the ideas, I suspect they will have taken those (rather over-used) terms and produced an architecture and implementation that justifies using the terminology.
It is, of course, a separate issue as to whether the technology is useful to yourself or to anyone else.
I was really just referring to the description with all the buzzwords. I haven't had a chance to look at the system.
A very interesting article. Long, well written, and it defintely fits my world-view in many areas.
I'm not 100% convinced that XML as a programming mechanism (XSL etc.) is all that natural for many applications, but the versioning, addressing, declarative chaining, seperation of transport from processing aspects are well described. I think these issues are just as applicable to non-XML centric applications. XML forms a nice mechanism for module data interchange however, as it is used in many of the BPM/Integration tools.
It's a shame that we cannot experiment with this architecture within a J2EE application.
I think these issues are just as applicable to non-XML centric applications. XML forms a nice mechanism for module data interchange however, as it is used in many of the BPM/Integration tools.Totally Agree. We regard XML processing as simply an important application domain - the Kernel has absolutely no XML dependence. You could write a set of composable URI addressable services for image, PDF, CSV... processing if you wished.
Also, XML syntaxes for programming languages *are* horrible! We have used XML syntax for the high-level languages (DPML, XRL) since there seems to be potential value, in a declarative model, in enabling a process to dynamically generate another process.
We have a short-form DPML spec on the drawing board. Since a NetKernel language runtime is just a service that issues asynchronous requests for other services it's pretty simple to add a new language to the system.
It's a shame that we cannot experiment with this architecture within a J2EE application.You can. Out of the box NetKernel is a standalone app server, however it can also be deployed as a J2EE Servlet (supplied with the download) and may even be embedded in a Java app using it's Embedded API.
Can you give a brief (non-buzzword) description of what this does and and example of what it can be used for? Most of us don't have time to read long papers on technologies which may not apply to us.
Can you give a brief (non-buzzword) description of what this does and and example of what it can be used for? Most of us don't have time to read long papers on technologies which may not apply to us.Ok, so now we have to hire an admin to read and interpret articles for you?
I do not care much for the XML itself, I think XML shines when it is used together with XSL scripts. For me the greater value of this project is implementation of the REST concept. REST makes the famous "Net is the computer" come true in a very elegant way.
I just want to understand the licencing terms. Is it GPL or LGPL or something else? The licencing document on their site is sooooo boring.
I just want to understand the licencing terms. Is it GPL or LGPL or something else? The licencing document on their site is sooooo boring.When has a license ever not been boring?
NK is licensed under the 1060 Public License - which like the GPL is viral for distribution of, modifications to the Kernel and system components.
For *use* of the system it mandates OSI licensing, a quick summary is: NK is on the open-source commons, if you use it on the commons (ie open-source your application code) it's free, if you want to take it off the commons (ie keep your source closed) then you gotta pay. Unlike GPL we let you choose which OSI license you like best if you choose to open-source your application code.
Hopefully our license represents a business model that's fair to the OS community, fair value to the commercial world and means we get to feed those hungry kids I mentioned in the acknowledgement.
The License FAQ might help http://www.1060research.com/license/faq.html
Just spotted a small error that must have crept in during the TSS editorial process. In the DPML example most of the closing XML tags are missing - however this doesn't effect the gist of the example.
Also there's no link to the NetKernel download: http://www.1060.org/
OK here's a very brief executive summary:
NetKernel is microkernel that realises an abstraction of the Web. The abstraction allows any software component to present a Web-like URI interface. They may do this totally independently of any external application protocol (eg HTTP). NetKernel software components are URI addressable services but equally they can be web-clients into the address space. Components can be encapsulated in modules, a module may also present a set of URI interfaces. Since everything is based on URIs, modules can be combined into a virtual URI address space - ie NetKernel manages a Web of services. It also manages process scheduling, caching, module versioning, application protocol transports...
Why implement a Web abstraction? Because the web is proven as an excellent way to build systems. It is robust, adaptive to change, upgradeable, scalable, durable, composable...
Moving up to the application level, standard technologies (such as the XML technology set) can be exposed as URI addressable services. Moving up again language runtimes are provided which manage and issue requests onto the URI address space.
What can you do with this? Big question. You can create Web-applications, Web-services ... information systems of any kind - we assert that since NetKernel is intrinsically web-like then these systems reflect the proven properties of the Web. One application domain, though certainly not the only one, that benefits hugely from this is XML processing.
So sooner of later there will be a need to propagate soap-headerish informaiton from one xml-service to another. For instance caller identity assertions, reply-to field, or other headers that would help to implement varios message exchange patterns like reliable delivery. And this could happen over arbitrary transport (for instance SMTP is mentioned in the paper). Then you can imagine visual designer tools for DPML that will be aware of xml input/output shapes associated with URIs, and of those header-ish stuff that's needed for call.
So you might need to provide standard way to describe xml services, and standard way of propagating headers regardless of transport. Prety soon you are talking about creating your own version of WSDL and WS-*incomprehensible set of specs, so what's the point?
The alternative is to deliberately keep NetKernel at the infant level simplicity, in which case users will keep struggling to build required infrastructure themselves, or will only use NetKernel as XSLT engine on steroids.
What's wrong with this reasoning?
So sooner of later there will be a need to propagate soap-headerish informaiton from one xml-service to another.Good point. NK is entirely pragmatic about application protocols. If it makes sense to use SOAP and the WS-* stack then use them. If you want to write a REST web service its your choice.
WSDL is fine for describing any XML-service interface, not just SOAP - if a service exposed in a module needs to export a WSDL description there's nothing to stop it. Equally any service can send and receive SOAP-headers. These apply equally to publicly exported services over a transport or internal services in a module's URI address space.
At the lowest level the microkernel doesn't care about what you're up to in the application level - just the same as the Linux kernel doesn't care whether your using Gnome or KDE. So with this analogy the NetKernel XML App server is just a suite of replaceable/extendable libraries on top of the microkernel.
As a general observation. Our feeling is that with the XML-service world, the application must eventually handle the XML message no matter what the protocol. For many XML processing problems we've found that the later you bind to procedural objects the better - ie when you have the choice, keep your system loosly coupled.