The most basic route will take its input from just one endpoint, using the from syntax in the DSL. But, what if we needed to identify multiple inputs for your route? For those situations, there are several alternatives for specifying multiple inputs to a route. The approach taken will depend on whether we need the exchanges to be processed completely independently of one other or if we want the exchanges from different inputs to be combined together in some fashion.
Multiple Independent Inputs
The simplest way to specify multiple inputs is using the multi-argument form of the from() DSL command:
...
NOTE: Exchanges from each of the input endpoints, URI1, URI2, and URI3, are processed independently of each other and in separate threads
Segmented Routes
In certain situations, we may want to merge multiple incoming messages from different messaging systems and process them using the same route. In most cases, you can deal with multiple inputs by dividing your route into segments:
...
The initial segments of this route example will take their inputs from external queues (ie. nyse and nasdaq), and then send the incoming exchanges to an internal endpoint (ie. combinedURL). The next route segment will then merge these incoming exchanges, extracting from the internal endpoint and sending to the destination queue.
Direct Endpoints
The direct component provides us with the simplest mechanism for linking together routes. The event model for the direct component is synchronous, so that subsequent segments of the route run in the same thread as the first segment. The standard format of a direct URL is direct:EndpointID, where the endpoint ID is simply a unique alphanumeric string that identifies the endpoint instance.
...
NOTE: Direct endpoints can only be used to communicate between routes that belong to the same CamelContext in the same Java virtual machine (JVM) instance.
SEDA Endpoints
The SEDA (Staged Event Driven Architecture) component provides an alternative mechanism for linking together routes. It can be used similary to the direct component, however, there is a different underlying event and threading model:
...
NOTE: The primary difference between this scenario and the direct scenario is that with SEDA, the second route segment (from seda:combinedURL) is processed by a pool of five threads.
Content Enricher Pattern
The content enricher pattern defines another different approach to deal with multiple inputs to a route. When an exchange enters the enricher processor, the enricher contacts an external resource to retrieve information, which is then added to the original message. In this type of situation and pattern, this external resource will effectively represent a second input to the message.
...