Figure 6 shows a high-level overview of the routing and integration service's architecture.

Figure 6. Routing and integration service architecture

At a high-level, Fuse ESB Enterprise's routing and integration service consists of routes, processors, components, and endpoints, all of which are contained within a CamelContext, the routing runtime. In addition, the routing runtime also contains type converters, data formats, languages, and a registry.

For a detailed description of the routing runtime (CamelContext), see the Configuring a Component in Programming EIP Components.

Routes specify paths over which messages move. Processors execute actions on messages (such as routing, transformation, mediation, enrichment, validation, interception, and so on) as they move between the route's consumer and producer endpoints.

You create processors using the supported EIPs or by building your own. For more details, see the Programming EIP Components.

You create routes in routing rules by wiring a string of processors together between a consumer and one or more producer endpoints. The output from one processor in the string is the input into the next one.

Routing rules are declarative statements (written in Java or XML DSL) that define the paths which messages take from their origination (source) to their target destination (sink). Routing rules start with a consumer endpoint (from) and typically end with one or more producer endpoints (to). Between the consumer and producer endpoints, messages can enter various processors, which may transform them or redirect them to other processors or to specific producer endpoints. For example, the Java DSL choice() method creates a content-based router;

from("jms:widgetOrders")
 .choice()
   .when(predicate)
     .to("jms:validOrders")
   .otherwise
     .to("jms:deadOrders");

which, based on the specified predicate, directs messages to one or the other producer endpoint.

Figure 7.2 shows an example that employs five routes and two processors. The consumer endpoint, camel-cxf (3), receives part order requests and passes them to a content-based router processor (4), which pushes each onto one of the four store's queue (5), according to the part order's zip code. If a part order's zip code fails to match any of the zip codes on its list, the content-based router processor pushes the part order onto the deadOrders queue. In the back end routing runtime, the dynamic router processor (6) directs orders to different destinations based on whether the ordered parts are available.

Components are plug-ins that add connectivity to other systems. A component behaves like a factory, creating endpoints of a given type. (For example, you'd use an HTTP component to create HTTP endpoints, and a File component to create file endpoints.)

Fuse ESB Enterprise includes over eighty components that support a wide range of functions, such as data transports, message validation, JMS messaging, and so on.

For more details, see Programming EIP Components.

Created by components, endpoints represent the end of a message channel through which a system can send and receive messages. You both configure and refer to endpoints using URIs.

Functionally, endpoints are a message source or a message sink, mapping to either a network location or some other resource that can produce or consume a stream of messages. Within a routing rule, endpoints are used in two distinct ways:

For more details, see Understanding Message Formats in Programming EIP Components.