• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

spring integration philosophy

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.


 
Spring Integration Committer
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 92
Mac Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
reply
    Bookmark Topic Watch Topic
  • New Topic