Apache Camel - Spring

Though Apache Camel come with lot of examples , when I was totally new to Camel I found it a bit difficult to follow. I couldn't find a simple example to get me started in google as well. Here is a simple Camel-Spring example.


Before we start, 


What is Camel?
Apache Camel is an Open Source Integration Framework based on known Enterprise Integration Patterns


Need for Camel,


For Integrating Systems , you have few options like,


Option 1, Develop a custom solution. This Works & Fastest for small use cases
Option 2, Use Integration framework.


Cons,

  • Framework do the heavy lifting
  • Focus on business problem
  • Not "reinventing the wheel“

Option 3, Enterprise Service Bus. But ESB's are more than a integration framework, many uses may not need that complexity.


Since you are here, I assume , you have decided to go with Option 2. Camel won't disaapoint you. Now Let's get our hands dirty,


What all you need?


1. apache-activemq , Download here
2. apache-camel


What are we trying to do?


Very simple scenario, I need to read from a message queue and save the message to file. [You may never face such a use case but, good enough to explain the concepts]




(Step 1) Set Java Home and the Java path
(Step 2) Set Up Your Queue



  • Unzip apache-activemq
  • For windows, go to apache-activemq-5.5.1\bin\win32
  • Run activemq.bat
  • Once the mq is started, go to http://localhost:8161/
  • On the home page, click on Manage ActiveMQ broker
  • One the page opened you will find a link "Queues", Clictk on "Queues"
  • Give a name, say IN_QUEUE, for your queue in the text box. Click "Create"

Now you test message queue is ready.


Before we go further, there are few things in Camel, you should know,


Camel consists of a CamelContext which contains a collection of Component instances.


Components are the extension point in Camel to add connectivity to other systems. Endpoint where the message comes in or leaves the integration layer. Acts rather like a URI or URL in a web application or a Destination in a JMS system; you can communicate with an endpoint "c:/tmp", you could use URIs like "jms:aQueue" and "file:c:\tmp .


Processors are used to manipulate and mediate messages in between Endpoints. The Processor interface is used to implement consumers of message exchanges or to implement a Message Translator.


To wire Processors and Endpoints together, Camel defines a DSL Camel provides Java DSL, Spring XML, Scala etc.


We trying implement this use case with Camle Spring support.


So we leave few things to Spring like create the Camel Context, Define your Compoent.Now in this use case we have two Component, a JMS component and File Component.


Step 3 [As precondition, you need to create the Java Project in you IDE and add required the jar files to the build path]




(a) Create spring-demo.xml






(b) Create a class which extends RouteBuilder, This is where you configure your 'Route'. Route connects Components through the Endpoints. Routes are defined using DSL. Here we use Java DSL


@Override
public void configure() throws Exception {
from("jms:queue:IN_QUEUE").
to("file://D:/Work/My Workspace/Camel/springout");
}




The code says get message 'from' IN_QUEUE and transfer 'to' a file. Now how do you test this code ?


For that you need some one to put messages to your IN_QUEUE. Let's write one the Camel way. I created another xml , to create a new Camel Context. Basically I wanted the client to be used else where.


Here is my client-spring.xml






This is my Client code,






Now for the test,


First run the server or the class which extends RoutBuilder


java -duration 60s -fa /META-INF/spring/spring-demo.xml


This will keep the server live and keep looking for messages.Now just run the Client code to put the message.You should see the file created in the out put folder.

Evolving Architecture ...

Recently I heard some one using the term 'Evolving Architecture'...

I'm wondering how much an architecture can 'evolve'. If architecture can evolve, then how much 'architecture' should be there in the beginning ?

During the days of water fall projects , we had the fully signed off (no really though ;o) ) architecture before we start anything. But now in the days of iterative development , this may not the be case.

So should we allow the architecture to 'evolve' or create a full blown architecture before we start ?

I think it should be some where in between !!!

There are some decisions we should not defer, till we run into problems..

Identify the architecturally significant pieces and create structure and strong foundation for those in the beginning..

If you are deferring something for later..be sure you are aware of the consequences..

Any thoughts ?