1060 NetKernel: virtual Internet operating system, XML runtime

Discussions

News: 1060 NetKernel: virtual Internet operating system, XML runtime

  1. 1060 NetKernel is a new virtual Internet operating system running on a Java virtual machine. Based on a microkernel architecture it provides a REST* abstraction for creating applications that seamlessly integrate with the Internet. It features a fully pluggable, transport independent, universal resource infrastructure and dependency-based cache.

    An XML runtime is included which enables powerful XML processes and applications. XML Pipelines and declarative scripts can be created with the advanced features of conditionals, iterations and nested exception handling. All standard XML technologies are integrated out-of-the-box including XSLT, compiled XSLT, XQuery, XSL-FO, XML index/search, XPointer, XPath, XInclude, Relax NG, XSchema, Schematron, DTD, XPath, XML Signature, XACML... plus some brand new XML technologies such as Declarative Processing Markup Language (DPML) and Simple Tree Manipulation (STM) language...

    NetKernel modules execute within a fully protected environment with a publicly exposed vs. privately addressable URI and classpath space. Modules are versionable as are their imported dependant modules.

    NetKernel has a highly optimized dependency-based cache architecture where each resource's validity might depend upon a hierarchy of other resources used in its creation.

    NetKernel's Representation-Aspect-Transrepresentation (RAT) model ensures resources are automatically and transparently available just-in-time in the correct in-memory forms. This is most important in the XML domain where documents can be represented as unparsed character streams, DOM, SAX and many other alternate APIs. It is also useful for many other resource types such as images or database result sets.

    NetKernel can be deployed as a standalone server, incorporated into a J2EE application server as a servlet, linked as a co-processor into an application or used in shell scripts as an executable.

    NetKernel is transport independent. v2.0.7 ships with HTTP and telnet transports. Mail and BEEP transports are available. New transports can be easily added.

    NetKernel is fully documented, provides numerous interactive demos, applications, development tools, tutorials and example code. Full text search is available.

    New features in v2.0.7 include a developer friendly installation with fully tooled XML workbench, updated development tools, support for accessing CGI and PHP, and supports running in a J2EE application server.

    Also included is a new standalone XPath Document API (XDA) that provides a clean XPath based approach to procedural XML processing in Java. It features iterators, full namespace support, separate read and write interfaces. By using XPath locations into an XML document XDA is a highly productive compromise between declarative XSLT and using low-level APIs such as DOM.

    NetKernel provides a new infrastructural technology for service oriented architectures, it is independent of J2EE and servlets though can be used as an embedded servlet component. It's clean distinction between declarative processes and componentized procedural business logic enables very flexible and highly maintainable applications to be developed.

    Please take a look and let us know what you think. We really appreciate all feedback ...

    1060 NetKernel is open-sourced under the 1060 Public License. It is available for immediate download from http://www.1060.org

    Further information including background on the initial origins at Hewlett-Packard, support and commercial licensing at http://www.1060research.com

    *The REST architecture, formalized by Roy T. Fielding in his thesis, describing why the web is so effective.

    Threaded Messages (10)

  2. Please take a look and let us know what you think. We really appreciate all

    > feedback ..

      Allow me to add two comments:

      1) Somehow you seemed to have missed out on XUL (XML UI Language). To get started with XUL you might wonna check out the XUL Alliance Link-opida.

      2) Have you heard about the Golden Hammer Anti-Pattern?

      May I quote from my VanX The Future of Web talk slide titled "XML is not ... / The "Golden Hammer" Fallacy":

     When you have a hammer in your hand, everything starts to look like a nail.

      Don't get swamped away in the XML craze. XML has limits and is not the magic bullet that will solve everything from world hunger, to peace in the Middle East to folding your laundry and cleaning your carpet.

     * XML is not a scripting language --> choose Python
     * XML is not a heavy-duty programming language --> choose Java, C#, Shark
     * XML is not a style-sheet language --> choose CSS
  3. XML does have a place, however[ Go to top ]

    XML may not be the sole place for everything (I'm an old prolog hacker, so I know how things can really be done :), but having played with NetKernel a bit (not in production), I think it could set a balance.

    Specifically, there are things whose role in the system is to normalise external data sources -HTTP, SMTP requests, databases, whatever- and make them look like XML structures, handling xpath and xpointer. A lot of the heavy lifting can be done here (in Java, not Python), in a way that is reusable. Imagine its like Ant -the tasks are in Java and reusable; the build files are simply declarative XML glue between the tasks.

    In NetKernel, you work in the XML space: everything is mapped to XML. Whereas in normal J2EE everything is mapped to Java objects. When you consider that EJB, JDBC, JDO, Castor, XMLBeans, SAX, DOM, StAX, JAX-RPC and many other projects are different ways to map data to objects, xml to objects and back, you have to wonder what is the right space to work in: object, database, prolog logic clauses, XML or something else.

    My recommendation would be try it and see. I dont think it is perfect for everything, but it may make a lot more sense than SOAP toolkits. (I say that as an apache Axis developer, BTW)

    -steve
  4. XML is the future[ Go to top ]

    Think about this:

    1) Most Web applications end up generating XML or XML-like markup
       (HTML, XHTML, WML, XUL, you name it) for the presentation layer.

    2) Most data can also be represented as markup (database result sets,
       documents exchanged between applications in general).

    3) New protocols are based on XML (SOAP).

    Using languages like python or Java as the glue between those worlds
    is arguably often a bad choice, because you either end up manipulating
    some sort of DOM in Java, which is very painful, or use some sort of
    XML <-> object mapping. The gap is similar to the object-relational
    chasm.

    So I can easily make the exact opposite point to Gerald's. Instead of
    Java an Python, use the adequate languages to process XML, and those
    are XSLT, XPath (and think the upcoming XSLT 2.0 and XPath 2.0 rather
    than the too limited 1.0 versions), XQuery, BPEL for orchestrating
    processes, and more.

    None of this precludes writing heavy logic in Java or any language you
    choose, and here I agree with Gerald. But if anything, Java developers
    today are under-using XML, not over-using it.

    XML platforms will take more and more importance, and it is exactly
    the way we are going with OXF and the upcoming OXF XML Application
    Server (http://www.orbeon.com/oxf/).

    -Erik
  5. XML is the future[ Go to top ]

    ...use the adequate languages to process XML, and those are XSLT, XPath (and think the upcoming XSLT 2.0 and XPath 2.0 rather than the too limited 1.0 versions), XQuery, BPEL for orchestrating processes, and more.

    Totally. The processing synergy is scorching. And NetKernel's choice of REST is great. I hope NetKernel is only the first of what I would call an "XML executive". I hope more folks recognize procedural as decrepit.
  6. All very interesting but...[ Go to top ]

    Suppose I am just a lowly java developer who doesn't stay up with all the latest buzzwords and technologies and stuff, just suppose, then I might be tempted to ask.... what's it for?

    The description has more jargon per square foot than I thought possible, but doesn't tell me why I might find this thing useful. This is a sales tactic that is only useful on senior management ;-)
  7. All very interesting but...[ Go to top ]

    Suppose I am just a lowly java developer who doesn't stay up with all the latest buzzwords and technologies and stuff, just suppose, then I might be tempted to ask.... what's it for?

    Data transformation, firewall tunneling, build scripting -- those are all cases where Java developers are increasingly using XML to reduce the amount of code they write. Web service is a concrete example of how Java developers are leaning very heavily on XML, with dialects such as WSDL and Ant. It also helps to think of the XML dialects as APIs. Ie, an application could easily use several dialects. There is the possibility that an application would benefit from an XML processing environment in much the same way that a JVM helps a Java program.

    The description has more jargon per square foot than I thought possible, but doesn't tell me why I might find this thing useful.

    To me the compelling technology in NetKernel is REST, an object oriented way to use HTTP. I doubt NetKernel would be worthy for an application that didn't use REST. And I'm fairly sure NetKernel would be almost useless for an application that didn't use HTTP -- maybe that's why NetKernel's value seems unclear to you.
  8. What's it for?[ Go to top ]

    These comments are very valid and highlight our inadequacies as marketing people.

    Thomas says: Suppose I am just a lowly java developer who doesn't stay up with all the latest buzzwords and technologies and stuff, just suppose, then I might be tempted to ask.... what's it for?

    This is a very big question and to answer it you need to try summarize what the web-services hype has all really been about and what gives data expressed in XML any more value than any other format.

    Web-services is really about the evolution of the Web from a content publishing application (Web-server/browser, linked HTML resources) to becoming a standard interface for IT systems. The promise of a standard interface is probably worth getting hyped up about but it can mean the technology wood is lost behind a particular variety of trees (SOAP).

    There are various technology models for how you implement a web-service interface - you can choose from SOAP, XML-RPC, PHP, CGI... The common factor however is that the interface is exposed in the URI-address-space. It is the URI (historically URL) address space that made the web scale and it is URI's that are really at the heart of the web-service technology hype. The URI truely *is* a Universal Resource Identifier, it may not be perfect but the URI is the thing that makes the web work and there's a huge diversity of infrastructure dedicated to URIs. A service exposed using URI's can tap the network effect of the infrastructure for free - this could never happen with Corba, COM+, JRPC etc etc

    Why is data expressed in XML more valueable than CSV, or whatever. XML is just a stupid data syntax. XML's power is not that it is particularly good, or the technologies for working with it are ideal. It's power derives from the network effects that expressing data in XML opens up. If my web-service consumes and emits XML there are more people can interact with it than if it produced CSV.

    NetKernel is an infrastructure for scheduling requests on the URI address space and abstracts REST away from it's HTTP origins. NetKernel's XML processing application set is a higher-level technology layer that runs on the NetKernel abstraction. Taken together NetKernel+XML let's you address services with URI's and, if the service uses XML, to handle and manipulate it any way you like. Of course all of this can be done with procedures but we find that for many XML-oriented middleware tasks it's easier to stay in the XML domain. NetKernel is modular and for those tasks that are best done procedurally you can place behind URI addressable service interfaces.

    So what's it for? It let's you provide and interact with URI addressable services with an abstraction that is backwards compatible to the web and forwards compatible to web-services whether expressed through SOAP, XML-RPC or plain-old REST technologies. On top of this the XML processing layer abstracts low-level API's and makes several generic XML processing technologies easy to use and combine. So what's it for? It's for publishing, invoking, combining and manipulating web-services (in the broadest sense).

    Brian says: To me the compelling technology in NetKernel is REST, an object oriented way to use HTTP. I doubt NetKernel would be worthy for an application that didn't use REST. And I'm fairly sure NetKernel would be almost useless for an application that didn't use HTTP -- maybe that's why NetKernel's value seems unclear to you.

    Certainly the current system appears to be biased towards REST over HTTP. But URI addressing of services is applicable to more than just HTTP transports. We use NK to provide SMS (Text message) management interfaces to our servers for example. We also run NK as a mail server. Something else we've not highlighted is the value of direct XML-to-SQL and back. Mapping between these two declarative domains without intermediate procedural steps is very efficient. Of course we've also built and invoked SOAP services.

    We're currently putting together the next release and will have more diverse examples.

    Thanks for the feedback so far.
  9. XML is not suitable for code[ Go to top ]

    The problem i have with the 'everything in XML' approach is
    that unlike Lisp s-expressions and other easily machine parseable
    data/code formats (that have been round for 35+ years), XML is just
    not a suitable format writing code in (declarative OR procedural!).
    A quick look at any large Cold fusion or XSLT code snippet will make
    most developers scream.

    Yes it's possible to represent all data and code in XML dialects,
    yes it's possible to write equivalents of all coding languages out
    there in XML dialects, yes it's possible to get some value from
    your code and data being in the same format (easy code generation
    etc), but these advantages have been available with Lisp for
    decades. Why learn all these 15+ XML technologies when I can write
    my application in ONE general purpose non-XML language such as
    Java/C/C++ or Lisp?
  10. The download link seems not working[ Go to top ]

    Tried a few locations but none of them works, a long slow waiting period after clicked on download and eventually failed.

    Cheers,
    John Yuan
  11. The download link seems not working[ Go to top ]

    Checked things out and everything seems to be fine. We've not had any other reports of difficulties. Perhaps you'd like to retry http://download.1060.org/

    Cheers