in-VM
In-VM transport (also called VM transport) is a communication mechanism that allows clients and the broker to communicate directly within the same JVM (Java Virtual Machine)—without using any network protocol.
The first client to use the VM connection will boot an embedded broker. Subsequent connections will attach that the same broker. Once all VM connections to the broker have been closed, the embedded broker will automatically shutdown.
In-VM local transport allows TCP loop-back like SOAP communication between the client and the server in the same virtual machine. It is primarily designed to enable testing of web service endpoints without using a fully-fledged web container.
It is important to realize that InVM achieves its performance benefits by optimizing the internal data structures that are used to facilitate communication between services. There are a number of limitations that are discussed below that must be taken into account when deciding to make use of this transport.
The major limitation is that the queue used to store messages is not persistent. If the service is shutdown or otherwise fails before the queue is emptied, then those messages will be lost.
Why we use In-VM transport?
We use In-VM transport mainly for performance and efficiency when both sender and receiver are inside the same application instance.
Key reasons to use in-VM:
1. High performance (no network overhead)
Messages are passed via method calls or memory queues instead of HTTP/TCP, so it’s much faster.
2. Low latency
Since there’s no serialization over the network, latency is extremely low.
3. Reduced resource usage
No need for socket connections, ports, or network stack processing.
4. Useful in modular systems
When an application is split into multiple internal services (e.g., mediation, routing, logging), In-VM transport lets them communicate efficiently.
5. Simplifies internal communication
No need to expose internal services as HTTP endpoints.
When NOT to use in-VM?
• When components are in different servers / containers
• When you need distributed scalability
• When services must be independently deployable
• When you need fault isolation between services
Key Features of in-VM
No Network Overhead: No TCP/IP stack involved
Extremely Fast: Direct memory / method invocation
Embedded Broker Support: Broker runs inside your app
Simple Configuration: No ports, no firewall, no networking
Advantages
High Performance: Fastest possible messaging in ActiveMQ.
Low Latency: No network delays.
Easy Setup: No external broker required.
Great for Testing: Perfect for unit/integration tests.
Disadvantages
Same JVM Requirement: All components must run in the same JVM.
No Remote Communication: Cannot connect from other machines.
Limited Scalability: Not suitable for distributed systems.
Tight Coupling: Applications become tied to the embedded broker.
Alternatives to In-VM transport
Depending on architecture, these are common alternatives:
1. HTTP / REST
• Most common alternative
• Works across machines and networks
• Slower than In-VM but highly interoperable
• Good for microservices
• Easy debugging and standardization
2. SOAP (Web Services)
• XML-based enterprise protocol
• Strong contracts (WSDL)
• Heavier than REST
• Used in legacy enterprise systems
3. Messaging Systems (Asynchronous)
Examples: Apache Kafka, RabbitMQ, ActiveMQ
• Decoupled communication
• High scalability
• Event-driven architecture
4. gRPC
• Binary protocol over HTTP/2
• Very fast and efficient
• Low latency distributed systems
• Strong typing via protobuf
5. Direct method invocation (same module)
• No middleware layer at all
• Pure in-process function calls
• Fastest possible
• No decoupling or mediation layer
6. JMS (Java Message Service)
• Java-based messaging standard
• Often backed by ActiveMQ or similar
• Enterprise Java systems
