Announcement Announcement Module
No announcement yet.
How about a simplified syntax (implicit channel configuration) Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • How about a simplified syntax (implicit channel configuration)

    Hi there,

    when looking at the XML syntax of Spring Integration, I wonder if there couldn't be more conventions used to simplify pipeline configuration ...

    A while ago, we built our own specialized pipes&filters framework to massage Java HashMaps passed from filter to filter where a configuration could look as simple as below. Each XML element represents a Java source/sink or filter.

    <read-file name="test.txt">
    ... some groovy script or BSF ...
    <print stream="stdout"/>
    <write-db databaseRef="jdbc1"/>

    Many little filters have been built to be configured this way. It's pretty short XML code to express what you want, so it can't be bad.
    Please note, you can also build things like <if><else> constructs, etc. this way. Or even 'push-events' that send objects to 'read-events'.

    I agree that the channel pattern can generally provide more flexibility, but in my experience, you need to be very small filters to make the reusable. And if you do that, you end up with lot of chaining code. I would think that for 90% of the cases, simple chains are enough.

    So how about using the order of elements in XML as 'implicit channel' definitions ?

    So instead of:

    <gateway id="cafe" service-interface="org.springframework.integration.samples .cafe.Cafe"/>
    <channel id="orders"/>
    <splitter input-channel="orders" ref="orderSplitter" method="split" output-channel="drinks"/>
    <channel id="drinks"/>
    <router input-channel="drinks" ref="drinkRouter" method="resolveOrderItemChannel"/>

    you write the following, knowing that 'if no channel is specified, create a default one to the next element in the XML configuration'.

    <gateway id="cafe" service-interface="org.springframework.integration.samples .cafe.Cafe"/>
    <splitter ref="orderSplitter" method="split"/>
    <router ref="drinkRouter" method="resolveOrderItemChannel"/>

    Maybe this is already possible, but it slipped my attention...

    PS.: building Spring Integration is a very good idea. If it had been around 4 years ago, we wouldn't have to roll our own framework.

  • #2
    Have a look at the 'chain' element:

    Is that basically what you are looking for?


    • #3
      Yes, almost. There's still a input channel, but that can be very useful on the 'source' side.

      About simplifying the XML syntax ... was there ever any talk in Spring about using the XML definition in a more concise way ?
      For example instead of:
      <beans:bean id="orderSplitter"
      class="org.springframework.integration.samples.caf e.xml.OrderSplitter"/>

      allow something like this ?

      Maybe only inside a <chain> and there would be a default packagename and by convention 'OrderSplitter' in Java relates to 'order-splitter' in XML ?
      Of course I could build my own XSLT for that mapping, but it might be generally useful, to have the possibility to use a very short XML syntax.

      then you could do things like 'XML programming', e.g. if your Message is a HashMap
      you can build very fine-grained filters, for example:

      <set field="name" value="Joe"/>
      <rename from="address" to="Address"/>
      <delete field="city"/>


      • #4
        I am personally not a big fan of programming in XML.

        However, much of what you are describing - in terms of making the configuration more concise and dynamic - will be addressed in Spring Integration 2.0 where we are going to build on top of Spring 3.0 and thus provide support for Spring's new EL (expression language).

        We are also planning much closer integration with Groovy (e.g. point to a Groovy script for transformation/routing/splitting logic).

        So, keep an eye out for those features!


        • #5
          Well, I'm not saying XML programming is an alternative to Java or Groovy.
          But it can provide some extra flexibility in your pipeline configuration.
          Very often you just want to change a something small, no need to start an IDE.
          Or you want to give customers control over the wiring, but not over the source code.

          A new Spring expression language sounds very interesting.
          Is there already some documentation available?


          • #6
            And yes, Groovy is an excellent glue for 'dynamic configuration of pipes&filters'.
            We started out with the XML programming first, but moved towards Groovy more and more. Except when you want to link a GUI to your configuration, it becomes difficult to link Groovy code to an equivalent GUI.


            • #7
              The Spring 3.0 reference documentation is a work-in-progress and is not yet available online. However, you can check out the 'spring-framework-reference' directory from the SVN trunk:
              svn co .
              Then, run the 'ant doc' target from within that directory. When that completes, the output will be under 'target/spring-framework-reference' (including pdf and html versions).

              The EL support is covered in Chapter 6.


              • #8
                Excellent, thanks a lot !


                • #9
                  No problem. If you have feedback on the docs and/or features, be sure to send that as well.


                  • #10
                    Ok, although building the doc is not so easy, I get this one:
                    Where do I get ../spring-build from ?

                    C:\home\spring-3.0-doc>ant doc
                    Buildfile: build.xml

                    BUILD FAILED
                    C:\home\spring-3.0-doc\build.xml:7: Cannot find C:\home\spring-3.0-doc/../spring
                    -build/docbook/default.xml imported from C:\home\spring-3.0-doc\build.xml


                    • #11
                      Sorry, you should probably check out the entire 'trunk' (same instructions as above, but one level higher). That will then bring in spring-build via the svn:externals configuration for it.