A network defines a group of nodes that exchange messages. The network defines a trust perimeter in regards to security and behavior around a set of nodes and is the smallest unit of configuration in FABRIQ. Nodes inside a FABRIQ network should not be exposed to and should not directly addressable from entities outside the network. Securing a FABRIQ network and access to its nodes is not in the scope of this specification, but it is assumed that FABRIQ networks run within a secured environment that allows no foreign (potentially hostile) access.
Messages shall flow into a FABRIQ network through a well-defined and secured gateway, which is the “head” of the network. Access to the network is governed by a policy that defines security requirements and other requirements for messages flowing into the network. The gateway is capable of dispatching verified messages directly to nodes inside the network. Inside the network, nodes exchange messages without security restrictions and without authentication or authorization. As a deployment strategy, the communication channels between nodes may be guarded by transport level security, but this is not made a requirement. This relaxed security model and the requirement for absolute security trust between nodes is introduced to allow the network to operate at very high speed. The expense of security verification is consciously pushed out to the network perimeter using a single gateway.
Each node inside a network is uniquely identified by its node URI. A node must also be associated with at least one logical host identifier and may be associated with any arbitrary number of host identifiers. A host identifier logically represents a host machine on which node instances that shall be run. FABRIQ uses DNS to resolve the host identifier to determine whether a node shall be run on the local machine. This allows creating groups of machines by grouping the IP addresses of a set of machines under a common name in DNS.
There is no predefined message flow inside the network. Each node may send messages to any other node in the network directly. If a node does not choose to specify an explicit destination address during processing, the message is relayed along one of the routes specified for the node, which may lead up the next node or even an external endpoint.
Each node is run as an independent service within its own AppDomain running on top of the FABRIQ runtime process (using the Enterprise Services process model). There is exactly one such service process per machine inside a FABRIQ machine cluster. The service process provides a set of communication ports and hosts any number of node instances.
The communication ports will not attempt to read incoming messages. Their only purpose is the yield either a byte array or a stream of data accompanied by a URI. The relative node URI, which is assumed to be the rightmost part of the URI is used to match against a map of the nodes the host is current running. Once a match is found, the incoming raw message is handed into the node’s application domain and there into a thread pool wait queue and is only cracked (parsed) and processed once a thread becomes available for that message.
On the processing thread the node constructs an XmlReader over a BufferStream over the raw data stream and constructs a Message over the XmlReader. That message object is then handed into the node’s main pipeline for processing. The main pipeline consists of a “gatekeeper” that is responsible for ensuring that the incoming message contains all required headers and will also enforce policy. The “action dispatcher” will dispatch the message to a concrete action pipeline (there can be any number of actions per node). Once the message has been processed by the action’s pipeline, the resulting message(s) are passed to the “router”, which determines the route for the message. Once the message is routed (which may result in the message being sent to multiple destinations concurrently), the “sender port” is responsible for getting it “out the door”.
Next step: Configuring nodes.