Home/ Questions/Q 8727475
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T08:26:26+00:00

I am seeking help from SOA/ESB experts on some architectural design. Apologies if the

  • 0

I am seeking help from SOA/ESB experts on some architectural design. Apologies if the question isn’t very clear.

We have several business cases where we are currently using P2P communications or loads of blocks of code like 

       if(...)
               Update System 1
               Then Update System 2
               Then Update System 3
       Else If (...)
                Update System 1 in a different Way
                 Don't Update 2 at all
                 Update 3 but differently

Now there is lot of boiler plate code and Database update code all over. Fun is we started off with one client facing interface and then kept on adding more and to gain “quick wins” kept on replicating the code all over. Now when a small change was required it became a humongous task.

This was a typical ESB type case IMHO and we are thinking of embracing Topic – Publish – Subscribe model to cater to such scenarios. So that all participating clients can publish a message to a Topic and then we simply hook on subscribers wherever and whenever needed. Al the Db or system update code will be generic and goes to a single clustered deployment.

However say the data should be updated in all systems. e.g. if an update in 1 subscriber fails we should rollback the update in other systems or at least maintain an audit where it failed.
What is the best approach to achieve the above? Are there standard tools/ utilities we can use?

FYI – We are using Java technologies and Mule ESB and want to utilise it’s full potential.
Thanks in advance. Please do let me know if more clarity is needed

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Using Topics is a very powerful way to tie services together. This is a pattern I call Saga. When You should make sure that your topic design should convey both the event and the context since the same event may need to be routed to different recipients depending on the context (so a topic might look like context.evetnType and subscriber can subscribe to all the events of a type (*.eventType) or only in a specific context)

    Note that anohter alternative for externalizing this behavior from services is to use Orchestration. Orchestration has makes it easier to see and monitor predefined business proceses at the cost of serendipity and some flexibility (vs. saga). It can also encourage nano-services

    • 0