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