This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Spring and the fly likes spring integration philosophy Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "spring integration philosophy" Watch "spring integration philosophy" New topic
Author

spring integration philosophy

kato Kwong
Greenhorn

Joined: Sep 23, 2011
Posts: 27
Hi,

I am wondering what is the mission of the Spring integration project.

Is it to provide a DSL for integration patterns that follows the Spring way?
Or is it to provide a microcontainer for integration?
Or is it just an alternative to other frameworks like Camel?
Something else?

I have little experience of integration and I get confused about when I might use integration patterns (other than when coupling existing and legacy applications).

Does the book discuss reasons to use Spring integration rather than the Spring integration features themselves?

Cheers,
Kato
megan smith
Greenhorn

Joined: Nov 30, 2009
Posts: 22
Enterprise Integration Patterns is a book by Gregor Hohpe and Bobby Woolf and describes a number of design patterns for the use of enterprise application integration and message-oriented middleware.

Its a very good book and I love it.

Apache Camel uses most of the EAI Patterns described in the book.


Gunnar Hillert
Spring Integration Committer
Greenhorn

Joined: Oct 31, 2012
Posts: 5
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.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Gunnar Hillert wrote:Hi,

Cheers,

Gunnar

Disclaimer: I am a Spring Integration committer.


I added a title to your account, now you don't need the disclaimer added. It is in your name and profile.

By the way, welcome to JavaRanch. Unfortunately, I wasn't able to attend your talk a couple weeks ago. There were just so many great talks it was always tough to decide which to go to. I even had to miss a couple that happened at the same time as my talk on Tuesday morning.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
kato Kwong
Greenhorn

Joined: Sep 23, 2011
Posts: 27
Thanks Gunnar.

I've read a reply you made in another post: spring integration vs ESB and you say:

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


Is it thus the intention to make integration patterns more accessible from within applications?

Does the book discuss the trade offs involved in using integration patterns in this manner, e.g. overheads involved in any transformations?

And what are your thoughts on the use of spring integration vs spring dependency injection vs OSGi in making applications more modular?

I mean, with Spring we have a great way to decouple components of an application. With OSGi we have a way to formalise this decoupling at a physical level. So why do we need to complicate matters further by using integration patterns within the application?

I'm just trying to understand the bigger picture

Cheers,
Kato
David Sachdev
Ranch Hand

Joined: Oct 18, 2011
Posts: 32
Gunnar Hillert wrote: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."



Welcome Gunnar. You mention that the book goes into quite some detail about when and how to use Spring Integration (SI) . Since SI includes so many different technologies, I'm curious to know as far as breath and depth how much the book covers. I realize that a book that covers all points of SI in depth would be massive - so do you try and cover an overview of the integration points offered by SI, or do you choose a few integration points and go into depth with them. I see that there are also quite a few new components including various NoSQL support, and enhanced XML and FTP support.

Currently we are using SI for scheduled services, polling email accounts, but I'm sure that there is much more that we will adopt over time.

Thanks
David
Gunnar Hillert
Spring Integration Committer
Greenhorn

Joined: Oct 31, 2012
Posts: 5
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
kato Kwong
Greenhorn

Joined: Sep 23, 2011
Posts: 27
Thanks for your reply Gunnar, very interesting.

Particularly when you say:

one may consider OSGi being an even higher-level of abstraction for applications (but could use Spring Integration internally)



I always thought that OSGi would be used to define application modules that would be fine grained “chunks” and combine them to form the coarse grained “chunk”. This coarse grained "chunk" can then be integrated with other coarse grained “chunks” using SI, for example. The reason for this is OSGi offers a way to integrate the chunks as though a normal java method call were being made, i.e. there is no overhead for calling an external module and we can make them as fine grained as we like.

But maybe this is the wrong way round…or maybe it could be used in both ways…or maybe I have confused the purpose of OSGi...

Maybe I’ll just have to read the book!

Cheers,
Kato
 
Consider Paul's rocket mass heater.
 
subject: spring integration philosophy
 
Similar Threads
Spring in action - integration with other web frameworks
how many design patterns are there?
Pro Spring Integration - Previous knowledge
Camel vs Spring Integration. Part 2.
Pro Spring Integration versus Camel, et al.