Steve comments on the W3C web architecture recommendation.

I had a good think about this whilst cycling into work this morning. As usual I returned to my Physics roots to look for an appropriate metaphore for my thoughts...

It seems that the W3C has a Newtonian view of the world - every particle can be described absolutely with a small number of canonical variables. A single URI is sufficient to uniquely define a resource.

I think that these recommendations seem pretty reasonable at a macroscopically large scale - i.e. the world-wide public web address space. However as you turn down the scale, URI addressing becomes more and more dependent on the local context.

Steve provides his example at the Corporate Intranet level - an intranet is clearly a localized URI address space.

Going even finer grain, a NetKernel module is a micro-URI-address-space and displays URI addressing patterns of all types and a resolution process which actually depends on application context. For example...

• It is frequently desirable to have more than one resource with the same URI, in this case resolvable by its local module context - see for example the typical accessor configuration patterns such as the sqlQuery accessor.
• It is frequently desirable to have a single resource with more than one URI - see for example an Accessor that implements more than one function or continues to provide legacy services in an updated system.
• It is often desirable to have two generations of a URI addressed service in two seperate modules - two different application use the same URI to two different services with no clashes based upon the locally configured module import rules.

The degree to which a resource has relative or absolute URI addressing becomes totally blurred at a microscopic addressing level - and for good reasons, system flexibility (aka loose coupling) totally demands it.

Please W3C don't be too trenchant about the absoluteness of the URI address-space. Newtonian mechanics is appropriate at large scale but recognise that loosening the constraints at small scale is valid...

I've been participating in some discussion about NetKernel following the 2.0.1 release announcement on The Serverside...

The Jetty folks have published an interview style case-study on NetKernel and Jetty.

Jetty really is an excellent pure-java HTTP Server.

After missing the cut for release with 2.0.0 we have put together a 2.0.1 release which includes the JMS connectivity module, together with a few new tools and some minor patches.

The JMS module has two parts - a Transport which can subscribe to queues and topics and allows the creation of message-driven-service patterns. In addition there's an Accessor which allows NetKernel to post new messages.

There are several new architectural patterns that the two components enable. NetKernel can be used as a primary message dispatcher server - aggregating and pre-processing transport intiated events and sending them out to the JMS bus. Equally NetKernel can be a JMS peer - listening on topics and queues and executing message-driven-services.

It'll be interesting to hear what new uses people will start find.

As ever you can get the latest release at download.1060.org

A couple of our customers have reported spurious errors involving cookies. Here's an example of the sort of error stack trace that they're seeing (names have been xxxxxx'ed for privacy)

Message:    The request
jetty://zzzzzzzz.xxxxxxx.com:8888/yyyyyyy/provider/+cookie@literal%3Acookie
in module urn:org:ten60:netkernel:tpt:http failed because no module could
be located to handle it. See Exception trace for details of resolution process.
Request:    
jetty://zzzzzzzz.xxxxxxx.com:8888/yyyyyyy/provider/+cookie@literal%3Acookie
Trace:    
Searching for 
jetty://zzzzzzzz.xxxxxxx.com:8888/yyyyyyyy/provider/+cookie@literal%3Acookie
Starting Module urn:org:ten60:netkernel:tpt:http
Matched on Mapping jetty:.* skipping next 17 mappings
Matched on Mapping .* SUPER
Entering Parent Module urn:org:ten60:netkernel:fulcrum:frontend
Rewriting Request to ffcpl:/yyyyyyy/provider/+cookie@literal%3Acookie
Checked Unmatched Mapping (many) rewrite
Checked Unmatched Mapping (many) rewrite
Checked Unmatched Mapping ffcpl:/(etc|pub)/.* THIS
Checked Unmatched Mapping ffcpl:/entrypoints.xml THIS
Checked Unmatched Mapping (many) to import urn:org:ten60:netkernel:tpt:http
Checked Unmatched Mapping (many) to import
urn:org:ten60:netkernel:cache:standard
Checked Unmatched Mapping (many) to import
urn:org:ten60:netkernel:mod:ws:test
Checked Unmatched Mapping (many) to import
urn:org:ten60:netkernel:ext:layer1
Matched on Mapping (many) to import urn:com:xxxxxxx:mod:yyyyyyyyyy
Entering Import Module urn:com:xxxxxxx:mod:yyyyyyyyy
Checked Unmatched Mapping ffcpl:/(app/|entrypoints.xml).* THIS
Checked Unmatched Mapping (many) to import
urn:org:ten60:netkernel:ext:xml:core
Ignoring pre-checked Mapping (many) to import
urn:org:ten60:netkernel:ext:layer1
Checked Unmatched Mapping (many) to import urn:org:ten60:netkernel:ext:dpml
Checked Unmatched Mapping (many) to import urn:org:ten60:netkernel:ext:sys
Matched on Mapping .* SUPER
No Match Found for 
jetty://zzzzzzzz.xxxxxxx.com:8888/yyyyyyy/provider/+cookie@literal%3Acookie

The problem is that some other app-server has set a permanent cookie in your browser on the root path / for host zzzzz.xxxxxxx.com. This is getting processed by the HTTPBridge and added as an argument on the active URI. The active URI with cookie is then failing resolution against the the internal module address space.

The quick fix is simply to delete the cookie.

A better solution is to modify your HTTPBridgeConfig.xml in the Fulcrum which is hosting HTTP transport. The HTTPBridge lets you set arbitrary filters on the HTTP request - including specifying if cookie processing should occur or not.

This highlights a possibly unwise choice we took - the default bridge zone performs cookie processing! Which means you can get cookie errors in your application's URI address space resolution if your not anticipating +cookie@[...] arguments on the active URI request on your module's public interface.

It's your choice how you want to expressly deal with cookies: at the fulcrum or application level - we generally specify URL zones at the fulcrum-level where we expect to use cookies and everywhere else they're filtered off. [Though actually we screwed this up on the backend fulcrum we put out with 2.0.0 - we've posted an update, see system health check, which does what I said we do!]