NetKernel News Volume 3 Issue 41

October 12th 2012

What's new this week?

• Repository Updates
• Resource Oriented Analysis and Design - Part 8
• Edge State To The Limit
• What about two players in different places?
• Process

Catch up on last week's news here

Repository Updates

The following update is available in the NKEE and NKSE repositories...

• lang-groovy 1.12.1
  • Eliminated a potential very rare race condition in the GroovyTransreptor (compiler)

The following update is available in the NKEE repository...

• nkp 1.13.1
  • Fixed potential contention that may have occurred during initialisation of NKP-Load-Balancer clients.

Resource Oriented Analysis and Design - Part 8

Last in a series of articles taking a well understood domain problem and casting it as an ROC solution.

• Part 1, Part 2, Part 3, Part 4
• Part 5, Part 6, Part 7

This is the final part of this series. Now that we've implemented a solution its time to step away from the details of the problem that has been addressed and to examine the patterns, the working methodology and perhaps to extrapolate from this simple problem to bigger and more grand systems.

First though, I want to consider some feedback and questions that have come up from people following the articles...

Edge State To The Limit

Around about Part 3, Steve Cameron in Tasmania got in touch with a very good observation. He suggested that an alternative approach for the WWW application was for all of the state to reside either entirely-client side or entirely server-side. With a full representation of the state transfered with each interaction.

He has also provided an implemention of a version of the game using an XForm to show this pattern, with his comment below...

http://collinta.com.au/xsltforms/0&X.xml

Here's my reply, which was sent before I started work on normalising and constraining of the solution...

I guess the most important thing to emphasise about this series is that it was never the intention to write a Web-application.

We built a web-application rendering layer just simply because it happens to be a useful and common way to expose the design requirements and to offer an implementation.

I think you can see that by the end, the services, and in particular the move endpoint have been abstracted from HTTP and could be used and exposed to other transports with different renderings (for example, you could imagine playing a 19th century style of game via sedate email correspondence, "Dear Mr Darcy, I play an X in cell c:1:2. It is my earnest wish that you might expedite a reply forthwith. Your Humble Servant, ..."

What about two players in different places?

Earlier this week Matt Pearce at Cognizant raised another good question. How would we extrapolate last week's closing section on the migration and dynamic generation of the pds configuration state in the contextual application, so that two users could play a single game from two separate locations?

Returning back to the ROC modelling of Part 1...

With Matt's requirement we would have to introduce an additional abstract resource: "Game". We might call it active:game+id@foo.

As with implementing the atomic cell resources, we'd follow a similar architecture, we'd create a new module for the game resources and import this abstracted game resource model into the www tier (more on which below).

To solve Matt's requirement our pds configuration resource would therefore need to be generated with a unique zone for each Game resource.

If we were cunning about it, then we'd use the same abstraction technique as in the use of the HTTP parameter. We wouldn't hard code the pds: zone generation to request active:game+id@foo. Instead we would configure the space with an endpoint that provided a contextual game resource active:currentGame

So now, for two people to participate in the same game all that is required is that they would each share the same context for the identity of the game resource.

User/Game Context

To achieve this, each player would now need to provide some state such that there was a context to enable us to determine which one was currently playing and furthermore to use this to determine the game in which they are participating.

In a web-application there are two ways to do this. The most common is to use a cookie and a correlated session (which with NK we can easily do by wrapping our application with the session overlay). The other is to have the user go through an initialisation phase where an identifying token is provided to them and stored in the client-side - in this latter case the AJAX code would need to qualify a move request with the user token too.

The active:currentGame resource would provide correlation between user token (or session state) and game identifier.

My inclination would be to implement this "user correlation" tier in a new module that would sit above the existing core www-module. Since the existing services are completely unaffected by Matt's new context. The user-game correlation layer would therefore play the role of contextualizing requests to the existing www game implementation.

Token State

It follows that a similar analysis and design is required to deal with the "token-correlation problem". That is, we must ensure that each person is playing the correct piece in the correct order.

Its pretty simple to sense that it would need a new set of resources active:userToken+user@foo for which we'll assume the state is established during the game initialisation.

Interestingly, based on Steve's comment, this requirement can be seen as the migration of the state management of the move token from the client-side to the server-side (remember our AJAX code was previously managing this). In addition the requirement that we enforce the order in which users can play their turn also tends to favour the token state on the server-side (but not in the middle!) - though of course with a cunning token counting/coding scheme you could leave it on both client-sides.

Anyway, since we now know the user, and have a set of resources that tell us which token they must be playing, therefore we no longer need to hold that state on the client-side.

However, with this change we would be required to change last week's abstracted active:safeStateParam so that it would instead point to the new "contextual user token". Easy, we just change the state argument refering to the http parameter httpRequest:/param/state like this...

And of course we'd then have to abstract the call to active:userToken+user@... to one called active:currentUserToken with the user argument being resource reference to a user-correlation resource from the user-correlation layer.

And so it goes...

Process

The section above is an attempt to show how the existing game could be progressively evolved. Essentially, the process discussed is exactly the same as any of the other implementations discussed in the series...

Its the four steps.

1. What have a I promised?
2. What do I need?
3. Add value
4. Respond

In the analysis undertaken to solve Matt's question I start with "I am promising a unique pds configuration for each game". I then ask "What do I need to do this". Which then leads to the revealing of the necessary services (each of which then has its own 4 step process).

You can see that to actually solve this problem for real I would introduce scaffolding resources (like the dummy resource in the early stage of developing the cell atoms). I don't have to bite off the whole problem - I can implement each resource independently and allow the interactions to emerge and be made dynamic in a progressive way.

This implementation process and more particularly Matt's new requirement are both aspects of the same thing.

We have been on a journey throughout the implementation of our solution in which we have progressively evolved it by introducing contextual layering.

This a very natural evolutionary process in ROC solutions and it comes back to something I said way back.

If you can remember back to part 2 I said imagine that an empty space contains all the resources - development is reducing the potential set down to a set that solves our problem.

The introduction of contextual layers is, just like defining endpoint grammars in a space, just another way to sculpt the set to satisfy our specification.

I was thinking this was going to be the final article, but I'm not quite done yet. Perhaps this is good point to pause. I'll offer some final thoughts next week...