Announcement Announcement Module
Collapse
No announcement yet.
How to model your EDA? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to model your EDA?

    Hi,

    I am looking for a good example on modeling the communication/events in different parts of my system.

    After a lot of reading, mostly on eaipatterns.com, I come to a realization that STS integration graph describes a message flow, not an orchestration workflow. That is excellent, because if it is an orchestration flow, any medium-sized logic will become very complicated to be described in a single xml.

    I guess I can break up the "flow" into several small files. But at the end of the day, modeling a flow like that is a CEP (complex Event Processing), which a message will be composed of pulling data out from other parts of the system.

    So what is your experience? Any pointers?

    Thanks,
    Simon

  • #2
    Its an interesting question, so let's start from me asking why do you separate messaging and orchestration?
    I realize that there will always be a logical separation, but Messaging in itself implies interaction between two+ components via exchanging messages. Orchestration IMHO is the ability to apply EIP (filtering, splitting, aggregation, transformation etc) during the message exchange. So what I am saying is that Messaging enables Orchestration. In other way of looking at it is that Messaging at least within the scope of SI is an implementation detail of orchestration, right?

    Comment


    • #3
      Hi Oleg,

      Maybe I'll try to ask the question in another angle:

      1. I love SI graph in STS, but if there's a lot of event exchanges involved, it becomes too big and too complicated to look at.
      2. The SI examples are really short and sweet, which I love it, but while I can import SI config, STS does not import the graph to form this big flow.
      3. Which leads me to think, that I should be modeling the message exchange, or a smaller "orchestration", instead of this one big thing.
      4. Which comes to the next question, how to communicate the design of my system. The whole orchestration, or smaller groups of orchestrations? Communicate == drawing, documenting, not necessarily put everything upfront in the STS.

      I am making a transition from procedural mindset to this messaging paradigm. Thanks for helping me to convey the design.

      Thanks,
      Simon
      Last edited by simonso; Aug 17th, 2012, 08:02 PM.

      Comment

      Working...
      X