A transport is an endpoint that originates requests within NetKernel. A transport is implemented by a physical endpoint which also participates in the external world and the originator of root requests in the ROC world. In the external world, a transport functions as an event detector; when it detects an event, a transport creates and issues a corresponding root request into the logical level of an ROC system and forwards back to the external world the returned resource representation.
Because a transport does not resolve any requests its declaration only needs to reference the Java class or prototype that provides the physical endpoint implementation:
There is no limit to the type of event a transport can be designed to detect. Examples include the arrival of an HTTP protocol request on a TCP/IP port, a signal on an RS-232 connection, the arrival of a file in a monitored directory, the passing of time, etc.
One of the advantages of developing software in NetKernel with the ROC abstraction is the virtualization of radically different types of real-world events handled by transports. One application can be logically coupled to a variety of transports.
Because transports issue root requests and initiate all processing in NetKernel, the space and module hosting a transport plays a special architectural role in an application design. The name "fulcrum" is given to the module and space hosting a transport because that point is the pivot point or fulcrum.
Detailed information about transport development is provided in the Physical Reference Guide.
The SMTP transport opens a TCP/IP port on the outside of NetKernel to listen for and accept connections from external clients. The event detected by this transport is a TCP/IP connection and the successful delivery of a message through the SMTP protocol. SMTP clients may be email client or SMTP servers that need to deliver an email message. When the transport accepts an TCP/IP connection and a message, it creates and issues a root request using the following URI scheme:
The SMTP transport also injects a dynamically created address space, emailMessage:/, into the request scope prior to issuing the request. Handlers of the smtp:message root request may issue requests for various elements of the message and they will resolve within this transient message space.
In the following example, a SMTP transport is established within the space named Email Fulcrum. (It is also configured to accept dynamic imports to the identifier SMTPFulcrum. Dynamically imported spaces will contain handlers for the root requests.)
The HTTP Transport opens a TCP/IP port on the outside of NetKernel to listen for and accept connections from external clients. The event detected by this transport is a TCP/IP connection and a HTTP protocol request. HTTP clients are generally browsers but they could be any remotely running application. The HTTP protocol supports the World Wide Web and is used to tunnel other protocols because of wide spread firewall support. When the transport accepts a TCP/IP connection and a HTTP request, it create and issues a root request using the following URI scheme:
The transports combines the low-level HTTPRequest and HTTPResponse objects into a single HTTPRequestResponseRepresentation which is added to the root request as the primary argument. This very low level request is then directed to the HTTP Bridge overlay. The HTTP Bridge handles the root request issued by the transport by injecting a transient space into the request scope of the request and then issuing a sub-request into its wrapped space. The injected space provides access to parsed elements of the HTTP request.
A good example of the use of the HTTP transport is the front end fulcrum module, which is shown below.