The ChannelFramework, aka Transport Channel Service, is a package used to link together common componentized pieces of function as an abstracted protocol stack. Each Channel or Transport Channel can be linked together with other Channels to create a Transport Chain or Chain. In this model, the Channel represents a protocol layer and the Chain represents the whole transport or a protocol stack.
The ChannelFramework is fairly protocol agnostic and mainly is concerned with how connections are established in Chains and how Chains link together.
Terminology
- Channel - A Channel is the functional equivalent of a protocol layer in a stack. A channel provides some functionality that is unique in the stack.
- Channel Chain - A Channel chain is like a protocol stack. It is a group of one or more channels linked together to perform some function.
- Inbound Channel/Chain - An Inbound Chain is a server side chain, or transport/protocol stack. Connections in this sort of chain originate at the bottom of the stack. Each channel in an Inbound Chain is an Inbound Channel. These Channels expect the connections to originate from the bottom of the stack. If this chain is connected to the network, the lowest level channel would be listening for new connections to be originated from a network client.
- Outbound Channel/Chain - An Outbound Chain is a client side chain, or transport/protocol stack. Connections in this sort of chain originate at the top of the stack. Each channel in an Outbound Chain is an Outbound Channel. These Channels expect the connections to originate from the top of the stack through a connect call. If this chain is connected to the network, the lowest level channel would be creating a new connections to a remote process. Often, there is no Application Channel in an Outbound Chain.
- ChannelFactory - This will be instantiated by the ChannelFramework in order to create channels and to check the coherency of the chains. The coherency of the chains is checked by asking the factories for the interfaces surrounding the channel in question to ensure they are expecting one another. While multiple of them may be instantiated to check things such as chain coherency the ChannelFactory has a lifecycle of its own. Before any channel is created, the init() method will be called and the destroy method will be called once all the channels belonging to that factory have been destroyed.
- DiscriminationProcess - This is the process by which an Inbound Channel associates itself with the channel above. An inbound channel will provide some information and the DiscriminationProcess will link to the correct channel above. An example of how to utilize this is in the package information for zero.network.vendor.channel.
- VirtualConnection - The VirtualConnection is the piece of code that allows channels to store state/context information throughout the life of a connection. VirtualConnections often map one-to-one to physical connections although this is not always the rule. (See HTTP Tunneling Channel).
- VirtualConnectionFactory - There are inbound and outbound VirtualConnectionFactories that provide the Channel Framework users a way to create VirtualConnections for a given Chain. On the inbound side, there is no Chain name used to create the connection and the Chain name is never actually mapped directly.
- ChainEventListener - This is the only interface that should be implemented outside the ChannelFramework in this package. This interface is used to catch lifecycle events (among others) for Chains.
Most of this package includes interfaces into the implementations of the ChannelFramework. This represents the main API used to create Channels, use Channels, and to access information about the Channels.