Why should one use Spring Integration

[Sai Hegde]

There are so many better and powerful API's from either Mule ESB or Camel. Why should one use Spring Integration then except for when you are working on a Spring project?

[Mark Spritzler]

so many better and powerful API's

Who says???

Spring Integration is just as powerful. I would say about Mule, do you want a full blown server to get and ESB, or get it without having to get a server as well. Spring Integration works with POJOs, just like Camel, which is a cleaner and beter api.

If you are going to make a statement like that you have to at least support it somehow.

Mark

[Sai Hegde]

I did some initial proof of concepts about 6 months back comparing Spring Integration and Camel and felt Camel was far better and easier to use.
I hate having to go through large XML config files that make me dizzy. Camel has excellent support for DSL's which is far better to read than XML and extremely handy when you are writing complex integration logic.
Mule ESB can be used as a lightweight framework by using only the bare minimum libraries. Also Mule has great connectors to Paypal, SAP and other proprietary interfaces.

[megan smith]

I have used Camel in one of my projects. I agree with Sai, Camel is very easy to integrate . I don't know anything about Spring Integration to make any comments.

[Mark Spritzler]

Sai Hegde wrote:I did some initial proof of concepts about 6 months back comparing Spring Integration and Camel and felt Camel was far better and easier to use.
I hate having to go through large XML config files that make me dizzy. Camel has excellent support for DSL's which is far better to read than XML and extremely handy when you are writing complex integration logic.
Mule ESB can be used as a lightweight framework by using only the bare minimum libraries. Also Mule has great connectors to Paypal, SAP and other proprietary interfaces.

Spring integration also has a DSL for a few languages.

Mark

[Sai Hegde]

Yes it does now with Scala and Groovy, but then it is the same argument about Spring Integration playing a catch up game as JavaEE does with Spring.

[Mark Spritzler]

Sai Hegde wrote:Yes it does now with Scala and Groovy, but then it is the same argument about Spring Integration playing a catch up game as JavaEE does with Spring.

Sort of, from one perspective. ;)

Mark

[Iwein Fuld]

Camel promises more or less the same thing as Spring Integration and Camel was there first. Wether you like the one API or the other is up to you of course. I like the clear separation of Channels and Endpoints in SI. I like immutability. But Camel probably still has plenty of features that SI doesn't have.

The next statement is somewhat harsh, but by no means meant as a personal attack on anyone. The reason I would never use Mule or Camel is that I've read the source code, extended it and debugged it. It wasn't of sufficient quality to run on a production system.

I'm very biased of course, but I'd recommend a healthy bias towards quality to any serious developer. I'd have enormous respect for someone that won't use Spring Integration because he demands higher quality and backs that up somehow.

[kato Kwong]

Mate, I love your brazen attack on Camel code quality. Poor old Camel.

I would like to point out you have not backed this up with any of the somehow you would like from a Spring Integration critic...

[Iwein Fuld]

kato Kwong wrote:Mate, I love your brazen attack on Camel code quality. Poor old Camel.

I would like to point out you have not backed this up with any of the somehow you would like from a Spring Integration critic...

Excellent point. I mean something different though. If someone decides not to use SI and backs that up with working software, he has nothing to prove in an argument. I won't back up my claim by pointing out bad code in Camel, it would be easier for me to point out the deficiencies in SI code because I know where to look. Nobody is perfect. At the time I looked at them, both Camel and Mule didn't meet my (subjective and unreasonably strict) quality criteria. That might be interesting to you, or funny, or not. Many parts of Spring Integration do meet those strict quality criteria, so my answer to the OP's question is: 'because of the quality'.

If I come up with code samples to prove the quality of SI or disprove Camel's quality, that will only serve as a way to slip by an appeal to authority on the part of anyone buying my argument. The only way to get through this is to look at the code yourself and decide.

At the end of it all poor old Camel will be fine I'm sure. As will Spring Integration. Most of you won't look at the code anyway, and most of you would get away with it. That won't be the same set though and you should decide carefully to what remaining minority you don't mind belonging