Extending Spring Integration
presented by Josh Long (@starbuxman) and Oleg Zhurakousky (@z_oleg)
One of the most interesting things these guys said is that integration, as an industry need, is extending beyond the specialty of systems integration and toward customer integration: that is, getting systems to integrate with the users, or the users' devices, rather than just neighbouring systems.
Though I've been to two other talks that mentioned or demonstrated Spring Integration (SI), this is the first one I'd attended that focused on it exclusively. Hence, this was the first place where I received the simple definition of SI that I've been searching for. The answer was that, at it's core, Spring Integration is just an embedded message bus.
The guys went on to describe the basics of enterprise integration patterns and of Spring Integration in particular...
Channels are the most important concept in SI. These can be point-to-point or publish-subscribe and can also be synchronous or asynchronous. Enterprise Integration involves lots of different types of components for connection and processing the messages travelling through Channels: Transformers, Filters, Routers, Splitters, Aggregators, etc. All these are not Spring-invented terms but are commonly accepted integration patterns.
There is a Spring Roo add-on for Spring Integration currently in development. There are no milestones yet but apparently it is currently useable. (It's available from the SpringSource GIT repository under spring-integration/roo-addon)
It seemed very simple from a quick demo to create a persistent queue with just a few lines of XML. This is the kind of stuff that I'm very interested in. Unfortunately, there was no discussion about transaction coordination between the queues and other data sources.
A 'Service Activator', which is typcially the end point of a message chain, can simply be any POJO that defines a method that accepts the payload of messages, but is itself completely message- and SI-agnostic. In other words, you can use SI to deliver messages to your existing service-layer components without any change to their code. Pretty neat.
In response to a question, it was said that you could use a Service Activator to implement filters, transformers, etc., by holding a reference to the next channel in the chain, however this would bring integration concerns into the domain of your business logic.
They explained how the whole point of Spring Integration is to separate this logic away from you business logic, so your business code just deals with payloads and handles business-ey stuff, while your integration components - be they out-of-the-box ones or custom extensions - just deal with integration concerns and know little about the business function (other than routing). In a nutshell: The Spring team believe integration should be a configuration concern, not a business logic concern. This was a bit of a lightbulb moment for me.
There is a Spring Integration Samples project showing lots of different ways to use SI and they have a JIRA where you can request the addition of new samples! Good stuff.
After the talk ended, I wanted to ask a question about transaction coordination between Service Activators and message queues, but unfortunately, there were about 20 other people that wanted to ask questions as well so I couldn't get a word in.
I almost forgot that this talk was about extending Spring Integration. I'm sorry to say that I didn't write too much down about this because creating your own integration components is just so easy that's it's not really worth me re-documenting it. They did talk a little bit about rolling your own inbound and outbound channel adapters at either end of a channel in order to integrate with systems that the SI components don't yet support, but this stuff was a little over my head being a SI newbie.
One thing that I'm still keen to know but which I haven't been able to glean so far is exactly how transactional message queues like RabbitMQ fit into the picture. Are they installed as some special implementation of a Channel? Or is a message broker just another SI-agnostic endpoint? (Perhaps using an channel adapters?) Or can you use either approach, depending on your circumstances (e.g. single-process system with persistence vs. distributed system)? If you have any experience in this area, any comments you're able to add to reveal some more depth would be greatly appreciated.
If you're interested in watching the video of this talk, it's been published on InfoQ (1 hr 22 min)
Want to learn more?
| From Amazon... | From Book Depository...  |
No comments:
Post a Comment