Win a copy of Building Blockchain Apps this week in the Cloud/Virtualization forum!

Gunnar Hillert

Spring Integration Committer
+ Follow
since Oct 31, 2012
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Gunnar Hillert

Hi Kato,

Thanks for your question. This is somewhat tricky to answer. The easy answer is as always: "It depends..." :-) but let me try...Let's say you write a very basic "Hello World" application. Using the core Spring Framework for that application would most likely be total overkill.

However, once you start having a reasonably complex application, using the core Spring Framework makes perfect sense as it helps you to decouple your code using dependency injection. Plus you are getting more targeted framework support for specific uses-cases, such as writing a web-application (Spring MVC).

On top of core Spring, you may consider Spring Integration as another/additional (thin) higher-level layer of abstraction. If you are writing a small/medium (web-) application you most likely don't have a need for Spring Integration. However, if you start having more complex requirements, Spring Integration helps you to decouple your code even further. For example, you need to import, validate, process some weird flat-file that ultimately ends up in your application database.

Yes, you can do this using just core Spring (DI) but using Spring Integration, you can break this process down into more coarse grained chunks connected through messaging. Each "chunk" (Spring Integration components, sub-flows) may be using of course dependency injection (to wire up additional services).

In addition to that you can use the provided Spring Integration adapters to avoid the hand-coding of certain steps in your process (E.g. using the FTP Adapter to retrieve the remote files).

I am not very familiar with OSGi, but one may consider OSGi being an even higher-level of abstraction for applications (but could use Spring Integration internally). And at some point, your application may have scaling/uptime requirements, that may necessitate to break up your application into separate applications/processes. However, using Spring Integration should make this journey fairly smooth.

I hope this helps you a bit with the bigger picture but please ask if I shall provide more details.

Cheers,

Gunnar
7 years ago
You may want to watch this talk by John Davies at last year's, SpringOne conference (2011). It gives you you some ideas of how Spring Integration is being used in the financial industry:

http://www.infoq.com/presentations/Enterprise-Integration

Disclaimer: I am a committer on the Spring Integration project
7 years ago
Hi,

Yes, the book does go into quite some detail about when and how to use Spring Integration. The first chapters provide an excellent overview in that regard. This is probably as close to a mission statement as it gets:

"Spring Integration provides an extension of the Spring programming model to support the well-known Enterprise Integration Patterns."

The core take-away from this is that Spring Integration closely follows the patters of Gregor Hohpe's EIP book and re-uses as much from the Spring ecosystem as possible. Thus, if you are using Spring today, introducing Spring Integration into your projects should feel very natural. It is basically a slightly higher abstraction on top of the existing Spring functionality.

Cheers,

Gunnar

Disclaimer: I am a Spring Integration committer.
7 years ago
Hi,

Take a look at chapter 16 of "Spring Integration in Action": "Integrating Spring Batch and Spring Integration". It provides a very good overview of how to integrate Spring Batch and Spring Integration:

* Launching batch jobs through messages
* Providing feedback with informational messages (via StepListener, ChunkListener, JobExecutionListener)
* Externalize batch process execution (Call Spring Integration from inside batch jobs)

We talked a little bit about those options in our recent (2012) SpringOne talk: http://www.slideshare.net/hillert/introduction-to-spring-integration-and-spring-batch
There will also be an audio/video recording of that presentation available in the upcoming weeks/months.

As Spring Integration and Spring Batch are under the same umbrella of Spring projects, you will see an increasingly tighter integration between Spring Batch and Spring Integration. As for your specific situation, take a look at the features provided by Spring Batch. I believe one could make an argument that for simple use-cases with small batch files, you can do the job efficiently using Spring Integration only (Use the simple/more generic tool first). However, if you start dealing with massive files that don't easily fit into memory anymore, take a very long time to process, and you start feeling the pain, then you probably need to seriously consider Spring Batch. Other people may have a different view point but I hope this provides you with some useful guidance.

Cheers,

Gunnar

Disclaimer: I am a Spring Integration committer
7 years ago
Hi,

I think two major advantages that Spring Integration brings to the table is that it is extremely lightweight and that it reuses the features of the Spring ecosystem to the fullest extend.

Thus, you can use Spring Integration easily as a library within (existing) applications. This means Spring Integration is also very suitable for intra-application integration and not just for business-to-business (B2B) or application-to-application integration (EAI).

What I mean by that is that you may have pieces of your application that you want to logically separate in order to break down complex business requirements into more manageable components but you still want to keep everything as part of the same application (at least initially). This give you the infrastructure, as your application scales, to add asynchronous behavior to your application or to refactor out components to un on difference machines etc. as the need arises. In that regard it is worth to mention that you can use Spring Integration in any type of application - be it stand-alone applications (jar) or web-applications (wars).

Therefore, yes, you can create applications with Spring Integration that run similar to a traditional ESB but you can also create application using Spring Integration that are almost embedded in nature. I have heard of an example where Spring Integration is used as part of an ATM stack using the TCP/IP adapters in a financial institution.

I hope this provides some insights regarding how Spring Integration fits into the landscape compare to a traditional ESB.

Cheers,

Gunnar

Disclaimer: I am a committer on the Spring Integration project
7 years ago