Comments

Address Space Mappings

The HTTP Transport issues root requests into the internal address space with an http: scheme URI. Usually these HTTP transport requests are mapped to the HTTP Bridge.

It is important to note that the HTTP bridge issues sub-requests using the jetty: scheme. It does this to avoid any possibility of circular HTTP loops - since NetKernel is a symmetric client server, if the request were internally issues as http: it might be possible in a badly configured system to end up making a infinite callback to the host server. By moving to jetty: any failure to process the request will return an exception and not a loopback. (If you use the HTTP Transport at a low level without the HTTP Bridge you are responsible for ensuring HTTP callback loops cannot happen.)

The fulcrum modules are configured to map requets from the HTTP bridge to the internal ffcpl: address space with the following rewrite rule:

This mapping removes hostname and port information. If this information is needed by the application then either modify the HTTP Bridge configuration to supply this as an active URI argument, or modify the rewrite to preserve this information in the mapping to ffcpl:

Exception Handling in NetKernel HTTP Transport

Exceptions raised in NetKernel application and resource model code are propagated up the context stack until an exception handler is found. If no exception handler is located the exception is finally propagated to the transport issuing the initial root request.

The HTTP Bridge configuration information supports zone specific exception handling. For each zone the element

may be set to a URI to invoke when an exception propagates back to the HTTP Bridge.

Additionally the element

can reference a global exception handler.

If an exception handler is not specified then the NetKernel exception, expressed as an XML document, is sent back to the client as the payload along with a code of 500 set.

If NetKernel is used on the client side to initiate the remote HTTP request then it is possible to propagate exceptions across the remote link. This is done using the HTTP Client services. For example the following DPML code will use the httpGet service to issue a remote get and then the httpResponseCodeFilter will analyze the returned resource. If the return code is a non-200 code then the exception is unpacked and re-thrown within the client.