Announcement Announcement Module
Collapse
No announcement yet.
How to garantee resilience of the system? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to garantee resilience of the system?

    Can I ask a question that is not completely related to the inner workings of Spring Integration but more about the overall architecture of a solution where SI is the basis?

    Also I'm not looking for "answers" but more for "opinions" so please comment on this even if is just some thoughts.

    The architecture we put up, practically all based on SI and a few JSR-311/Jersey components, is designed roughly like this:

    User Agent -> [ Connector -> Resource/Gateway -> IN-QUEUE -> ServiceHandler/Implementation -> OUT-QUEUE -> Gateway/Resource -> Connector ] -> User Agent

    (actually, the User Agent is not part of it, hence the [...])

    Now our next logical step will be to implement JMS QUEUEs (almost for sure ActiveMQ) in the place of the intra-VM queues that we have now.

    However the question of resilience was raised now, because with this design, if any of the components is down, all the platform is down and we lost every incoming message that other external components sent to us.

    So to obviate this problem, was suggested that we put the ActiveMQ not replacing the intra-VM ones but on the "border" of the system, like

    User-Agent -> IN QUEUE -> [rest of my SI-components] -> OUT QUEUE -> User-Agent

    Although this solves the resilience problem it doesn't seem a "elegant" solution to me, I think it turns our solution less expandable, more tight-coupled between the service definitions and it's implementation, we loose the capability of having services outside of our system, all the resilience will be concentrated in only one type of connector (JMS), it turns "vertical" issues like Monitoring more difficult...

    But the fact is that it solve the resilience issue (although only for the JMS connector, but it seems that is enough for us) while the current situation doesn't.

    Any thoughts/experiences on this? Any comments welcomed.

    Cheers.

  • #2
    After some discussion on the PT-JUG I'm thinking about this alternative:

    - decouple as much as I can my internal components, so that a failure in one doesn't affect the others. At least, decouple all the connectors/adapters (decouple both logically and physically)

    - implement some kind of "light" persistence on each connector, for instance using a Persistent Queue (something like this?)

    - implement redundancy and fail-over between connectors, which I don't know yet how to do.


    What do you people think about this?

    Go raibh maith agat.
    (it's "thank you" in Irish)

    Comment

    Working...
    X