 |  |  |  |  |
| | | | |
 |  |
Figure 1.1 gives a general overview of the Apache Camel architecture; this architecture enables you to deploy across a wide variety of container types.
The router service is represented by a Camel context object,
which encapsulates routing rules (in the form of RouteBuilder
objects) and components (which enable the router to bind to various network protocols and
other resources). The router application itself consists either of Java code or XML
configuration, or possibly a combination of the two.
In general, an endpoint is a source or a sink of messages, identified by a URI. In practice, this means that an endpoint maps either to a network location or to some other resource that can produce or consume a stream of messages. Within a routing rule, endpoints are used in two distinct ways:
The consumer endpoint, which appears at the start of a rule
(for example, in a from() command), receives messages from an
external source and creates an exchange object that is processed by the rule;
The producer endpoint, which appears at the end of a rule
(for example, in a to() command), sends the current exchange's
message to an external target.
A component is a plug-in that integrates the router core with a particular network protocol or external resource. From the perspective of a router developer, a component appears to be a factory for creating a specific type of endpoint. For example, there is a file component that can be used to create endpoints that read/write messages to and from particular directories or files. There is a Apache CXF component that enables you to create endpoints that communicate with Web services (and related protocols).
Typically, before you can use a particular component, you must configure it and add it to the Camel context. You do not have to do this for the following components, which are embedded in the router core:
Bean—Binds Java beans to message exchanges. It is also useful for exposing and invoking POJO (Plain Old Java Objects).
Direct—Provides direct, synchronous invocation of any consumers when a producer sends a message exchange. A direct endpoint can be used to connect existing routes. Clients running in the same JVM as the router can also access direct endpoints.
File—Provides access to the file system, enabling you to read messages from files and write messages to files.
Log—Logs the message exchange to some underlying logging system like log4j.
Mock—Provides a powerful declarative testing mechanism similar to jMock, allowing declarative expectations (assertions) to be created on any Mock endpoint before a test begins. When the test is run, messages are fired to one or more endpoints and the assertions are checked.
SEDA—Provides asynchronous SEDA behaviour, so that messages are exchanged on a BlockingQueue and consumers are invoked in a separate thread from the producer.
Timer—Generates message exchanges when a timer fires. This component can be used only to define consumer endpoints (appearing at the start of a route).
VM—Enables asynchronous calls to another endpoint in the same JVM.
For more details about the available components see the Deployment Guide and the list of Camel components.
The RouteBuilder classes encapsulate the routing rules. A router
developer defines custom classes that inherit from RouteBuilder and adds
instances of these classes to the CamelContext.
The router architecture supports these deployment options:
Spring container deployment—You can deploy the router application into a Spring container, using the Spring configuration file to configure components and define routes.
Standalone deployment—You can write a
main() method in the application code, which is responsible
for creating and registering RouteBuilder objects as well as
configuring and registering components.
OSGi—You can deploy the router application into an OSGi container.
For more details about the deployment options, see the Deployment Guide.
| |  | |
 |
