In-Transit Intelligence
In-Transit Intelligence lets Maps process and filter messages while they move through the system — between publisher and subscriber — without introducing noticeable latency.
It is achieved through JMS selectors applied at:
- Connection level – server-side filtering for incoming or outgoing links.
- Subscription level – client-defined selectors for per-topic or per-queue delivery.
- Protocol bridges – to transform, enrich, or drop messages as they cross protocols.
Capabilities
-
Real-time data filtering
Clients or administrators attach JMS selectors that define what should be received or forwarded.
Selectors can include ML expressions that use trained models (Smile, TensorFlow, ONNX) to decide which events match. -
Dynamic transformation
Messages can be transformed in-flight (JSON↔Protobuf, binary packing, CloudEvent wrapping) before they reach the next hop. -
Protocol-aware optimisation
Each transport (MQTT, AMQP, STOMP, CoAP, NATS, etc.) can evaluate filters at its ingress/egress boundary, minimising unnecessary transmissions.
Example — ML-based subscriber filter
A client subscribes only to environmental readings that the Random Forest model marks as anomalous:
SUBSCRIBE topic:/building/level1/room-201/sensors
SELECTOR rf.classifyprob(room201_rf, AQI, CO₂, temperature, humidity) < 0.05
The Maps server executes the model inline as messages stream through, delivering only those events that meet the selector.
This allows:
- Per-subscriber ML filtering without duplicating topics.
- Server-side execution close to the data source.
- Consistent behaviour regardless of protocol.
Why it matters
- Lower bandwidth and latency: Only relevant messages traverse the network.
- Edge intelligence: Decisions occur at the broker or gateway, not in the application.
- Flexible policy: Different clients can subscribe to the same topic but with different ML-based filters.
- Unified syntax: All filtering—simple logic or ML—is expressed via JMS selectors.