Announcement Announcement Module
No announcement yet.
Suggestion for Spring Integation Graph Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Suggestion for Spring Integation Graph

    Spring Integration is a very good product. I really like it. If the Spring Integration Graph in STS could be more understandable, I would really appreciated it.

    In the spring-integration-graph, it's fulled with channel information which make the graph difficult to be understood. While in my feeling is that the channel information is not that important. It is just like | in linux pipe. I am wondering if possible to use the way similar with BPEL/BPMN.

    For the basic example xml which is show BookOrderProcessing case. If the graph can be similar like this, it is much easy to understandable for me. The channel name even not necessary to show by default.

    Attached Files

  • #2
    Channel is the first class EIP pattern and unlike other frameworks and products we don't hide it. Instead we embrase it and emphasize its importance every chance we have.
    Yes you are correct, in general you may compare channel to a pipe simbol (hence pipes and filters pattern). However if you dig deeper you'll quickly realize that the main reason for such pipe to exist is to achieve logical and physical decoupling between producers and consumers. The pipe (channel) is what makes producer unaware of consumer, its type or functionality. Producer produces the message and sends it to a channel where consumer will retrieve it. Consumer has no idea who produced the message or how it was produced. That is the core of Messaging architecture. You can swap producers and consumers without affecting one another.
    Channes also responsible for managing the communication protocol between producers and consumers. In your analogy pipe simply connects two sides, but it does not specify how the message have to be dispatched or consumed. For example what does this mean a | b? You may read it as a sends message to b, and you will be right, but if I ask you how the messages is sent or how it is consumed? (push pr poll???). The pipe does not have enough information to answer these questions. This is where channels become even more important since they manage communication protocol such as P2P vs publish-subscribe, event driven vs polling etc. That is why we have several implementations of channels to accomodate all messaging scenarios.
    So as you can see the pipe itself becomes a sophisticated component rather than a simple connector. If it was than I would agree with you.


    • #3
      Thanks for quick answering & detail explaining. I can buy that the channel is important.

      Then comes to what the reason to provide this graph. What I guess is that provide people a way to easy understand how every thing is integrated. Although want emphasize the channel concept, it still be easier to understood.