Micro Services the easy way with Fabric8

Micro Services have received a lot of discussion of late. While its easy to argue the exact meaning of the term; its hard to deny there's a clear movement in the Java ecosystem towards micro services: using smaller, lighter weight and isolated micro service processes instead of putting all your code into monolithic application servers with approaches like DropWizard, Spring Boot and Vert.x. There are lots of benefits of the micro services approach; particularly considering DevOps and the cloud.

Fabric8 is poly app server

On the fabric8 project we're very application server agnostic; there are lots of pros and cons with using different application servers. The ideal choice often comes down to your requirements and your team's knowledge and history. Folks tend to prefer to stick with the application servers they know and love (or that their operations folks are happy managing) rather than switching; as all application servers require time to learn.

OSGi is very flexible, modular and standards based; but the modularity has a cost in terms of learning and development time. (OSGi is kinda marmite technology; you tend to either love it or hate it ;). Servlet engines like Tomcat are really simple; but with very limited modularity. Then for those that love JEE there's WildFly and TomEE.

In the fabric8 project we initially started supporting OSGi for managing things like JBoss Fuse, Apache Karaf, and Apache ServiceMix. If you use version 1.0.x of fabric8 (which is included in JBoss Fuse 6.1) then OSGi is the only application server model supported.

However in 1.1.x we're working hard on support for Apache Tomcat, Apache TomEE and WildFly as first class citizens in fabric8; so you can pick whichever application server model you and your team prefer; including using a mixture of container types for different services.

Fabric8 1.1.0.Beta5 now supports Java Containers

I'm personally really excited about the new Java Container capability which is now available in version 1.1.0.Beta5 or later of fabric8 which lets you easily provision and manage java based Micro Services.

A Java Container is an alternative to using an application server; its literally using the java process using a classpath and main you specify. So there's no mandated application server or libraries.

With pretty much all application servers you're gonna hit class loader issues at some point; with the Java Container in fabric8; its a simple flat class loader that you fully control. Simples! If things work in maven and your tests; they work in the Java Container (*); since its the same classpath - a flat list of jars.

* provided you don't include duplicate classes in different jars, where the order of the jars in the classpath can cause issues but thats easy to check for in your build).

The easiest, simplest thing that could possibly work as an application developer is just using a simple flat class loader. i.e. using the java process on the command line like this:

java -cp "lib/*" $MAINCLASS

This then means that each micro service is a separate isolated container (operating system process) with its own class path so its easy to monitor and perform incremental upgrades of dependencies without affecting other containers; this makes version upgrades a breeze.

However the problem with micro services is managing the deployment of all these java processes; starting them, stopping them, managing them, having nice tooling to view whats happening and performing rolling upgrades of changes. Thats where fabric8 comes to help! The easiest way to see is via a demo...

Demo

Here's a screencast I just recorded to show how easy it is to work with any Java project which has a maven build and a Java main function (a static main(String[] args) function to bootstrap the Java code. I use an off the shelf Apache Camel and Spring example; but really any Java project with an executable jar or main class would do.


For more background on how to use this and how all this works check the documentation on the Java Container and Micro Services in Fabric8.

Please take it for a spin and tell us how you get on. We love feedback and contributions!

Demo of Fuse 6.1 with Apache Camel and hawtio on OpenShift

Here's a screencast showing how to get started using JBoss Fuse 6.1 Early Access release on OpenShift for creating integration solutions based on Apache Camel in the hybrid cloud (via OpenShift Online for the public cloud or OpenShift Enterprise for on premise, or a combination of both).

JBoss Fuse 6.1 Early Access from JBoss Developer on Vimeo.

Watch it on vimeo for the HD version.

The screencast shows how to create and deploy EIP flows; change them, make rolling upgrades and visualise whats happening all from your web browser via the Fuse Console; which is implemented completely using the open source project hawtio.

If you want to try it out for yourself (everyone gets 3 free gears on OpenShift online!), try this quickstart or see the more detailed instructions.

I hope to create many more videos soon; showing many other aspects of Fuse on OpenShift (like creating A-MQ topologies, getting insight into whats really happening via ElasticSearch and the API registry support among others). Until then, enjoy! Feedback always appreciated.

a sneak peek at whats coming in JBoss Fuse 6.1

I'm really excited about the forthcoming Fuse 6.1 release as there's a ton of awesome new features which I've really wanted for some time and some really hawt tooling :).

So here's a quick sneak peek, focussing mostly on the new version of the Fuse Management Console (which is now implemented by hawtio open source project).

A-MQ

First let me show you the A-MQ topology view which lets you view and create topologies of Apache ActiveMQ brokers in your fabric.

The green background is used to show the master broker (see the top row, the green master is on the left, the grey background container on the right is the slave). If in doubt, hover over the containers and the tooltip tells you whats going on or click on things to dive into the detail views.

For containers which are inactive, the green play icon becomes an orange stopped icon (or you see the provisioning icons as containers startup, download, provision etc). This view is real time so you can watch containers startup (which can take a little while if you're using small gears on OpenShift ;).

If you click on the connect icon inside each container box, it takes you straight inside that broker; so you can view the destinations & see all the detailed metrics etc.

Incidentally the numbers in green badges next to the profile names show the number of containers running versus the required target number (like the new profile screen shows - see example below - the Target (requirements) versus Count (actual) columns). Again the tooltip gives a detailed explanation if you're unsure

e.g. if you create a new broker config for a replicated broker; it by default creates a requirement for 3 containers to run for that profile (broker configuration); then you'd get a red icon until enough containers are running - and clicking the red badge takes you to the create containers page.

On OpenShift we've an auto-scaler, so as you add a new broker configuration, the containers would spin up immediately once the configuration is saved and you can watch them visually spin up (cool eh!).

To setup your own broker topology click the + Broker button to add new broker configurations (Stand Alone, Master / Slave, N + 1 or Replicated) and define the groups of brokers.

When using Fabric you can put brokers into groups (or 'regions'). A group is just a name (or a path "us/east" if folks prefer); its just a String which is used to look in the right bit of ZooKeeper to find the brokers to connect to. So it can be a tree; though usually folks requirements are simple enough to just have either 1 global region; or have, say, 3 for different geo locations.

We can have a bunch of brokers in different groups, say, us-east, us-west, emea and messaging clients can then just use the right group name to connect to the right group of brokers. We use groups too for defining store/forward networks between groups. e.g. the us-east brokers may need to also store/forward with us-west brokers; they typically don't care which broker they connect to - but just need to connect to a broker within the right group. 

We can then create Fabric profiles for clients which are location specific. e.g. if you've a 'cheese' application (some web service or web app or whatnot) that needs to connect to A-MQ; we can have a cheese-us-east profile; which the only thing that profile does is it inherits from 'cheese' and just specifies the A-MQ group name of "us-east' to connect to.

Longer term we hope to align the broker groups with OpenShift's DNS/applications; so folks not using Fabric at all can just have the regions mapped to DNS names; e.g. "broker-us-east-foo.rhcloud.com" would be the host name to connect to an A-MQ broker and under the covers it does the DNS / haproxy crack to connect you to the right broker - without requiring any magic on the client side (other than knowing the right DNS/host name for the right group).

Dashboards

Also new in 6.1 is profile specific dashboards; so you can create custom dashboards for any profile which is based on the services running in that exact profile (i.e. a specific group of containers); then any container you connect to via the Fuse Management Console you get a nice easy view of the right things you want to see for that kind of profile. 

e.g. here's the default real time dashboard:

you can resize, move and add/edit/delete views in the usual way. Pretty much any UI in Fuse Management Console (which includes all the hawtio plugins) can be used as a rectangle on the dashboard; so you could add camel route metrics, log file searches or whatever).

Dashboards are then versioned and stored with all the other configuration. Which brings me to the configuration side...

Configuration gets git hawtness

Fuse Fabric is designed to make it really easy to manage large clusters of containers in a simple way; so you can group containers into profiles. Then you can configure the profile & choose the exact deployment artefacts once and all the containers are updated immediately. You can use profile inheritance so you can configure groups of containers differently; e.g. use regional changes to some configuration values; increase the RAM/cache/disk usage settings on bigger boxes etc.

Finally you can version your profiles; so that rather than changes to a profile becoming immediate on all containers; you can create a new version; edit the profiles - then perform a rolling upgrade; choose which containers to upgrade, try them for a while, if things look good, roll more containers to the new version - or rollback if things go bad.

In Fuse 6.1 we have support for working with the configuration using the git source control system and its associated tools. This means that all changes to configuration, deployment units, dashboards, the wiki, camel routes and broker topologies all has a nice audit log of who changed what when; its easy to use all the available git tools to do diffs and revert changes, merge between branches/repos etc. 

This means the configuration can work nicely with Continuous Integration and Continuous Deployment systems (e.g. using gerrit and jenkins). e.g. define all your profiles and configuration in development; then through Continuous Integration and Continuous Deployment builds and code review systems like gerrit, merge changes from development -> integration test -> soak test -> production etc.

Using git with Fuse 6.1

If you view any container's page like below and click on the URLs tab:

it shows the git url; so just do a git clone of that; then checkout the branch for the version you want to work with. (In 6.1 of Fuse, a version maps to the name of a branch in git).

git clone http://localhost:8181/git/fabric
cd fabric
git checkout -t origin/1.0
ls -al fabric/profiles

you can then hack on the profile data using any editor you like (they are just folders of config files) then commit and git push to make the changes active! Or make your own branches and so forth.

Whats really cool is that the wiki (where you can document all your applications and profiles) is versioned in the same git repository as your dashboards and configuration. So if you add a new version of a service in a new version of a profile; the dashboard can be updated to show new metrics; then whatever version is running you see the right wiki, documentation and dashboard for the exact version!

Camel editor and debugger included

Last but not least; 6.1 includes web based editing, viewing (with real time metrics and debugging of camel routes. The camel routes can be versioned in profiles; so you can do rolling upgrades of your camel routes with all changes audited and browsable in a git repository.

Summary

No blogging for months and then I write a huge post, sorry! :) 

If the above was too long just think, Fuse 6.1 has an awesome improved web console (based on the hawtio open source project) and lets you work with all the configuration in git so all changes are audited and you can easily combine Fuse 6.1 with any git, Continuous Integration or Continuous Deployment tooling for all your provisioning & configuration data.

There's lots more 6.1; I'll have to try blog more often ;)

CamelOne and Scala eXchange were awesome!

Its been a busy few weeks lately! 3 weeks ago we had CamelOne which was a really great conference; one of the best I've been to for a while. Great talks & conversations - loads of energy around the Apache Camel community. I'm already looking forward to the next one! We should have the various presentations from it online.

I got the chance to demo the new beta of Fuse IDE which is coming out soon; its packed with some really awesome features for working with ActiveMQ, Camel and ServiceMix. We're hard at work getting that ready...

Then yesterday I had the pleasure of giving the day 2 keynote at Scala eXchange in London. I had heaps of fun, met loads of the Scala folks I've only met online before (including Martin, finally!) & even managed to get a few laughs in my talk (mostly at JSPs expense I think :). It was a very similar conference to CamelOne in many ways; heaps of fun, loads of energy & passion around and lots of fun was had by all.

My keynote was on the Scalate template engine; there's details here or go straight to the slides or video. The samples I used in the talk are in github.

Wanna try our Apache Camel developer tools for Enterprise Integration Patterns?

When I first created Apache Camel one of my design goals was to let folks describe the Enterprise Integration Patterns as easily as possible using concise and declarative domain specific languages instead of reams of confusing opaque bean configurations.  So whichever the developer prefers, a DSL in Java, XML, Scala, Groovy, Ruby etc. It was always part of the plan to actually have a visual domain specific language too and we've finally created one.

We're just starting the public beta of Fuse IDE for Camel, our Eclipse tool suite that lets you visually create, edit and configure Enterprise Integration Patterns easily using Apache Camel and its huge selection of patterns and components.

If you use Apache Camel or have always meant to give it a try then please install it, take it for a spin and see what you think. We'd love to hear your feedback on the tool & how we can improve it!

We've lots of things planned for the tool; this is just the beginning...

Fuse Community days in NY & SF next week - come hear about ActiveMQ, Camel and ServiceMix

Next week we're hosting two Fuse Community day events in the states

• Tuesday 8th December - New York at the Hyatt Hotel in New York City
• Thursday 10th December - San Francisco at the Hyatt Hotel in Burlingame

If you're in the area pop by and say hello - you'll need to register on the above links.

We'll have a bunch of presentations on various popular open source Apache projects like ActiveMQ, Camel and ServiceMix. Schedule in the links above. See you there if you can make it!

Here's a flavour of what to expect, the devoxx talk I did recently.

Apache Camel 1.6.0 released - 2.0 not far away!

Both Claus and Jon beat me too it, so being lazy am just gonna link to their posts. You can grab the latest Apache Camel 1.6.0 release with its 169 improvements on top of the 266 improvements from the 1.5 version.

Get it while its hot! Work is progressing well on 2.0 which will hopefully be out soon too! Great work Camel Riders!

Apache Camel goes top level!

Apache Camel is now a top level project at Apache - you can find it at http://camel.apache.org/. Yay! 

Many thanks to all the Camel Riders who made this happen!

Liking the File language in Camel 1.5.0

Claus has a great write up on the new File language feature in Camel 1.5.0 - cool stuff! I'm really looking forward to the next release!

A favorite feature of mine in the next Apache Camel is a new feature to use file name patterns in the file component. What we have introduced is a new language, the file language, so you can leverage this feature anywhere in Camel where it uses Expressions, Languages etc. The file language currently support both the file and the FTP component as well.

As a lot of integrations is file based you need to be able to read (consume) or write (produce) files. Then you need to be able to specify file names. What's new in Camel 1.5.0 is that you can express this using patterns, for instance directly in the configuration of your endpoints. Prior you had to do this in Java code.

Simple example
Lets image you need to move consumed files into a backup folder after processing.

Now you can express this using the pattern: backup/${file:name}
Well then you need to use .bak as extension, and the pattern is:backup/${file:name}.bak

Okay next issue is that the backup folder should be grouped by dates using the yyyyMMdd pattern. Well the expression support thejava.text.SimpleDateFormat patterns also.
The pattern is:backup/${date:now:yyyyMMdd}/${file:name}.bak wherenow means current date. You can substitute this with different commands such as file for using the timestamp on the file instead.

Advanced example
In this sample you need to produce files (save) and you need to save the file using a generate unique filename. We use the divide and conquer pattern for this so you create a POJO class that generates the unique filename, then you as the developer have the full power how to do this. And then its very easy to unit test as its plain POJO that can be tested very easily with JUnit. Next step is to express this as a file pattern. As your POJO is a bean we use the bean langauge to invoke your pojo.

So the pattern is: myfile-${bean:myguidgenerator.generateid}.txt
Where myguidgenerator is the bean id of your POJO and generateidis the method name. You can omit the method name if there is no ambiguity which method Camel should invoke.

Camel routes
This feature is configurable directly in camel routing on your endpoints. So what we can do now is:

from("file://inbox?expression=backup/${date:now:yyyyMMdd}/${file:name}.bak").to("bean:processFile");

The route will consume files and process the files in the processFile bean, that is a plain POJO class. After processing the files is moved (renamed) using the pattern in the expression. So the file is moved to the backup subfolder, for example: backup/20081014/report-october-2008.bak

More to come
Well there is a ton of new features and improvements in Camel 1.5.0. Check out the current release note.

Enterprise Integration Designer preview

From Oisin's blog.

Thanks to Enterprise Integration Patterns, architects have a clear and succinct way to describe integration within complex systems. It certainly beats a lot of MS-Word documents and monster integration architecture diagrams. And, with Apache Camel, we’ve got an open source runtime that allows us to create routes by chaining EIPs together, using Spring XML or Java fluent builders. That’s fantastic, but EIPs are as much about sharing pictures as creating message routing graphs, and where are the pictures?  

We’ve made some tools that will allow you to load up Camel Spring XML files into Eclipse for visual inspection and editing. You can also create EIP diagrams in your Workbench and save them as Camel configurations. Finally, we’ve put in some debugging capabilities to allow you trace through the paths a message will take through your EIP graph.  

We are earnestly seeking feedback - check out the FUSE Integration Designer Preview page to download the Eclipse plugins, or check out the video links under the Training Videos at the bottom of the page.

Looks great! Feedback greatly appreciated

Using Camel with ServiceMix Kernel

Gert has a great post on ServiceMix Kernel and Camel showing how easy it is to take ServiceMix Kernel, install Camel into it and then deploy a route using a simple Spring XML file. Nice job Gert!

Apache ServiceMix Kernel 1.0.0 released!

via Guillaume's post

Apache ServiceMix Kernel 1.0.0 has just been released.

Apache ServiceMix Kernel is a small OSGi based runtime which provides
a lightweight container onto which various bundles can be deployed.
Amongst the list of supported features, Apache ServiceMix Kernel supports:

• hot deployment of OSGi bundles, exploded bundles or custom artifacts (spring xml configuration files support is provided)
  
• services configuration stored as property files are monitored and provided as standard OSGi configurations
  
• a centralized logging back end supported by Log4J, ServiceMix Kernel supports a number of different APIs (JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi)
• provisioning of libraries or applications can be done using simple commands via simple xml descriptors
  
• native OS integration as a service so that the lifecycle will be bound to your Operating System.
  
• an extensible shell console to manage services, applications and libraries
• operations on the console can be done remotely via a secured and encrypted channel
  
• a security framework based on JAAS
• new instances can be created using a single command line

This release, with the detailed release notes, is available at:
http://servicemix.apache.org/kernel/servicemix-kernel-100.html.

I'm particularly pleased to get the 1.0.0 release out; it makes it really easy to have hot-redeployable Camel routing rules - just edit your Spring XML when using the expanded bundle mode and ServiceMix will auto-redeploy your routing rules dynamically!

Neat eclipse templates for working with the Java or Spring DSLs for Camel

If you're an Eclipse user who works with Camel you might be interested in the Eclipse templates that Jon has just created - nice work Jon!

Feedback on my Camel talk at the IJTC conference

Thanks to John for the great feedback on my Camel talk (and other talks too). I started to write a huge reply and figured I'd post it here instead then link to it as its easier to reply to different parts.

Camel itself is not an ESB per-se, it is a component of an ESB

Agreed. The idea is Camel does the routing and Enterprise Integration Patterns - you can then use it inside a web service stack like Apache CXF, a message broker like Apache ActiveMQ or an ESB like Apache ServiceMix

1. One of the key messages that came out of the session was how Java-centric the Camel solution is - Strachan went so far as to articulate the view that coding in XML was a fundamentally bad idea.

Maybe being the author of Jelly and hating writing XSLT has made me a bit too sensitive to the idea of programming by XML. Quite a few customers I talk with report frustration of too much XML hacking with Spring (which is being addressed in Guice and Spring 2.5). But heck if you like programming in XML be my guest :)

He went on to cast aspersions on graphical tools also. His clear preference was that integration logic should be written in Java. Given that I have worked with highly skilled Java developers for many years now I was not too surprised to hear this - many good developers shy away from tooling, seeing it as compromising their style or the power of the underlying framework - hence the longevity of vi and emacs I suppose.

I didn't mean to cast aspersions on graphical tools; more that pretty much all developers understand Java these days, its pretty universal - whereas most complex graphical tools require a fair amount of learning to get used to them.

Personally I totally prefer writing in Java rather than XML or using visual tooling but one of the main requirements of Camel is that you can configure and specify routes in any way you like - via a graphical IDE (e.g. Cimero) or via XML or Java or Groovy or Ruby or one day hopefully a real DSL. Using XML is quite useful as you can just drop your routing rules inside a spring XML file such as inside the Apache ActiveMQ.

So we're working hard to allow folks to specify routing rules however they like - despite what I prefer :). Irrespective of how you write your routing rules, we can visualise them so anyone can easily understand them.

However it is important to note that all developers are not middleware experts and have no wish to be. Indeed the enterprises they work for want their developers to spend as little time and effort as possible on middleware plumbing. They need and demand tools which will enable them to get at least 80% of patterns done without having to understand the middleware architecture, it's threading model,

Thats one of the main things we're trying to attempt with Camel - letting folks who are not middleware experts easily use the Enterprise Integration Patterns using a single line of Java code - using any transport or component with minimal configuration required.

it's support for configurable expression languages etc.

I find it hard to understand how any tool can be usable by folks without some kind of expression language that they understand - whether its Java or SQL or XPath/XQuery or whatnot. Even a visual query definer is a language that users need to know.

Most people express their requirements in a declarative way- I have data at A that needs to get to B, on it's way I need to perform transformation, validation, logging etc. (indeed the EIP book itself does this) . However Camel has taken a very Java centric approach and I think this increases it's complexity unnecessarily.

We are actually trying to be as declarative as possible - don't let the fact that you can use Java as the DSL confuse you. e.g. here's what you just described in Camel using a single line of Java code...

from(a).
to("xsd:org/cheese/something.xsd").
to("xslt:com/acme/mytransform.xsl").
to("log:com.acme.MyLogger").
to(b);

Its hard to be more concise than that in Java code. But sure - you could use some other language or XML or UI tool etc

2. Camel presents transports as nice-simple looking endpoint URIs in Java. However configuration of these transports may not be as simple as it seems. There appears to me to be a potential disconnection between the Camel processors and the Camel Components in terms of configuration.

You can always configure anything in Camel via Java or Spring; a component, endpoint, processor etc. The URI is just a shorthand notation for configurating things; which tends to work well with endpoints as usually all the smart configuration is in the component.

In the presentation processors use endpoints which can be configured using Spring within Camel. However it would appear that many of the component implementations are inherited from ServiceMix and these properties will need to be set presumably within the ServiceMix container configuration?

Not so - all the components are configured in Spring via Camel. If you want to talk to ServiceMix components and endpoints you can use the NMR and the JBI endpoint.

When you have multiple XML configurations to use a transport then the pretty looking URI is hiding a lot of complexity under the hood.

I hear you. We've tried very hard to make things as easy as is possible with minimal configuration; for example most configuration tends to be on the Component rather than the Endpoint. But you can configure things however you like in Java code or Guice or Spring.

3. Some of the pattern implementations look a little short on credibility - take the aggregator pattern for example the "aggregator" pattern does not seem to have the concept of a store - so in essence one must have access to all of the messages which require aggregation or must hold aggregations in memory for the configurable timeout period. This will clearly not work in a scalable way. Likewise as regards clustering - if you are looking to aggregate 2 messages and they turn up on different servers you gotta problem.

You're right I purposely missed out some of the detail on a few slides (such as specifying some kind of persistence store or strategy for aggregator or for idempotent consumer) but that is easily done via a pluggable strategies Spring beans. However just because I missed out some detail on some slides (its kinda hard in an hour to present all the detail in all the patterns as well as the rest of Camel) please don't think that somehow Camel isn't short on capabilities.

To summarise Camel is clearly a worthy set of widgets and they will work for very simple applications without Enterprise requirements.

Ouch :). We've actually lots of customers using Camel today in production with very Enterprise requirements. Apache ActiveMQ 5.0 actually ships fully integrated with Camel so we've tons of users in production using Camel today.

I hope I've managed to straighten out some misunderstandings on Camel; its definitely a great fit for enterprise requirements. Thanks for your great feedback - I'll definitely take it on board on future presentations and try and avoid confusing other folks :).

XPath based splitter in one line of Java code

This came up in a recent thread & thought I'd mention it here for those not on the list. If you want to implement the Splitter Pattern from the Enterprise Integration Patterns using XPath then you can use the following line of Java code...

from("activemq:my.queue").
 splitter(xpath("/invoice/lineItem")).
 to("file://some/directory");

Pretty neat eh. Use any language you like for the expression such as XQuery, SQL, Groovy, Ruby etc.
It sure beats programming in XML :)

Mock JavaMail rocks. Mocking out protocols and services is damn useful

If ever you find yourself needing to test some JavaMail code, I highly recommend Mock JavaMail. It does exactly what it says on the tin & is very useful. Its yet another project from the incredibly prolific Kohsuke - nice job! We're using Mock JavaMail on Camel to test our Mail Integration and its been soo useful.

All APIs to messaging & integration systems and protocols should have some Mock testing library to allow developers to create easy unit tests and to save them having to mock complex services (which you're never sure your mocks are faithful to the underlying systems & protocols).

For JMS we can use ActiveMQ. For Camel and JBI we have Mock Endpoints (which I wish we had years ago, it'd have made developing ServiceMix much easier). For files you can just use your local file system; for databases you can use Derby, HSQLDB or H2. For HTTP/REST you can just embed Jetty.

I guess the missing things are things like XMPP and FTP. Anyone seen any other interesting mock projects for specific protocols, APIs and services? (Yes I know about jMock :)

Enterprise Integration Patterns in Java using a DSL via Apache Camel

For those of you who missed me rambling about this at JavaOne I thought I'd introduce Camel to you.

Apache Camel is a powerful rule based routing and mediation engine which provides a POJO based implementation of the Enterprise Integration Patterns using an extremely powerful fluent API (or declarative Java Domain Specific Language) to configure routing and mediation rules.

The Domain Specific Language means that Apache Camel can support type-safe smart completion of routing and mediation rules in your IDE using regular Java code without huge amounts of XML configuration files; though Xml Configuration inside of Spring 2 is also supported.

A good way to get started is to take a look at the Enterprise Integration Patterns catalog and see what the Java code of an example looks like. For example, try the message filter, content based router or splitter.

Apache Camel is heavily influenced by the fluent APIs or Java DSLs used in projects like jMock for testing mock objects and LiFT for testing web applications (both of which are great frameworks BTW), where Camel's primary focus is on the easy creation of routing & mediation rules (and all the Enterprise Integration Patterns) together with testing them.

One of the things I'm most proud of is the Mock endpoint support which makes it very easy to test that your routing and integration rules do what you think they do; rather like with jMock you can create expectations up front (things that at the end of the test you expect to happen) then fire in some messages to some endpoints; then assert that things arrived at the mock endpoints as you expected. This includes adding jMock/LiFT style assertions on things; such as the second message received on a specific mock endpoint has a header called "foo" of value "bar". This can be expressed as

endpointA.message(1).header("foo").isEqualTo("bar")

All with nice Java IDE smart completion. I've really wanted something like Camel for a while; a nice easy way to configure EIP rules without having to resort to reams of XML - plus being able to test things in a distributed message based system easily is very useful.

Incidentally if you're curious of the name, here's why we called it Camel