Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

spring integration philosophy

 
kato Kwong
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
kato Kwong
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic