Modelling Injected Spaces

One of the enhancements to the ROC abstraction that was introduced with NetKernel 4 was the ability to dynamically inject address spaces into the scope of resource requests. In NetKernel 3 the scope was determined purely from the requestors scope and the resolution path through any space imports to the resolved endpoint. In NetKernel 4 this same basic approach is used but any endpoint can now inject new spaces into the scope before issuing a request. In essence what this new capability does is allow local (private) address spaces to be shared by any sub-requests. The practical uses of this include such things as:

• unifying “pass-by-value” and “pass-by-reference” to always be pass-by-reference but with a reference to a resource in an injected space. For more details see the NKSE documentation.

• providing a mechanism for late/lazy access to transport state. This is used by the HTTP transport bridge to provide access to all areas HTTP envelope if needed but only if needed. This not only reduces the overhead of parsing the various parts into representations but more importantly automatically maximizes the cachability of the response. (Those who used NetKernel 3 will remember needed to configure the HTTP bridge to determine which parts of HTTP envelope should be passed as explicit arguments to sub-requests.)

Anyway the reason for this post is to show how these injected spaces are now modelled in the space explorer. This is a new feature of the Static Structure Diagram and will be available in the repositories soon.

This static structure diagram shows a Fulcrum space with the HTTPTransport and with HTTPBridge wrapping Space 2. The new notation shows the HTTP Request Response Space injected into all requests that get delegated from the HTTPBridge into Space 2. We can see that the HTTP Request Response Space has two endpoints the HTTPRequestEndpoint and HTTPResponseEndpoint which provide access to the request and response through the httpRequest: and httpResponse: schemes respectively for all sub-requests.

Space 2 contains the HTTPSession overlay which delegates all requests through to Space 3. We can see the HTTPSession overlay similarly injects a HTTP Session Space into the scope of all the requests it delegates.

Here is the module definition xml (module.xml) for this functionality:

<rootspace name="Fulcrum" filter="false" public="false">
	<transport>
		<prototype>HTTPTransport</prototype>
	</transport>
	<overlay>
		<prototype>HTTPBridge</prototype>
		<config>
			<rewrite>
				<match>http://.*?/(.*)</match>
				<to>res:/$1</to>
			</rewrite>
		</config>
		<space name="Space 2">
			<overlay>
				<prototype>HTTPSession</prototype>
				<config>
					<maxsessions>5</maxsessions>
				</config>
				<space name="Space 3">
					<endpoint>
						<grammar>res:/archplaypen/sessionTest</grammar>
			<class>org.netkernel.tab.arch.playpen.SessionTestAccessor</class>
					</endpoint>
				</space>
			</overlay>
		</space>
	</overlay>
	<fileset>
		<regex>res:/etc/.*</regex>
	</fileset>
	<import>
		<uri>urn:org:netkernel:xml:core</uri>
		<private/>
	</import>
	<import>
		<uri>urn:org:netkernel:tpt:http</uri>
		<private/>
	</import>
</rootspace>

I hope this new notation is going to be useful to throw light onto what previous was one of the darker corners of the ROC abstraction and will help with visualizing your systems. As ever all feedback welcome!

Tony