Category: apache Camel

Apache Camel – Features Having seen an overview of Apache Camel, let us now delve into its features to see what it offers. We already know Apache Camel is an open source Java framework that essentially provides an implementation of various EIPs. Camel makes the integration easier by providing connectivity to a very large variety of transports and APIs. For example, you can easily route JMS to JSON, JSON to JMS, HTTP to JMS, FTP to JMS, even HTTP to HTTP, and connectivity to Microservices. You simply need to provide appropriate endpoints at both ends. Camel is extensible and thus in future more endpoints can be added easily to the framework. To wire EIPs and transports together, you use Domain Specific Languages (DSLs) such as Java, Scala, and Groovy. A typical Java routing rule may look like − from (“file:/order”).to(“jms:orderQueue”); This routing rule loads the files from the order directory, creates a JMS message with the contents of the file and sends that message to a queue called orderQueue. Here are some of the most important features of Camel that you would find useful in developing Camel applications − Camel supports pluggable formats and type converters for such message transformations, so new formats and converters can be added in future. Currently, it supports several popular formats and converters; to name a few – CSV, EDI, JAXB, JSON, XmlBeans, XStream, Flatpack, Zip. Camel supports pluggable to write predicates in DSL. Some of the supported languages include JavaScript, Groovy, Python, PHP, Ruby, SQL, XPath, XQuery. Camel supports the POJO model so that you can plug in Javabeans at various points. Camel eases testing of such large distributed and asynchronous systems by using messaging. Let us now understand the architecture of Camel and see how the various features are implemented.

Apache Camel – Architecture The Camel architecture consists three components − Integration Engine and Router, Processors, and Components. This is illustrated in the following figure − The Camel core itself is very small and contains 13 essential components. The rest 80+ components are outside the core. This helps in maintaining a low dependency on where it is deployed and promotes extensions in future. The Components module provides an Endpoint interface to the external world. The Endpoints are specified by URIs, such as file:/order and jms:orderQueue that you have seen in the last chapter. The Processors module is used for manipulating and mediating messages between Endpoints. The EIPs that I mentioned earlier are implemented in this module. It currently supports 40+ patterns as documented in the and other useful processing units. The Processors and Endpoints are wired together in Integration Engine and Router module using DSLs. While wiring these, you may use filters to filter messages based on user-defined criteria. As mentioned earlier, you have several options in writing these rules. You may use Java, Scala, Groovy, or even XML for this. Now, we come to the most important component of Camel, which may be considered as the core − the CamelContext.

Apache Camel – Components Camel provides several pre-built components. In this chapter, we will discuss a few important components from the camel-core module. Bean The Bean component binds beans to Camel message exchanges. The URI to create an Endpoint is specified as bean:beanID, where beanID is the name of the bean as specified in the Registry. JndiContext jndiContext = new JndiContext(); jndiContext.bind(“MilkOrder”, new MilkOrderProcessor()); CamelContext camelContext = new DefaultCamelContext(jndiContext); camelContext.addRoutes(new RouteBuilder() { public void configure() { from(“direct:bigBasket”) .to(“bean:MilkOrder?method=placeOrder”); } }); Note how the endpoint is specified using the bean: protocol. You may optionally specify the bean method that is to be invoked; in this case, the method called placeOrder will be invoked while evaluating the Endpoint expression. The MilkOrder is a JNDI name to the MilkOrderProcessor Javabean as registered in the first two lines of the code snippet. The definition of MilkOrderProcessor itself is omitted here for brevity. Direct You must have noticed the use of Direct in our previous examples. To send an order to an oil vendor, we used direct:oil in the Endpoint specification. The use of Direct component allows you to synchronously invoke an endpoint. The following two code snippets from our previous examples illustrate the use of Direct − .when(header(“order”).isEqualTo(“oil”)) .to(“direct:oil”) And, from(“direct:DistributeOrderDSL”) .process(myProcessor); File The File component provides access to the file system on your machine. Using this component, you will be able to save messages from other components to a local disk. In addition, it allows other Camel components to process the local files. You may use either file:directoryName[?options] or file://directoryName[?options] as a URI format while using the File component. You have earlier seen the use of this component − from (“file:/order”).to(“jms:orderQueue”); Note that the File component by default takes the directory name. Therefore, the contents of the order directory will be taken as input contents. To specify a particular file in the order directory, you will use the following statement − from (“file:/order?fileName = order.xml”).to(“jms:orderQueue”); Log The Log component allows you to log messages to the underlying logging mechanism. Camel uses Simple Logging Facade for Java (SLF4J) as an abstraction to various logging frameworks. You may use java.util.logging, logback, log4j for logging. This code snippet illustrates the use of the Log component − from(“direct:DistributeOrderDSL”) .to(“bean:MilkOrder?method = placeOrder”) .to(“log:com.example.com?level = INFO&showBody = true”); SEDA The SEDA component allows you to asynchronously call another endpoint in the same CamelContext. If you want to call across CamelContext instances, you need to use VM component. The use of SEDA is illustrated here − from(“direct:DistributeOrderDSL”) // send it to the seda queue that is async .to(“seda:nextOrder”) In this route, we will simply route the orders to nextOrder asynchronous queue. A client who has subscribed to this queue will pick up the messages from this queue. Timer The Timer component is used for sending out messages at regular intervals and can thus be very useful while testing Camel applications. The code snippet here fires a test message to the console every two seconds − from(“timer://testTimer?period = 2000”) .setBody() .simple(“This is a test message ${header.timer}”) .to(“stream:out”);

Apache Camel – Introduction Consider a situation where a large online grocery store in your town such as the Bigbasket in India invites you to design an IT solution for them. The stable and scalable solution will help them overcome the software maintenance problems they are facing today. This online store has been running its business for the last decade. The store accepts online orders for different categories of products from their customers and distributes those to the respective suppliers. For example, suppose you order some soaps, oil and milk; these three items will be distributed to the three respective suppliers. The three suppliers will then send their supplies to a common distribution point from where the entire order will be fulfilled by the delivery center. Now, let us look at the problem they are facing today. When this store started its business, it was accepting orders in a comma-separated plain text file. Over a period of time, the store switched to message-driven order placement. Later, some software developer suggested an XML based order placement. Eventually, the store even adapted a web service interface. Now, here comes the real problem. The orders now come in different formats. Obviously, every time the company upgraded the order acceptance format, it did not want to break the previously deployed interface so as not to cause confusions in the customer’s mind. At the same time, as the business kept on growing, the store periodically added new suppliers to its repertoire. Each such supplier had its own protocol for accepting orders. Once again, we face the integration issue; our application architecture must be scalable to accommodate new suppliers with their unique order placement mechanism. The entire situation is shown in the following figure − Now, let us see how Apache Camel can come to your rescue to provide an elegant, maintainable, scalable solution architecture for the described scenario. Before we proceed with the solution, we need to make a small assumption. For all the discussions in this tutorial, we will assume that the online orders are placed in XML format. A typical format for the order file that we will be using throughout our discussions is shown here − <?xml version = “1.0” encoding = “UTF-8”?> <OrderID Order = “001”> <order product = “soaps”> <items> <item> <Brand>Cinthol</Brand> <Type>Original</Type> <Quantity>4</Quantity> <Price>25</Price> </item> <item> <Brand>Cinthol</Brand> <Type>Lime</Type> <Quantity>6</Quantity> <Price>30</Price> </item> </items> </order> <order product = “Oil”> <items> <item> <Brand>Saffola</Brand> <Type>Gold</Type> <Quantity>2</Quantity> <Price>649</Price> </item> <item> <Brand>Fortune</Brand> <Type>Sunlite</Type> <Quantity>1</Quantity> <Price>525</Price> </item> </items> </order> <order product = “Milk”> <items> <item> <Product>Milk</Product> <Brand>Amul</Brand> <Type>Pure</Type> <Quantity>2</Quantity> <Price>60</Price> </item> </items> </order> </OrderID> We will be using the above XML template to illustrate the Camel examples in this tutorial.