• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Camel vs Spring Integration. Part 2.

 
Ranch Hand
Posts: 491
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have no idea about Spring Integration until I came across it today. I am not an expert with Camel either.

So why re-invent the wheel? rather the thread as I just read it where Camel expresses:

https://coderanch.com/t/515218/oa/Camel-vs-Spring-Integration

Now is the time for Spring Integration to express its valuable thoughts.

When to use Spring Integration and when to use Apache Camel? 1M Thanks.
 
author
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've never really understood the "reinventing the wheel" metaphor, especially in a technology context. After all, would we really be better off today if our cars still had wooden wheels with a fixed axle? ;) The truth is, not only have wheels evolved, but there are different kinds of wheel (and tire) with different uses in mind, and therefore with different strengths and weaknesses. Likewise, in the software world, it's a Good Thing(tm) to have multiple frameworks, APIs, platforms, runtimes, libraries and languages from which to choose. As developers, I think we can all agree that it would be a much less interesting world if there were exactly one option available per type of application. That said, Camel and Spring Integration both provide a lightweight alternative to ESBs, focusing on the programming model in such a way that the developer spends less time with infrastructural boilerplate. So, I would say if you are using one of them, you're on the right track (er, using the right kind of wheel). Now that I've hopefully warded off any chance of a flame war, I can describe Spring Integration in terms of its 2 primary goals:

1. provide an API that represents "Enterprise Integration Patterns" as pragmatically and authentically as possible
2. build upon the existing functionality within the various Spring projects as efficiently and effectively as possible

Regarding goal #1, it's worth pointing out that I started prototyping what eventually became Spring Integration back in 2006 (yes, before I'd heard of Camel) after being hugely inspired by Gregor Hohpe and Bobby Woolf's excellent book. As what seemed most logical to me, I started designing the API around the Message and Message Channel and then moved on from there (next was Message Handler, the common base for Transformer, Router, Splitter, etc). Unlike most other APIs in the space, I wanted to make sure that the core of this API focused on one-way messaging. That is the simplest case, so it should be the foundation upon which support for more complex cases can be built. We on the Spring team have always been driven by the idea so eloquently stated by Alan Key: "simple things should be simple, complex things should be possible". A wide range of messaging scenarios are only one-way (simple), and where needed request/reply operations can be built by combinining two one-way operations (a bit more complex). With that in mind, one thing you will notice if you spend some time with Spring Integration is that the Message Channel has a central role. Most other frameworks seem to focus on the "Message Exchange" where there is a request and a response. In my opinion, using a request/reply model as the foundation might be appropriate for something like the Servlet API (although with increasing use of WebSockets, Comet/long-polling, and server-to-client 'messaging', I'm doubting that as well), but it's not appropriate as the foundation of a messaging API. And yet when needed, request/reply "exchange" patterns - as well as the wide variety of other Enterprise Integration Patterns - can indeed be built upon the one-way foundation of a well-thought-out messaging API. That's exactly the approach we took in Spring Integration. We have a similar philosophy with regard to sync vs. async, but I won't continue rambling with those details here; you can read the book if you're interested ;)

Now, goal #2 is where the framework provides the most value even for those who don't have the same obsession for API design details. Especially for those who are using Spring already, Spring Integration is above all else an "extension" to what is already there. In my opinion, that missing layer was glaringly obvious after reading "Enterprise Integration Patterns". Revisiting the "wheel" metaphor, Spring itself had already defined the hub, the spokes, the ball bearings, and the tread - such that I was compelled to think: "how could I *not* put all of these together and make a wheel?". In real world terms, there is a TON of stuff in the Spring Framework and related projects: Dependency Injection, Aspect-Oriented Programming, Task Executors, Task Schedulers, Transaction Management, JdbcTemplate, RestTemplate, WebServiceTemplate, JmsTemplate, AmqpTemplate, TwitterTemplate, MongoTemplate, RedisTemplate, GemFireTemplate, JMS MessageListener Containers, AMQP MessageListenerContainers, JMS MessageConverters, AMQP MessageConverters, HttpMessageConverters, Object-to-XML Marshalling, and... well, the list could go on and on. The point is that Spring Integration actually builds something EIP-ish on top of every single component I just listed there (and many more I did not mention). Basically, the building blocks were already there - but with Spring Integration, the layer of abstraction is raised to that of the Enterprise Integration Patterns. As just one example, our outbound JMS Channel Adapter uses the JmsTemplate as well as the JMS MessageConverters from core Spring. This reusability is important, because we have a massive community of users who are already familiar with those parts of the framework, and when using Spring Integration they don't have to relearn or even reconfigure those parts. If you need transactions, and you have experience with Spring already, you'll know exactly what to do - AND it will even work immediately with your existing TransactionManager and DataSource configuration. That's why I often say that if you are familiar with Spring and you read Enterprise Integration Patterns, then you're ready to go with Spring Integration. After all, a Spring Integration app *is* a Spring app. There is no need to learn a new way of doing things; just add a few beans.

Hopefully that provides a bit of insight into the rationale behind Spring Integration.

Regards,
Mark
 
H Paul
Ranch Hand
Posts: 491
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I were to recap your insight, foresight [and why not hindsight], would it be?

1. "The opposite of a correct statement is a false statement.
But the opposite of a profound truth [Camel] may well be another profound truth. [Spring Integration]"



2. "If I have seen ["Enterprise Integration Patterns"] further, it is by standing on the shoulders of giants. [Spring Framework]"



3. P.S: Just side notes question the entire Spring Team and its creator:

"To see the things in the seed [of Spring], that's genius."



Any prediction on as far as where Spring would go [grow] to establish its kingdom.

You are the 1st to answer. And yet please keep it as a secret. Thank-you.
 
Ranch Hand
Posts: 76
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have done a presentation about this question at CamelOne two weeks ago. You can find the slides here: http://www.kai-waehner.de/blog/2012/05/17/progress-report-from-camelone-2012-in-boston-apache-camel-activemq-servicemix-cxf/

Short summary: Spring Integration is perfect, if you need some integration features in your Spring project. In other cases (i.e. projects without Spring), IMO Apache Camel is besser due to several different DSLs, more connectors, and (IMO) a larger community.

 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kai Wähner wrote:I have done a presentation about this question at CamelOne two weeks ago. You can find the slides here: http://www.kai-waehner.de/blog/2012/05/17/progress-report-from-camelone-2012-in-boston-apache-camel-activemq-servicemix-cxf/

Short summary: Spring Integration is perfect, if you need some integration features in your Spring project. In other cases (i.e. projects without Spring), IMO Apache Camel is besser due to several different DSLs, more connectors, and (IMO) a larger community.



I'll agree with a larger integration community and more connectors. But Spring Integration has several different DSLs - Java, Groovy and Scala.

As far as connectors, Springs list keeps getting bigger. And looking at the differences, the ones left are not ones that I think the majority of people would need. Not saying that they aren't needed, just by not as big as say JMS.

Thanks for your post on your talk.

Mark
 
Kai Wähner
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Spring Integration has several different DSLs - Java, Groovy and Scala.



Cool, I did not know about the Groovy DSL yet. This is a way into the right direction. However, Groovy and Scala DSL are not production ready yet AFAIK. Furthermore, Spring Integration DSLs are no real DSLs and not easy to read compared to its competitors. Look at my slides, I have code examples from Spring Integration, Mule and Apache Camel.

As far as connectors, Springs list keeps getting bigger. And looking at the differences, the ones left are not ones that I think the majority of people would need. Not saying that they aren't needed, just by not as big as say JMS.



Well, Mule and Apache Camel also keep getting bigger :-) However, you are right. The most important technologies such as JMS, HTTP or File are supported by Spring Integration, too! For this reason I recommended Spring Integration in my slides and in my blog post (http://www.kai-waehner.de/blog/2012/01/10/spoilt-for-choice-which-integration-framework-to-use-spring-integration-mule-esb-or-apache-camel/) for Spring projects where you need exactly these connectors.
 
That feels good. Thanks. Here's a tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic