Tags / Resource Oriented Computing

Why Microservices and not Yoctoservices?

So we’ve heard a lot about microservices and there have been some good discussions comparing the benefits and disadvantages over the status quo of monolithic enterprise deployment. What is interesting me at the moment is the question of scale. When we break a monolith into parts we need to make choices of what those parts should be and inevitably how large they are. Mereology Mereology is the study of parts and wholes. [Read More]

Reducing Power Consumption with ROC

Two weeks ago I spent a couple of days in London attending an Architecture Engineering course at the BCS. Tom Gilb the course creator and teacher along with his son Kai demonstrated the power of an approach to thinking that extends much further than the course title suggests. By seeking to uncover all the variables and risks in any undertaking and then quantifying them, a project can make less subjective decisions through the entire path from conception, requirements gathering, design and implementation of systems. [Read More]

The Resource Oriented Architectural Style

I’ve been thinking a lot recently about how to model non-trivial Resource Oriented systems. It is interesting that each practitioner has a different style. Peter and I have discussed endlessly about our own approaches but failed to reach consensus about the best. (Ha! as if that would ever happen anyway.) However I think part of the reason is the sheer freedom that ROC offers. This of course has it’s advantages but one of the tradeoffs is that it can lead to choice overload. [Read More]


Brad Jones has his fingers on so many pulses that I imagine him beavering away in his leguminous clinic. So when he said to me last week that my last post would really help people familiar with REST to see what ROC was about it made me think. I realised that the aim was valid but that it wasn’t really well addressed despite Brad’s enthusiasm. So of course I better do something about that! [Read More]

ROC Concept Maps

Listening to the people I’ve spoken to this week then a picture may not be worth a thousand words. But those folks tend to prefer the command line over the GUI. If you’re in that camp you know where the source code to NetKernel is and you’ve probably read it. This post is for the rest. Following on from Essence of ROC I’ve decided to do a series of concept maps of the ROC principles. [Read More]

Essence of ROC

You might well have expected to see this confusing graphic1 to be from the NetKernel page on 1060research.com given the way we appear to be simultaneously teasing visitors with the promise of refreshing cool water of IT nirvana whilst blasting them with either technobable or mind twisting concepts (depending upon your level on cynicism.) This can act as a barrier to all but the persistent. I’ve recently spoken with quite a few people who have persevered and have told me their story, so in this entry I wanted to just reset things a bit and build up the story of what Resource Oriented Computing (ROC) is and why it’s worth the effort to understand. [Read More]

Modelling Injected Spaces

One of the enhancements to the ROC abstraction that was introduced with NetKernel 4 was the ability to dynamically inject address spaces into the scope of resource requests. In NetKernel 3 the scope was determined purely from the requestors scope and the resolution path through any space imports to the resolved endpoint. In NetKernel 4 this same basic approach is used but any endpoint can now inject new spaces into the scope before issuing a request. [Read More]

Resource Oriented Modelling Language

We are getting close the first anniversary of the NetKernel 4. With the release of Netkernel 4 finally we had the solid core ROC abstraction that we had always talked about. Along with the core abstraction came a metadata model which we haven’t really talked a lot about. Metadata means a lot of different things to different people so just to be clear, what I’m talking about here is the system state that is generated and captured by the core NetKernel infrastructure of the kernel in combination with standard modules. [Read More]

Separating Architecture from Code

The MP3 format is a great technology for compressing audio because it can be progressively configured to reduce the complexity in an audio stream in the parts that humans are less able to perceive. It understands the psycho-acoustics of human hearing and the typical waveforms that constitute music. By working in a constrained domain it can represent the data in a more concentrated form. Similarly JPEG is a great technology for compressing photographs because it can reduce the complexity in parts of an image that humans are less able to perceive. [Read More]

Where's the API? Where's the code?

These are common questions levelled at NetKernel and the systems developing using NetKernel. They reveal a mismatch of expectations which is caused by a fundamental difference in the structure of software using the Resource Oriented Computing (ROC) abstraction upon which NetKernel is based. In the closing remarks of a previous post I mentioned that ROC liberates systems from being implemented in a single language by virtue of the fact that the ROC middleware acts as an integration platform for different programming languages and technologies. [Read More]