NetKernel News Volume 6 Issue 4

March 27th 2015

• Repository Updates
• HTTP Client TLS v1.2
• Tony's Blog: Gödel Alone Knows
• On Software Fortresses

Repository Updates

//Test TLS client capabilities
s="https://www.howsmyssl.com/a/check"
rep=context.source(s, String.class)
context.createResponseFrom(rep).setMimeType("text/plain")           

In a dramatic move that risks damaging his reputation as the "practical one in the 1060 Research team who actually makes stuff", Tony has started a series of articles that explains how ROC traces its history back to the fundamental mathematics of Gödel numbering...

History of Gödel Numbering - Part 1

History of Gödel Numbering - Part 2

I know for a fact that there's a third part in draft since he's determined to shame me by actually completing a series of articles once he's started it!

Tony is able to risk this flirtation with academia, since he knows full well that he can restore his reputation any time by publicly unveiling another killer bit of IoT electronic device engineering he's put together. Watch this space...

A month or so back, I was in a conversation introducing ROC to Paul Worrall founder of Interition. Paul has a deep background in enterprise architecture in the financial sector - he's got some very cool ideas/solutions on how to solve a critical banking problem: how to know who actually wrote your software (the problem of software provenance) and what it is doing - questions that are increasingly becoming a regulatory compliance requirement.

We rapidly dug into some of the standard ROC patterns and how they relate to security (for example the Trusted Notary demo).

Next day Paul explained that, after seeing the ROC patterns, his head had been full of ideas - he told me I needed to read a book called Software Fortresses and explained that the Software Fortress pattern is regarded as the ideal by a number of banks.

The problem, as he explained, is that it is very hard to actually get right when your building blocks are objects and low-level Java code. In fact, in his experience, even with all the resources that a Bank can apply to the problem, the ideal never makes it to reality.

When I got hold of my copy of the book, I quickly understood why Paul was excited.

The software fortress pattern is very simple. It consists of a walled fortification within which a given business function resides. Access to the business function is only possible by sending a message to a Guard acting as the Fortress gatekeeper. The Guard accepts (or rejects) the message and, crucially, translates the message into an approved, validated trusted inner message.

The business function within the Fortress is not interacting with an untrusted external party - it is simply satisfying an approved trusted request from the Guard. The Guard acts as a trust broker.

Here's what it look like pictorially, the book takes its time to justify this, but the diagram is really all you need to understand the pattern...

Anything look familiar? What about this...

The Software Fortress is a specific instance of the general ROC/NetKernel Overlay pattern. In fact we call the Software Fortress pattern the GateKeeper Pattern (discussed in our overlay patterns book, with a worked example in the wiki tutorial - Ironically you were permitted to view this page by that very same GateKeeper since this wiki is contained within its own Software Fortress!).

NetKernel comes with literally dozens of embodiments of Overlay. The mapper, the throttle, the pluggable overlay, the HTTPBridge, etc etc. There is even a standard base class StandardOverlayImpl in NKF to easily create your own.

And since Overlays are just ROC spacial patterns, we can compose them and evolve them with no brittleness and without any side-effects on the encapsulated business functions.

So now I see why Paul couldn't sleep that night. ROC makes turning the Software Fortress ideal into a practical and easily accomplished reality.

DrawBridge / Reliable Messaging Prelude

I didn't elaborate on the role of the drawbridge in the discussion above. In the book, the drawbridge is assumed to be a reliable messaging infrastructure such as MQSeries and the like.

This got me thinking, if we know that the ROC abstraction dramatically simplifies complex N-Party interactions - such as we show in the Trusted Notary demo - what would a full ROC Reliable Messaging solution look like???

So I've set myself a challenge to build it. I may crash and burn, but in the style of the TicTacToe series, next time I'll try to explain how to think about and build a solution to this problem the ROC way...