Transports

Where Accessors are the client-side of NetKernel, Transports are the server-side. Here is a point-by-point description of the operation of a NetKernel Transport.

• A Transport receives an application or application-protocol-specific event
• It maps the event, using its application (or application-protocol) specific context, to an internal NetKernel URI
• It builds a URRequest object holding the URI and any resources received with the event
• It issues the request to the kernel scheduler
• The kernel scheduler executes the request against the URI address space of the module which hosts the transport.
• The kernel returns the result of the request to the transport
• If necessary for the application protocol, the transport interprets the request, and issues a response to the triggering application-specific event.

All NetKernel processes are initiated by a Transport initiated request - Transports kick-start processes on NetKernel. A module may host any number of transports. Multiple modules or versions of modules can host application specific transports.

HTTP is a very important application protocol and NetKernel Standard Edition is pre-configured to provide a full Web-application server. The NetKernel HTTP Transport is conceptually similar to the HttpServlet interface - it handles the HTTP verbs. Unlike an HttpServlet the HTTP Transport is simply a bridge to the internal URI address space. It maps the HTTP verb to NetKernel's internal verbs and issues an internal NetKernel URI request. Frequently the internal URI is the same as the external URL address but this is now issued against the address space of the module which hosts the HTTP Transport. Note, that HTTP's auxiliary technologies such as Cookies, file uploads, multi-part encoded forms... all fit into the Transport abstraction.

The Transport abstraction can be applied to any application protocol. Transports can be written to integrate non-Web-like systems into NetKernel - for example we provide polling SMTP transports to create email processing systems, an Intray transport, a Telnet transport, SOAP-messaging transports ... we've even experimented with GUI event transports!