NetKernel News Volume 2 Issue 2

October 29th 2010

What's new this week?

• Repository Updates
• Status Check
• HTTP Cookie Transreptors
• State Balancing Patterns

Catch up on last week's news here

Repository Updates

The following package is available in both NKEE and NKSE repositories...

• http-server 1.16.1
  • Adds new Cookie parse/serialize transreptors (see below)

Status Check

We're closing in on the general release of the new Space/Architecture Explorer tool. The tool offers navigation and integration of the architecture and metadata of a system, including a first graphical architecture visualisation - the static structure diagram. The tool is an extensible metadata visualization framework and can be extended with new views and data-overlays. It also provides a natural point for integrated cross-linking into several existing tools including documentation and search.

You may have noticed the repository update rate has been relatively quiet for a week or two. Due to the comprehensive interplay of the explorer with the existing tooling we've been adding enhancements to several packages. We're holding back on releasing these so that the whole composite tooling can be tested and pulled together as one coherent tooling refresh to coincide with the availability of the new explorer.

Watch this space...

HTTP Cookie Transreptors

The HTTP server package http-server has been updated with a matched pair of Transreptors to serialize and parse a javax.servlet.http.Cookie. Below there's a detailed discussion of an architectural pattern that seamlessly falls into place once Cookies are not constrained to being just javax.servlet POJO objects.

Of course, even if you're not interested in the discussed architecture below, you still might find it useful to have a cookie parser to generate a Cookie object representation from an HDS or XML representation if you ever need to.

State-Balancing Patterns

Why on earth would you want to serialize a cookie?

A cookie is a state bearing entity and is generally used to provide correlation and binding of an HTTP request with a server-side session. The diagram below shows a typical architecture for a session enabled "Web App" space.

You can review the ROC architecture book for a detailed discussion of this pattern.

Briefly the HTTPBridge overlay provides the normalized httpRequest:/ and httpResponse:/ resource spaces.

The Session Overlay wraps the Web App space and performs session correlation for each request entering the Web App. It is implemented to SOURCE httpRequest:/cookie/NETKERNELSESSION in order to determine the correlation id for the session associated with the browser request.

The Session overlay models a session as a SOURCE/SINKable address space with a resource identifier matching session:*. It injects this space into the request scope for each request passing through. You can think of its role as swapping the cookie for a dynamically correlated ROC state space (session:).

The Web App has no need to know anything about sessions - it is isolated and is guaranteed that any request arriving will have in its contextual request scope a session: space that it can use to hold transient application state for the web client.

A Load-balanced Caching Proxy

As we discussed last week, holding state is not a violation of ROC provided that its consistency respects the abstraction. But one concern of enabling server-side state is that it creates the potential for a scaling bottleneck. The session state can become the fat cuckoo in the architectural nest.

There are many solutions to this problem. One such, with a relatively high capital cost, is to introduce a network level TCP/IP correlating router that routes a given client originating network request to one of an equal set of front-line HTTP servers.

Here's a cheap alternative. With the addition of a router endpoint and NKP you can transparently fan out the state-bearing tier of your architecture...

The first Host1 system is dedicated to the HTTP transport front-end of the architecture. As before each HTTP request has a bridged normalised space of httpRequest:/ and httpResponse:/ resources. But instead of structuring this to go through the session overlay we instead map all requests to a Router endpoint.

The Router endpoint's job is to pick one of a large set of middle-tier servers (here we're just showing one and called it Host2).

The router algorithm could be simple round-robin load balancing, or since with ROC we always know the real cost of a request, could be adaptive based on the realtime performance of the selected server.

Importantly the router endpoint would ensure "routing affinity" based on the requestor's IP address and/or correlation cookie - so that requests from a given client will return to the same middle-tier server.

Basically we can model the router endpoint as a "single-pole multi-throw switch" with a memory of which route to choose for each HTTP client.

Having selected a given Host2 instance, the resource request coming from the HTTP transport/bridge combo is transparently relayed over NKP to the selected server.

The Host2 servers implement an NKP transport with a fulcrum that imports the session wrapped Web App space. To the application the NKP bridging is completely transparent. The Web App and the Session overlay see a spacial context that is exactly equivalent to that shown in the first diagram (above), only now the spacial architecture spans the cloud.

So with no modification the session overlay can SOURCE httpRequest:/cookie/NETKERNELSESSION which this time is in the httpRequest: space on Host1, the cookie is swapped for the appropriate session which is inserted into the Host2 spacial context.

The session state has been dispersed into a fanned out architectural tier.

Almost for free, the front-end Host1 has become a dedicated caching load-balancing proxy server with consistent correlated state.

"Houston: The cuckoo has landed"

Big Picture

There's only one hidden requirement to enable this pattern. The Cookie needs to be transreptable to and from a serialized stream to cross the transparent NKP bridge. So the Cookie transreptor updates in tpt-http should now make sense.

The pattern outlined above can be done with a dozen lines of code. I implemented it earlier this week in 30 mins so that I could play with a back-end fulcrum bridge (essentially a specialized router that rewrites links to provide a web view to an arbitrary clustered NK instance - that's still ongoing exploration but NK cluster management tooling is on the horizon).

Stepping away from the details of the HTTP / Cookie specifics here, you can see that controlling the partitioning of state is a core architectural weapon to keep in the ROC locker. It doesn't just apply to HTTP-based applications/services - the pattern is general and could as equally be used in ESB architectures etc etc.

The criterion for deciding if dispersing state makes sense is to weigh the network transfer cost of the dispersion against the computation cost and footprint of the implementation tier. The cost of routing an ROC request over NKP is very cheap and the returned representation has chance to be cached on the upper-request tier.

It should be clear that state/load-balancing patterns don't require modifications to application-level implementation code, just restructuring of the spacial architecture. ROC keeps architecture and code separate.

Halloween Resolution Error

I can't think of any Halloween related ROCket science, well other than building your own Pumpkin cannon. But here's something to make you groan...

Pumpkin Pi

Q: Why do computer scientists confuse Halloween with Christmas? [Answer] A: Because, 31 Oct = 25 Dec Q: Can you Count Dracula ? [Answer] A: Only with complex numbers, vampires are imaginary.

NetKernel West 2011 - Denver Area, April 2011

Its been two years since the last NetKernel conference, NK4 is finished and the NKEE release is out too. There are a ton of things to talk about. We don't have a precise space-time coordinate yet, but this much is certain: Denver Area USA, April 2011...

NetKernel West 2011
Location:	Denver Area, USA
Time:	April 2011

Details on Venue, Dates, Logistics coming soon...

Have a great weekend.