List of Figures

Chapter 1. Meeting Camel

Figure 1.1. Camel DSLs use real programming languages like Java, so you can use existing tooling support.

Figure 1.2. Files are routed from the data/inbox directory to the data/outbox directory.

Figure 1.3. Messages are entities used to send data from one system to another.

Figure 1.4. A message can contain headers, attachments, and a body.

Figure 1.5. A Camel exchange has an ID, MEP, exception, and properties. It also has an in message to store the incoming message and an out message to store the result.

Figure 1.6. At a high level, Camel is composed of processors, components, and routes. All of these are contained within the CamelContext.

Figure 1.7. The CamelContext provides access to many useful services, the most notable being components, type converters, a registry, endpoints, routes, data formats, and languages.

Figure 1.8. An endpoint acts as a neutral interface allowing systems to integrate.

Figure 1.9. Endpoint URIs are divided into three parts: a scheme, a context path, and options.

Figure 1.10. How endpoints work with producers, consumers, and an exchange

Figure 1.11. An event-driven consumer waits idle until a message arrives, at which point it wakes up and consumes the message.

Figure 1.12. A polling consumer actively checks for new messages.

Chapter 2. Routing with Camel

Figure 2.1. A message router consumes messages from an input channel and, depending on a set of conditions, sends the message to one of a set of output channels.

Figure 2.2. A customer has two ways of submitting orders to the Rider Auto Parts order-handling system: either by uploading the raw order file to an FTP server or by submitting an order through the Rider Auto Parts web store. All orders are eventually sent via JMS for processing at Rider Auto Parts.

Figure 2.3. A Camel endpoint URI consists of three parts: a scheme, a context path, and a list of options.

Figure 2.4. There are two types of JMS destinations: queues and topics. The queue is a point-to-point channel, where each message has only one recipient. A topic delivers a copy of the message to all clients who have subscribed to receive it.

Figure 2.5. RouteBuilders are used to create routes in Camel. Each RouteBuilder can create multiple routes.

Figure 2.6. Use autocomplete to start your route. All routes start with a from method.

Figure 2.7. After the from method, use your IDE’s autocomplete feature to get a list of EIPs (such as Pipeline, Enricher, and Recipient List) and other useful integration functions.

Figure 2.8. The route shown in listing 2.1 forms a simple pipeline. The output of the FTP consumer is fed into the input of the JMS producer. The payload conversion from file to JMS message is done automatically.

Figure 2.9. With a processor in the mix, the output of the FTP consumer is now fed into the processor, and then the output of the processor is fed into the JMS producer.

Figure 2.10. The CBR routes messages based on their content. In this case, the filename extension (as a message header) is used to determine which queue to route to.

Figure 2.11. By using the end method, you can route messages to a destination after the CBR.

Figure 2.12. A Message Filter allows you to filter out uninteresting messages based on some condition. In this case, test messages are filtered out.

Figure 2.13. A multicast sends a message to a number of specified recipients.

Figure 2.14. A recipient list inspects the incoming message and determines a list of recipients based on the content of the message. In this case, the message is only sent to the A, B, and D destinations.

Figure 2.15. A wire tap is a fixed recipient list that sends a copy of a message traveling from a source to a destination to a secondary destination.

Chapter 3. Transforming data with Camel

Figure 3.1. Camel offers many features for transforming data from one form to another.

Figure 3.2. In the Message Translator EIP, an incoming message goes through a translator and comes out as a translated message.

Figure 3.3. In the Content Enricher EIP, an existing message has data added to it from another source.

Figure 3.4. An overview of the route that generates the orders report, now with the content enricher pulling in data from an FTP server

Figure 3.5. A Camel route using an XSLT component to transform an XML document before it’s sent to a JMS queue

Figure 3.6. An object is marshaled to a binary representation; unmarshal can be used to get the object back.

Figure 3.7. The TypeConverterRegistry contains many TypeConverters

Chapter 4. Using beans with Camel

Figure 4.1. The service activator mediates between the requestor and the POJO service.

Figure 4.2. Relationship between a Camel route and the Service Activator EIP

Figure 4.3. A requester looks up a bean using the Camel registry, which then uses the Spring ApplicationContext to determine where the bean resides.

Figure 4.4. To invoke a bean in Camel, the BeanProcessor looks it up in the registry, selects and adapts a method, invokes it, and passes the returned value as the reply to the Camel exchange.

Figure 4.5. How Camel selects which method to invoke (part 1, continued in figure 4.6)

Figure 4.6. How Camel selects which method to invoke (part 2, continued from figure 4.5)

Figure 4.7. How BeanProcessor binds the input message to the first parameter of the method being invoked

Figure 4.8. Parameter binding with multiple parameters involves a lot more options than with single parameters.

Chapter 5. Error handling

Figure 5.1. Errors can be categorized as either recoverable or irrecoverable. Irrecoverable errors continue to be errors on subsequent attempts; recoverable errors may be quickly resolved on their own.

Figure 5.2. Camel’s error handling only applies within the lifecycle of an exchange.

Figure 5.3. A detailed view of a route path, where channels act as controllers between the processors

Figure 5.4. The Dead Letter Channel EIP moves failed messages to a dead letter queue.

Figure 5.5. Sequence diagram of a message being routed and a JmsException being thrown from the JmsProducer, which is handled by the onException. OnException generates a failure that is to be returned to the caller.

Figure 5.6. Sequence diagram of a message being routed and a ValidationException being thrown from the ValidateProcessor. The exception is handled and continued by the onException policy, causing the message to continue being routed as if the exception were not thrown.

Chapter 6. Testing with Camel

Figure 6.1. Testing a Camel application by sending a message to the application and then verifying the returned output

Figure 6.2. The Camel Test Kit is provided in two JAR files containing the JUnit extensions, Mock component, and producer template.

Figure 6.3. Three steps for testing: set expectations, run the test, and verify the result.

Figure 6.4. The channel acts as a controller, and it’s where messages are intercepted during routing.

Figure 6.5. The client sends orders to an order queue, which is routed by a Camel application. The order is either accepted and routed to a confirm queue, or it’s not accepted and is routed to an invalid queue.

Chapter 7. Understanding components

Figure 7.1. A component creates endpoints and may use the CamelContext’s facilities to accomplish this.

Figure 7.2. To autodiscover a component named “bean”, the component resolver searches for a file named “bean” in a specific directory on the classpath. This file specifies that the component class that will be created is BeanComponent.

Figure 7.3. A file transfer between two applications is a common way to integrate with legacy systems.

Figure 7.4. Orders are published to the xmlOrders topic, and the two subscribers (the accounting and production queues) get a copy of the order.

Figure 7.5. In request-reply messaging, a requestor sends a message to a request queue and then waits for a reply in the reply queue. The replier waits for a new message in the request queue, inspects the JMSReplyTo address, and then sends a reply back to that destination.

Figure 7.6. The javax.jms.Message interface has five implementations, each of which is built for a different body type.

Figure 7.7. A client invokes a remote web service over HTTP. To the client, it looks as if it’s calling a Java method on the service endpoint interface (SEI). Under the hood, this method invocation passes through the web services framework, across a network, and finally calls into the service endpoint implementation on the remote server.

Figure 7.8. In contract-first web service development, you start out by creating a WSDL document and letting a tool generate the required source interfaces and stubs.

Figure 7.9. In code-first web services development, you start out by coding the service interface and implementation and then using a tool to generate the required WSDL.

Figure 7.10. Sensors feed status messages over TCP to a server, which then forwards them to a JMS operations queue.

Figure 7.11. During TCP communications, a payload may be broken up into multiple packets. A MINA textline codec can assemble the TCP packets into a full payload by appending text until it encounters a delimiter character.

Figure 7.12. The custom welder sensor decoder is used to interpret an 8-byte binary payload and construct a plain text message body. The first 7 bytes are the machine ID and the last byte represents a status. In this case, a value of 1 means “Good”.

Figure 7.13. A message from the JMS accounting queue is transformed into an SQL command message by the OrderToSqlBean bean. The JDBC component then executes this command against its configured data source.

Figure 7.14. SEDA queues can be used as a low-overhead replacement for JMS when messaging is within a CamelContext. For messages being sent to other hosts, JMS can be used. In this case, all order routing is done via SEDA until the order needs to go to the accounting and production departments.

Chapter 8. Enterprise integration patterns

Figure 8.1. The Composed Message Processor EIP splits up the message, routes the sub-messages to the appropriate destinations, and re-aggregates the response back into a single message.

Figure 8.2. The Aggregator stores incoming messages until it receives a complete set of related messages. Then the Aggregator publishes a single message distilled from the individual messages.

Figure 8.3. Illustrates the Aggregator EIP in action, with partial aggregated messages updated with arriving messages.

Figure 8.4. An aggregated message is completed , it’s published from the Aggregator , and processing fails , so the message is rolled back.

Figure 8.5. The Aggregator recovers failed messages, which are published again , and this time the messages completed successfully .

Figure 8.6. The Splitter breaks out the incoming message into a series of individual messages.

Figure 8.7. A sequence diagram showing how the Splitter works internally, by using an iterator to iterate through the message and process each entry.

Figure 8.8. Splitting a complex message into submessages by department

Figure 8.9. A route that picks up incoming files, splits them, and transforms them so they’re ready for updating the inventory in the ERP system

Figure 8.10. The Splitter has a built-in aggregator that can recombine split messages into a combined outgoing message.

Figure 8.11. The incoming message has a slip attached that specifies the sequence of the processing steps. The Routing Slip EIP reads the slip and routes the message to the next endpoint in the list.

Figure 8.12. A Camel application load balances across two services.

Figure 8.13. Using a custom load balancer to route gold messages to processor 1 and other messages to processor 2

Chapter 9. Using transactions

Figure 9.1. Partner reports are received from the JMS broker, transformed in Camel to SQL format, and then written to the database.

Figure 9.2. A transaction is a series of events between begin and commit.

Figure 9.3. Spring’s TransactionManager orchestrates the transaction by issuing begins and commits. The entire Camel route is transacted, and the transaction is handled by Spring.

Figure 9.4. The Spring JmsTransactionManager orchestrates the transaction with the JMS broker. The Camel route completes successfully and signals the commit to the JmsTransactionManager.

Figure 9.5. A transactional client handles the client’s session with the receivers so the client can specify transaction boundaries that encompass the receiver.

Figure 9.6. A message is being moved from queue A to queue B. Transactions ensure the message is moved in what appears to be an atomic operation.

Figure 9.7. Using JmsTransactionManager as a single resource in a transaction. The database isn’t a participant in the transaction.

Figure 9.8. Using JtaTransactionManager with multiple resources in a transaction. Both the JMS broker and the database participate in the transaction.

Figure 9.9. A failure to process a message at the last step in the route causes the JtaTransactionManager to issue rollbacks to both the JMS broker and the database.

Figure 9.10. Using two independent transactions in a single exchange

Figure 9.11. A web service used by business partners to submit orders. A copy of the order is stored in a database before it’s processed by the ERP system.

Figure 9.12. A web service message causes the transaction to roll back, and a custom reply message is returned.

Figure 9.13. An Exchange has one UnitOfWork, which in turn has from zero to many Synchronizations.

Figure 9.14. Emails are sent to customers listing their invoice details. Before the email is sent, a backup is stored in the file system.

Chapter 10. Concurrency and scalability

Figure 10.1. Suppliers send inventory updates, which are picked up by a Camel application. The application synchronizes the updates to the ERP system.

Figure 10.2. A route picks up incoming files, which are split and transformed to be ready for updating the inventory in the ERP system.

Figure 10.3. Using the Concurrent Consumers EIP to leverage concurrency and process inventory updates in parallel

Figure 10.4. Messages pass from the first to the second route using SEDA. Concurrency is used in the second route.

Figure 10.5. Tasks from the task queue wait to be executed by a thread from the thread pool.

Figure 10.6. Caller and pooled threads are in use when a message is routed.

Figure 10.7. The web portal gathers information from three systems to compile the overview that’s presented to the employee.

Figure 10.8. In asynchronous InOnly mode, the caller doesn’t wait for a reply. On the Camel side, only one thread is used for all the processing of the message.

Figure 10.9. In synchronous InOut mode, the caller waits for a reply. In Camel, the consumer thread is used for all the processing of the message, and it delivers the reply to the waiting caller.

Figure 10.10. In asynchronous InOnly mode, the caller doesn’t wait for a reply. On the Camel side, multiple threads are involved during the routing of the message.

Figure 10.11. In synchronous mode, the caller waits for a reply. On the Camel side, multiple threads are involved during the routing of the message. The consumer thread has to block, waiting for the reply, which it must send back to the waiting caller.

Figure 10.12. A synchronous caller invokes a Camel service. The service lets the wire tap continue processing the message asynchronously while the service returns an early reply to the waiting caller.

Figure 10.13. The client submits tasks (Callable) to be executed asynchronously by ExecutorService, which returns a Future handle to the client.

Figure 10.14. The Rider Auto Parts web store communicates with the ERP system to gather pricing information.

Figure 10.15. A scalability problem illustrated by the thread being blocked (represented as white boxes) while waiting for the ERP system to return a the reply.

Figure 10.16. The scalability problem is greatly improved. Threads are much less blocked (represented by white boxes) when you leverage asynchronous communication between the systems.

Figure 10.17. The same thread services multiple customers without blocking (white and grey boxes) and without impacting response times, resulting in much higher scalability.

Chapter 11. Developing Camel projects

Figure 11.1. A Camel archetype and user input are processed by the Maven archetype plugin, which then creates a new Camel project.

Figure 11.2. Transitive runtime dependencies of the camel-ftp module. When you add a dependency on camel-ftp to your project, you’ll also get its transitive dependencies added to your classpath. In this case, commons-net, camel-core, commons-logging-api, and jsch are added. Additionally, camel-core has a dependency on commons-management, so that’s added to the classpath as well.

Figure 11.3. Final screen of wizard to import the chapter11-order-router project into Eclipse

Figure 11.4. Package Explorer view of the order-router project

Figure 11.5. The New Maven Project wizard allows you to generate a new Camel project right in Eclipse.

Figure 11.6. Right-clicking on the order-router project in the Package Explorer and clicking Run As > Maven Build will bring up the Edit Configuration dialog box shown here. The camel:run Maven goal has been entered.

Figure 11.7. A Component creates an Endpoint, which then creates Producers and Consumers.

Figure 11.8. A simplified view of a route where the consumer and producer handle interfacing with external systems. Consumers take messages from an external system into Camel, and producers send messages to external systems.

Figure 11.9. Applying an InterceptStrategy to a route essentially wraps each processor with an interceptor processor.

Figure 11.10. Interceptors are stackable, meaning the more InterceptStrategy classes you add to the CamelContext, the more interceptor processors will be added before each real processor is executed.

Chapter 12. Management and monitoring

Figure 12.1. A monitoring tool monitors Camel with a ping service by sending periodic HTTP GET requests.

Figure 12.2. The load balancer uses health checks to ensure connectivity before it lets the service calls pass through.

Figure 12.3. JConsole connects remotely to an MBean server inside the JVM, which opens up a world of in-depth information and management possibilities for Camel instances.

Figure 12.4. Camel registers numerous MBeans that expose internal details, such as usage statistics and management operations.

Figure 12.5. Using a wire tap to tap incoming files to an audit service before the file is translated to XML and sent to an order queue for further processing

Figure 12.6. Tracer sits between each node in the route (at , , and ) and traces the message flow.

Figure 12.7. Managing the Tracer from JMX allows you to customize the trace logging and change many attributes at runtime.

Figure 12.8. To enable tracing, select the CamelContext under the Context node and change the Tracing attribute from false to true.

Figure 12.9. Failure events must be published into the centralized error log database using the custom RiderEventNotifier.

Figure 12.10. Selecting the route to manage in JConsole

Figure 12.11. Adjusting a file consumer at runtime by changing the Delay attribute

Figure 12.12. Enabling the Verbose attribute at runtime using JConsole

Chapter 13. Running and deploying Camel

Figure 13.1. A Rider Auto Parts application accepting incoming inventory updates from either files or a web service

Figure 13.2. Using Camel with containers often requires the container in question to prepare and create CamelContext up front before it can be started.

Figure 13.3. Flow diagram showing how Camel starts by starting internal services, computing the starting order of routes, and preparing and starting the routes.

Figure 13.4. Camel application with two input routes and which depend on a common route

Figure 13.5. RoutePolicy changes the active state between the two routes so only one route is active at any time.

Figure 13.6. Camel embedded in a standalone Java application

Figure 13.7. Camel embedded in a web application

Figure 13.8. Using SoapUI testing the web service from the deployed application in Apache Tomcat

Chapter 14. Bean routing and remoting

Figure 14.1. Business partners send inventory updates to the partnerInventoryUpdate queue. These updates are then used to update the internal inventory database.

Figure 14.2. When an inventory update comes in, it’s used to update the inventory database and it’s also sent to the partnerAudit queue for auditing.

Figure 14.3. Each part of the business logic leverages middleware when communicating with the other parts.

Figure 14.4. The starter kit is used by business partners to hide the middleware and easily communicate with Rider Auto Parts.

Figure 14.5. A sequence diagram showing how a Camel proxy works under the covers, sending a BeanInvocation message to a remote endpoint and waiting for the reply, which eventually is returned to the caller

Appendix D. The Camel community

Figure D.1. Rider web tooling visualizes the route. You can drag and drop EIPs from the palette to the canvas to design the route at design time.

Figure D.2. Rider Eclipse tooling allows developers to design routes using the Eclipse IDE.

Appendix E. Akka and Camel

Figure E.1. The setup of the example application. A consumer and a producer actor provide connectivity to external systems. The consumer actor receives requests from a browser and forwards them to a producer actor, which fetches the HTML page. The HTML page is then forwarded to an actor that transforms the content of the page and returns the transformation result to the initial sender, so that it can be displayed in the browser.