The platform
NexusFabric is a process that takes messages, runs them through compiled flows, and delivers them onward. This page describes how it is laid out; the chapters at the end go into detail.
The pieces in one program
The front door, transformation and routing, the persistent queue with retry and dead-letter, the message journal and the management UI run in one program. The tokens come from your identity provider.
- Front doorChecked before the body is read. Closed by default.
- Transformation and routingTransforms compiled at publication; routing runs exactly one arm.
- Persistent queueRetry and dead-letter, on its own write-ahead log: an accepted message survives a crash.
- Message journalOne receipt and exactly one verdict per delivery.
- Management UIPages that answer each role exactly as the role table says.
Your identity provider
Stays yours, outside the program.
Every flow is checked before it takes traffic
A flow is a Markdown file with a header and steps. You validate it from the command line and publish it. Publication compiles it into an artifact identified by its fingerprint; what does not compile never reaches runtime.
Checked when you publish:
- The structure of the flow, and the shape of its routing block.
- Flow names, under one rule.
- Templates: credential keys and outbound headers.
- Transforms: XSLT outside the supported subset is refused, not run some other way.
- The SOAP version: anything outside 1.1 and 1.2 is refused.
At run time, a flow’s guards take over: validate refuses a message explicitly, at the first rule that is false, and condition filters silently.
Deduplication declared once, applied however the message arrives
You declare deduplication in the flow, once. Whether the message then comes over synchronous HTTP, through the queue, on a schedule or through the gRPC door, it enters the same delivery bracket, where deduplication, correlation and response memoisation are decided: one place, not four copies that can drift apart. The queue enters the bracket at the worker, not at hand-over.
| Door | Access control | How it reads in the log |
|---|---|---|
| Synchronous HTTP | The same one | Channel http |
| Queue | The same one | Channel queue |
| Schedule | Not applicable — the trigger is internal | Channel cron |
| gRPC | The same one | Channel grpc |
The measured unit is the delivery, not the request: one delivery leaves a receipt entry and exactly one verdict in the log. Which door it came through is read from a dedicated column, not from the kind of event.
One owner of execution
Execution has a single owner in the process. When the installation is at capacity, the refusal is loud: a synchronous call is refused, and the log records a refusal kind distinct from a flow error. At the queue door the message is still accepted and waits on disk; only starting its worker is refused. The refusal at capacity, and the one for a request with nothing to deliver to, stay out of the flows’ error rate.
Installation and configuration
An installation comes up knowing only the operations manual: the first flow runs with the gate closed and its configuration from the environment, inside the shipped image.
Environment configuration is declared in the flow. A published flow that requires a key the installation does not supply stops start-up, naming the flow, the key and the variable — at start-up, not at the first message in production.
More engines, no cluster to manage
Start the same program again over the same state directory. File locks are all that coordinates the copies.
The platform, chapter by chapter
- ArchitectureWhy one program: what runs inside it, and what stays yours.
- GatewayWho is allowed in, with which credential, and what a refused caller sees.
- ProtocolsHTTP, gRPC and SOAP inbound and outbound, plus a message’s ceiling.
- InteroperabilitySOAP, WSDL and gRPC: where the protocol ends and the flow begins.
- ConnectorsMessages that do not arrive over HTTP: a JMS queue and a directory of files.
- TransformationsThe flow language, guards, routing, libraries, and the refusals at publication.
- ObservabilityThe measured unit, the verdict, retention, and the management UI.
- OperatingWhat the running process owns, and what a restart asks of you.
- SecurityThe gate closed by default, the tenant, the roles, and what never reaches an error message.