Microservices Integration Patterns
Services connect by messagebus bindings. A Servit does not call the next service by class name.
The next service is the outbound binding. Business state travels in the payload and the parameters. A Servit publishes a channel name and does not name the next class.
| Pattern | Best fit | Core implementation | Caveats |
|---|---|---|---|
| Channel handoff | Next business step | Outbound channel to the next inbound binding | Sender must not name the next Servit class |
| Business result | Decline, mismatch, anomaly | Normal message on a rejected channel | Do not throw for an expected outcome |
| Dead letter | Step cannot finish | ServitException and <dead-letter-channel> | Routing params must still expand |
| Shared resource | Store or client used by the step | ref-name in service.xml, type in deploy.xml | Missing resource fails init |
Message contract
messagebus://endpoint1/com/kiosk/${param:kiosk_id}/payment/${param:payment_id}/requested
ServitMessage
messageId
headers
parameters: kiosk_id, payment_id, order_id
payload: byte[]
Wire a step
- Declare the Servit, its source channel, and init-param defaults in
service.xml. - Bind that channel to a messagebus URI in
deploy.xml. - Publish with
ServitMessageChannel.publish. Carry routing parameters on the message. - Point unhandled errors at
messagebus://error/.../deadletter/${ctx:service_id}.