NetKernel News Volume 6 Issue 10

October 9th 2015

• Repository Updates
• NetKernel Gradle Plugin Tutorials
• Productivity Measurement
• REST API Tooling Released + Now with RAML Support
• muCon - Stockholm / London November, Ticket Giveaway

Repository Updates

I'm very pleased to announce that Mircea Cocosila of Neodonis Software has written a series of tutorials that share his experience of using the NetKernel Gradle plugin on large scale multi-project builds.

The tutorials are an ongoing series, starting with links to the history of the development of the tool and its reference docs.

• Part 1 - Introduction
• Part 2 - Centralize Plugin Configuration
• Part 3 - Reusable Shared Configuration

He has also committed updates to the various test case examples in the plugin's source github project..

• Examples

Excellent work Mircea - thank you!

If you have any tips or advice on tools etc - even just small things - please let me know and we'll put it out. Its great to build up the collective community knowledge.

My good friend Tom Gilb, the father of Agile, has forgotten more about software engineering than we will ever know.

One very wise saying he is famous for is:

"You must measure everything about your system. If you don't measure it how can you tell if you're making it better?'".

His Architecture Engineering course essentially distils down to teaching how you can measure almost anything you care to think about - all you have to do is give it a little thought and remember to measure (or even just estimate) the change.

Last time I announced that there is a new tool for providing statistics about your spaces, modules and endpoints. Two weeks ago my stats looked like this..

null : null
	statistics : null
		spaces : 905
		modules : 228
		physicalEndpoints : 3411
		logicalEndpoints : 3773

So I followed Tom's advice and measured again today...

null : null
	statistics : null
		spaces : 921
		modules : 231
		physicalEndpoints : 3457
		logicalEndpoints : 3826

I've added 16 spaces, 4 modules and 53 logical endpoints.

To put that into context, if I'd been working everyday on adding stuff to my ROC system that would be about 2 modules a week and nearly 4 microservices a day. However in reality I spent about two days actually doing tech stuff - so the real stats are more like 26 microservices a day.

Of course, as Mr Butterfield just said when I told him these numbers, yeah but how do I know if you did anything of any quality?

Well you can decide. See the next article for details...

Last time we put out a preview release of a module for REST API development using Swagger. In the repositories today you'll find an official release of rest-api-swagger with a fully updated implementation of the active:swaggerParser which now uses the latest 1.0.10 parser library. It has been slimmed down from nearly 30MB (that one module was larger than the whole of the NK distribution!) to just 5MB by removing a ton of extraneous libraries to focus on just the core runtime dependencies.

In addition, as hinted last time, we now also have RAML support and have implemented an equivalent active:ramlParser to provide parity with the Swagger tools. The RAML parser is ready and officially released as package rest-api-raml.

With both tools we took some time to tune the generated Mapper configuration so that it can be simply dropped in and will give a ready to use API mapping. So we're pretty close to plug-and-play REST API development.

RESTOverlay Enhancements

Its notable that the REST API world permits the idea that one endpoint is allowed to produce multiple representations - sort of a multiplexed view of the content negotation resolution.

In ROC its preferable and quite simple to create a normalized demultiplexed interface such that every distinct representation is a unique resource and so gets a unique cache entry. In ROC there's no need for complex cache control directives such as HTTP's Vary response header.

However, we'll change the world one step at a time - and that battle is not worth fighting now.

So to be pragmatic we also did a significant update to the RESTOverlay (released as an update to tpt-http in the repos) so that it now supports multiple <produces> tags for a single endpoint.

The RESTOverlay will now perform content negotiation and route requests to your endpoint if it promises to produce an acceptable type for the external HTTP request (via weighted Accept type resolution). However, rather than leave your endpoint to have to figure out what content type it's supposed to produce, we now add an argument to the inner RESTOverlay request to your endpoint like this...

+requiredMime@...

So if you have multiple <produces> tags you need to be sure to have a grammar for your endpoint that expects the requiredMime argument. Something like this...

With this in place, your endpoint can source requiredMime like this...

mustProduceMime=source("arg:requiredMime")

to be told which mimetype it should use for its representation.

There is something very beautiful here, in that the requiredMime argument is passed-by-value and so creates a contextual injected PBV space into the request scope (see Push Pull Inversion discussion for details). It follows that even though the request to your endpoint has an identical identifier, it will have a unique scope for each type. It follows that we can therefore cache each representation uniquely without any cache control directives to explain why the representation may vary by header selections.

In short, we managed to come up with a normalized demultiplexed ROC solution even though REST and the REST API tools are trying to make it multiplexed!!

Incidentally, the RESTOverlay now also works out which headers were used in the ROC demux algorithm and sets an appropriate HTTP Vary header for any external REST cache that might be intermediating the external HTTP requests and needs to do its own form of demuxing its cache. (Thanks to Brian Sletten for pointing out this requirement.)

Interactive API Tools

Finally both of the REST API tooling modules provide relevant documentation (Swagger, RAML), but perhaps most usefully both now provide a development utility that lets you interactively generate Mapper configurations from RAML or Swagger respectively.

After install these tools automatically appear in the Developer control panel.

Here's what the RAML tool looks like...

I shall be speaking at the Skillsmatter muCon conferences in Stockholm and London at the beginning of November.

The abstract for my talk is...

MicroWebs and NanoServices: an Introduction to Resource Oriented Computing

Microservices allow us to adopt composite architectures in which the value of the composite is greater than the sum of the parts. Compositional solutions have a long tradition and are a core element of the Unix philosophy.

Through REST we now understand that the Web is a Resource Oriented Architecture. So perhaps we should think of microservices in terms of "microresources"?

In this talk we will introduce Resource Oriented Computing, a general abstraction for software in which "everything is a resource". ROC solutions are built by composing resources from nanoservice endpoints located in "microweb" spaces. Evovable highly scaled, ultra-high performance solutions are created by the scale-invariant composition of "microwebs". Resources all the way down, or if you prefer, microservices, nanoservices, femtoservices all the way down...

Stockholm Ticket

I have a spare ticket for the Stockholm event worth Kr5000 (€500). If you'd like to come along to the full conference and can make it to Stockholm please drop me a line. If we have more than one taker we'll write a special active:ticketLottery endpoint and let NetKernel pick the winner!

Closing date for entries will be next Friday 16th October to ensure the winner has time to make plans.