camel on SWiK

Redneck FORD (Fuck-over-Rebuilt-Dodge) Caravan

Thu, 28 Aug 2008 18:14:08 -0700

One of my closest redneck friends always used to say that FORD stood for “Fucked-Up-Rebuilt-Dodge”.

Well, here’s a FORD Caravan.

Allow us to officially introduce the Car Camel. Apparently plying the highways of Ontario, Canada, it’s a shortened minivan with a car hauler stuck to its backside. It ain’t pretty, and it probably ain’t too fast, but we have to admit that it is pretty neat… if you’re into that kind of thing. Have a look at the gallery of images below, but if any of you get the idea to make a Car Koala… please, don’t. Thanks for the tip, Zak!

via autoblog

Brought to you by: Zedomax.com

Redneck FORD (Fuck-over-Rebuilt-Dodge) Caravan

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

Thu, 28 Aug 2008 18:04:36 -0700

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!

Apache Camel on OpenESB

Wed, 13 Aug 2008 10:06:15 -0700

Srinivasan Chikkala reports that support for Apache Camel has been added to OpenESB via the Camel Service Engine (SE) and shows how to use it in this screencast.

Apache Camel can be used for routing and mediation rules and adds one more option for defining the interactions between services to OpenESB by using a Java domain specific language (DSL), Spring based XML configuration, or the (work in progress) Scala DSL.

Louis took the new capability for a test drive with a detailed "how-to" write-up and his impressions in his quest to replicate the demo scenario shown in the Project Fuji preview at JavaOne this year.

The standards based pluggability of OpenESB allows this new component to leverage and be combined with any of the other 30+ components now part of the OpenESB community.

Apache Camel - Ohloh

Mon, 30 Jun 2008 07:09:18 -0700

Glen Mazza's Weblog

Fri, 27 Jun 2008 12:56:23 -0700

Using Camel with Maven to access web services and message queues - Glen Mazza's Weblog

Tue, 27 May 2008 01:19:09 -0700

[from rugi] Apache Camel: Index

Mon, 26 May 2008 16:21:53 -0700

Using Scala to create a better Camel DSL for Enterprise Integration Patterns

Wed, 16 Apr 2008 07:17:34 -0700

Gert Vanthienen has been doing some amazing work creating a DSL for Camel using Scala. I'm amazed at how neat and concise it is. Go Gert! :).

I'd previously experimented with Groovy and Ruby DSLs and found them to be little more verbose (e.g. having issues of needing to pass 2 closures/blocks to methods like when or filter, one for the predicate and one for the block to execute if its true).

You can grab his slides from the recent ApacheCon talk. I'm really liking it. The Scala use of separate syntax for functions/predicates and blocks helps improve the Camel DSL hugely

Using Scala to create Camel Enterprise Integration Patterns

Wed, 16 Apr 2008 06:17:11 -0700

Easier Integration & Pattern testing with Camel and Spring 2.5

Fri, 15 Feb 2008 08:40:41 -0800

I'm really liking the testing features in Spring 2.5.x for easier unit testing with JUnit 3.8, 4.x or TestNG using Spring to do all your dependency injection before invoking your test classes.

I've just created a little document to show how to use Spring Testing with Camel, using the Camel Mock and Test endpoints for easier Enterprise Integration Pattern based testing. Incidentally Camel now has a new little Test endpoint which creates a Mock endpoint that automatically pulls its expected message bodies from another endpoint and auto-wires up the expectations for easier testing with minimal coding.

Easier EIP testing with Camel and Spring 2.5

Fri, 15 Feb 2008 06:39:54 -0800

Apache ActiveMQ -- JBoss Integration

Wed, 09 Jan 2008 04:26:43 -0800

Feedback on my Camel talk at the IJTC conference

Tue, 13 Nov 2007 08:43:22 -0800

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 :).

Apache Camel: Message Translator

Fri, 02 Nov 2007 16:25:50 -0700

Message Translator

Apache Camel: Index

Tue, 23 Oct 2007 07:48:30 -0700

Apache Camel: Index

Thu, 04 Oct 2007 16:58:34 -0700

Golden Toolbox: Good frameworks

Thu, 30 Aug 2007 13:32:07 -0700

"I just finished a little data transfer utility using Apache Camel for the transport mechanism, Spring for the plumbing and then Terracotta to cluster the work on the server."

Enterprise Integration Patterns in Java using a DSL via Apache Camel

Sun, 27 May 2007 09:46:51 -0700

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

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

Sun, 27 May 2007 09:46:50 -0700

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 :)

XPath based splitter in one line of Java code

Sun, 27 May 2007 09:46:49 -0700

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 :)

SourceKibitzer Feed

Tue, 22 May 2007 07:43:29 -0700

ActiveMQ

Fri, 03 Jun 2005 18:29:18 -0700

ActiveMQ is a Message Broker and JMS 1.1 provider.

It supports:

clustering
peer networks
discovery
TCP
SSL
multicast
persistence
XA

In addition, it integrates seamlessly into J2EE 1.4 containers, light weight containers and any Java application.

ActiveMQ is included in SourceLabs Self-Support for Open Source Java offering.

Other message brokers

ActiveMQ competes with Microsoft Biztalk, Oracle Message Broker, Websphere Message Broker, and other proprietary message brokers.

ActiveMQ is the highest profile of the open source message brokers, and the most liberally licensed.

Proteus – proteus is an alternative message broker and framework that is licensed under the gpl.

Information on the latest (5.0) release

Apache Camel

Thu, 10 May 2007 01:50:18 -0700

Apache ActiveMQ -- Index

Tue, 01 May 2007 18:35:40 -0700

"Apache Camel is an (...) declarative Java based, type-safe Domain Specific Language POJO broker, which uses Enterprise Integration Patterns as its foundation." "[It] is a routing and mediation engine for the following: CXF, ActiveMQ, ServiceMix and MINA"

camel on SWiK

Redneck FORD (Fuck-over-Rebuilt-Dodge) Caravan

Related posts

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

Apache Camel on OpenESB

Apache Camel - Ohloh

Glen Mazza's Weblog

Using Camel with Maven to access web services and message queues - Glen Mazza's Weblog

[from rugi] Apache Camel: Index

Using Scala to create a better Camel DSL for Enterprise Integration Patterns

Using Scala to create Camel Enterprise Integration Patterns

Easier Integration & Pattern testing with Camel and Spring 2.5

Easier EIP testing with Camel and Spring 2.5

Apache ActiveMQ -- JBoss Integration

Feedback on my Camel talk at the IJTC conference

Apache Camel: Message Translator

Apache Camel: Index

Apache Camel: Index

Golden Toolbox: Good frameworks

Enterprise Integration Patterns in Java using a DSL via Apache Camel

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

XPath based splitter in one line of Java code

SourceKibitzer Feed

ActiveMQ

Other message brokers

Apache Camel

Apache ActiveMQ -- Index