Service Message Path

How a deployed service receives a message, runs a Servit, and publishes the next channel.

Last updated: 2026-10-20 Section: Architecture

A node runs one service. Traffic enters on a messagebus://endpoint1/... binding, arrives on an inbound channel, and is handled by Servit.handle. The Servit publishes the next message with ServitMessageChannel.publish. The deploy file chooses the destination channel.

Before you begin Service definition is services/<service>/service.xml. Bindings and resources are config/services/<node>/deploy/<service>.xml. Connections and endpoints are under contexts/messagebus/.

Message path

Step	Where it is declared	What runs	Failure
Binding	deploy.xml `<inbound>`	messagebus URI with `${param:...}`	Missing routing params
Channel	service.xml `<inbound-channel>`	Declared message-params	Channel not subscribed
Servit	service.xml `<type>`	`init`, `handle`, `destroy`	`ServitException` and `ErrorCode`
Next hop	deploy.xml `<outbound>`	`channel.publish`	Publish failure
Dead letter	deploy.xml `<dead-letter-channel>`	`messagebus://error/...`	Unhandled processing error

Node worker count

Concurrency for a node is <worker-num> in config/services/<node>.xml. The sample file sets it to 256. That number is not a request-rate guarantee.

<node>
  <worker-num>256</worker-num>
</node>

Recommended design principles

Keep domain decisions in the Servit. The next service is selected by the deploy binding, not by a class name inside handle.
Put routing parameters on the message so ${param:...} in the messagebus URI can expand.
Send a business rejection as a normal outbound message. Throw ServitException only when the step cannot finish.