olegz edited this page Jun 5, 2012 · 22 revisions

This page will give you a quick introduction to ideas and inspirations behind Spring Integration (SI) Scala DSL and will provide you with the relevant links to help you get started.

For more on Spring Integration please check out Spring Integration Reference manual

NOTE: The Spring Integration Scala DSL is not itself a new EIP framework. Rather, it's a Scala-based DSL that sits on top of the Java-based Spring Integration framework. This is only the first milestone, and the DSL still relies heavily on Java types from the Spring Integration API. As it progresses through subsequent milestones, the DSL will evolve to become increasingly Scala-esque. We do believe that such close integration with the existing API provides instant reusability, but we also recognize the benefit of providing Scala wrappers and converters over those types in the future.

Project Goals

The goals of the project are:

  • provide a strongly-typed Scala alternative to XML configuration
  • raise awareness of Spring Integration in Scala community
  • provide first class AKKA integration
  • providing seamless integration with Java where Scala developers can still leverage their existing Java investments


The idea for the style of DSL you'll see below was inspired from the simple text-based way of documenting pipes-and-filters Messaging architectures

 pipe -> filter -> pipe -> filter -> ...

and in the current state of the DSL the above flow would be implemented like this:

filter{...} --> transform{...} --> split{...}

where custom code is provided as Scala functions (e.g., filter.using{payload:String => !payload.equals("foo")}) or java beans (to be supported shortly)

Through many internal and public dialogs it became clear that using verb representation of EIP patterns makes DSL that much simper to read, therefore instead of seeing transformer we use transform to identify a transformer. It becomes even clearer once you assume a Message making its way through the flow. For example; The above flow might be read as "Filter Message using [some code], then transform resulting Message using [some code] and than split the resulting Message using [some code]"

To identify continuity of the Message flow we've implemented '-->' operator which also depicts the direction of the flow and identifies the next EIP component in the Message flow composition.

For those familiar with XML style of SI configuration the above configuration would look like this:

     <int:filter input-channel="A" output-channel="B" .../>

     <int:transform input-channel="B" output-channel="C" .../>

     <int:split input-channel="C" output-channel="D" .../>
     . . . 

[Back to Home] (