How to design a scenario where one subscriber depend on other?

In my application, I have a scenario where if a change occurs on a particular module, it has to be notified to few other modules. I thought an observer pattern would fit here, by keeping the module on which the change will occur as subject and the modules to be notified as observers.

But going by the principle of observer pattern, the observers are independent of each other. There should be no connection between the observers. In my case, though the modules are different, they are dependent. The successful completion of execution of the first module is important for the next module to execute. Also if the module x fails, all changes made by module 1 to module x-1 has to be reverted. That is, either all the modules has to successfully execute or we have to rollback to previous state. You can imagine it like a transaction. Then I realized I was wrong that observer pattern is not the right way to implement this.

I am kind of stuck up here to come up with a clean design, where there are set of modules who needs to handled when a change in subject happens, but with the constraint the modules are dependent on each other. Can someone help me with this problem to come up with a good design?

Vinothkumar Rajendran, Aug 08, 2012

I dont see any ugly in employing observer pattern between 1 to x-1 modules. 1 observes 2, 2 observes 3 and x-1 observes x. if x files x-1 will roll off and raise fail event which will let x-2 know. only thing you need to make sure that you wont end up with circular reference.

Aug 13, 2012

Reply 1

Your scenario is a perfect workflow enclosed withing atomic transacation scope - All Suceeds or All fail..

Take a look at Windows work flow foundation, which gives you clear idea to handle your scenario.

The module dependency here , I presume it is somthing similar to business rules,,

If you have a configurable way of defining a module's dependency, which could be read and work flow built within an atomic transaction scope, you are almost done.

From your statement, it is not clear how do you plan to add/remove modules , which should be always fore thought , to handle scalability /maintainability point of view.

Hope this helps.

Thanks & Regards
Tarriq

Tarriq Ferrose Khan, Aug 13, 2012