NetKernel News Volume 1 Issue 33

June 18th 2010

What's new this week?

• Updates to layer0, standard-module, http-server (again!), rdf-jena.
• New runtime for Apache Ant.
• How Domain Driven Design (DDD) relates to Resource Oriented Computing.
• NetKernel at Semantic Technologies 2010.
• Announcing @netkernel twitter channel.

Repository Updates

• tpt-http
  • fix of encoding of redirects
  • fix corner case of over-aggressive caching of query params

• nkse-dev-tools
  • fix of new module wizard to tidy test space

• standard-module
  • allow transport base class to expose logical endpoints

• cron
  • fix to allow shutdown to proceed more expediently

• layer0
  • fix to identifier escaping when last char was escaped
  • fix to regex rewriter to allow for newlines in identifiers

• doc-content
• documented protocol handler - allows 3rd party technologies that use URLConnections to issue requests into NetKernel address spaces

• rdf-jena
  • updated documentation to new consistent reference style
  • added mime types to serializers

*New* Apache Ant Runtime

One of the pieces we're working on before finally declaring NKEE complete is a tool that will bundle up a NetKernel installation and make it embeddable within an existing servlet container. We are also thinking about a tool to create an executable Jar of an NK system image (essentially rolling NK back up into the same form as when NetKernel is distributed in its own "live-CD", but with your application image pre-installed).

To do these sorts of tools requires lots of file manipulation. So rather then reinvent the wheel we've created an active:ant runtime that executes Ant scripts. Ant doesn't understand anything other than the host operating system's file system therefore the runtime detects if the script is a file: URI (which is run directly by Ant and all relevative files are resolved with respect to this). If the script is not a file (for example, its fetched using the http client accessors or is dynamically generated in a process), then the runtime will serialize the script to a temporary file which ant is then told to execute (in this case relative stuff will almost certainly not be good!). So bear this in mind when using relative addressing inside the Ant script.

To give it a try use Apposite to sync with the repositories and look for 'apache-ant'.

How DDD relates to ROC

Last week I was at the Skillsmatter DDD Exchange. Its clear that the DDD thought leaders share a common view of the world as we ROCers. I thought I'd capture some quick notes on where we overlap (and hint at what lies beyond DDD in the world of ROC).

Domain Driven Design has a core set of concepts:

Domain:

    The subject area of interest (the business domain).

Model:

    A system that represents a solution space for the domain problem.

Context:

    The language and vocabulary in which the solution is expressed

These core concepts are applied using software building blocks...

    entities
    value objects
    services
    domain events
    aggregates
    modules

Essentially DDD solutions are built and implemented using classical object oriented techniques.

Ultimately the goal of DDD is to break the tyranny of dogmatic brittle architecture by pragmatically allowing the real world business domain to inform the architectural structure of the solution. A classic example, reiterated frequently, is that business logic cannot be applied at a central physical layer - it necessarily spans data, middle and client layers.

Its very clear that the core set of concepts (domain, model, context) are common with ROC. Indeed ROC takes the concept of context and brings it to life as a living boundary condition within which any system executes.

DDD recognizes that there is no "one-size-fits-all" model. Indeed it encourages the discovery and pragmatic adoption of models. This is very much in line with ROC in which it is a fundamental axiom that any information has any number of identifiers and representations (value objects).

DDD encourages immutable DTO's. ROC requires that representational state be immutable.

DDD encourages service based models. ROC models all information transformations as services, indeed any resource request is resolved to an implementing service.

DDD says that layers and tiers are not the same thing and that physically partitioning must not restrict the logical model of the solution. ROC and the address spaces take this to the limit and say that architecture is not even restricted to 2 dimensional structures but can be layered with vertical resource channels. ROC spaces make arbitrary and appropriate architectural structures to be deployed - most importantly they can exist concurrently within one solution and one space may be used in any number of appropriate locations. (In the limit and if required, ROC allows this aspect of DDD to be taken to the limit, with dynamically composed architecture based upon application state).

DDD suggests that "aggregates" are a flexible way to cope with the natural multi-dimensionality of real world information values. ROC recognizes that the part-whole duality is intrinsic to the nature of information and as a direct consequence that systems naturally evolve through composition and the accumulation of composite state. Indeed often these composite resources include links to other resource which become relevant and useful in the context of the recipient of the request (cf HTML, links, img and css in the context of a browser render engine).

DDD naturally suggests that separating read and write sides of the architecture offers best architectural value. ROC recognizes that read-side state transfer is naturally partitioned and separate from write state transfer.

So are DDD and ROC the same thing? Not quite. While the world view is very similar, and the modelling and mental process of considering architecture are both motivated to overcome the innate brittleness of OO architectural orthodoxy. DDD remains within the OO paradigm, its building blocks and patterns and the approach to adopting DDD are innately OO-centric.

ROC says, there is world that lies above OO, a world in which the building blocks are:

    resources
    identifiers
    spaces
    requests
    endpoints
    representations

These building blocks give us first order control over the architectural structure of our solution. We can model the domain, create spaces that embody the contextual information boundaries and dynamically compose solutions at a larger scale than DDD-OO. (Of course within endpoints etc we also descend to the level of OO - and existing OO DTO's etc are not excluded).

Furthermore ROC introduces whole new systemic qualities, state normalization via systemic memoization (caching everything). Threadless scaling and multi-core concurrency.

Finally, DDD remains a localized internal approach to architecture. ROC (with the NK protocol (NKP)) allows the abstraction and ROC building blocks to seamlessly span servers - to offer a true DDD/ROC cloud architecture.

In ROC we talk about the 3C's. Construct, Compose and Constrain. I believe DDD has the same 3C's - however by implementing with OO they are in danger of always having the "C of Constraint" grabbing hold too soon. ROC lets you play with the architecture using construction and composition and offers the ability to explore and solve problems without the tyranny of pre-constraint.

Semantic Technologies 2010

Next week we'll be back over in SFO again, attending and exhibiting NK and ROC at the Semantic Technologies 2010 conference...

http://semtech2010.semanticuniverse.com/

As you know NetKernel is general purpose and horizontal, in the NK world view, "Semantic Technology" is a system oriented around a specific "semantic" resource model consisting of data models and process tools (such as the rdf-jena library in the repos). Over the years there has been a growing number of projects using NK as the platform for SemTech projects. Notably the Semantic Universe is using NetKernel to power the conference's own Linked Data services...

http://data.semanticuniverse.com/

We're planning to show how NK makes a great foundation for Semantic applications, and in particular real world solutions, having the ability to integrate and converge diverse heterogeneous resource models not just strictly "Semantic Technologies".

If you are at the conference and discussing NK/ROC please use our conference hashtag #nkst2010

Whether you're at the conference, or around the Bay Area, give us a ping it would be great to meet up.

NetKernel @ UberConf

NetKernel was very well represented at Uber Conf this week in Denver. Brian Sletten gave a comprehensive work shop "NetKernel - Software for the 21st Century" that covered more ground in 3 hours than I thought possible. Reports are that audience reaction was excellent, though there had to be a break for nose bleeds before the Q&A.

http://uberconf.com/topics/introduction_to_netkernel___software_for_the_21st_century

Not to be outdone Jeremy Deane went in for the kill with *four* different presentations - essentially covering arcitectural subjects but with implementation details on NK.

http://uberconf.com/conference/speaker/jeremy_deane

If you were at UberConf and have recently started playing with NetKernel and would like a helping and and support getting going then ping me and we'll set up a Webinar boot camp on using the tools and getting oriented with Resource Oriented development techniques.

@netkernel Twitter Channel

If your a twitter user, we've set up a @netkernel twitter channel which is for low noise, high value announcements such as notices of repository updates and releases etc. For day to day and general NK/ROC stuff I'm still on @pjr1060

Finally, FYI, these newsletters get archived on http://www.1060.org/forum/index/3 about one week after they go out to this mailing list.

Enjoy the weekend.