What is the difference between SEDA, VM and direct in Apache Camel?

The difference between direct: and seda: components is that the first is synchronous and the second is asynchronous, with a queue.

The practical difference is that for sending synchronous messages, you must wait for the route to complete, whereas with asynchronous messages, its "fire and forget" - you put them onto a queue and presume a consumer will process them. You can also have multiple consumers (parallelisation).

The last example, vm: is also asynchronous, but it can also call routes in different camel contexts within the same JVM. Imagine application 1 has a camel context, and application 2 has a camel context, in this way they can communicate with each other.

edit:

In relation to "what to use when" :

• use direct: for calling normally between endpoints in a camel context
• use seda: when you need parallelisation or queues, but dont want to use jms:
• use vm: when calling between applications.

There are of course many other use cases but those are the common ones (subjective to my own experience)

There are at least four different mechanisms by which one Camel route can directly pass data to another. By "directly" I mean without using a network or some form of intermediate storage (file, database). These mechanisms can be grouped according to whether they can pass data between CamelContext instances or not, and whether they are synchronous or asynchronous.

• direct -- single CamelContext, synchronous (blocks producer)
• SEDA -- single CamelContext, asynchronous (does not block producer)
• VM -- multiple CamelContext, asynchronous (does not block producer)
• direct-VM -- multiple CamelContext, synchronous (blocks producer)

The direct and direct-VM mechanisms are synchronous, in the sense that the producing endpoint blocks until the consuming endpoint, and all the rest of its routing logic, is complete. The SEDA and VM mechanisms both use a pool of threads on the consumer, such that each request made by the producer is assigned to one of the threads in the pool. This allows the consumer endpoint and its associated routing logic to act independently of the producer.

Both the VM endpoints are required in situations where communication is between different Camel contexts. In many cases it is possible to combine routes into the same CamelContext. However, it may sometimes be inadvisable, for reasons of modularity, or impossible, because some application framework makes it so. For example, I might implement some Camel routing logic in a library (or component) with the intention that the library be used by other code. To be complete, this library will probably define a self-contained CamelContext with various routes. If I want to invoke the Camel logic in the library, I will need to use VM or direct-VM, because direct and SEDA endpoints do not contain the logic needed to route between Camel contexts.