Prism event aggregator : Persistent Events

Topics: Prism v4 - WPF 4
Jun 4, 2015 at 5:19 AM
I have implemented Prism event Aggregators on my server where a service publishes an event and another one listens to it.
My subscription code:
 my_aggregator.GetEvent<MyEvent>().Subscribe(Handler,true);
whereas I publish my event as:
my_aggregator.GetEvent<MyEvent>().Publish(Payload);
The thing is that if the subscriber is alive then, everything works fine. But, lets say an event is published and the subscriber (is a service) somehow shuts down. Is there a way by which when the subscriber comes alive again it can respond to the event that was fired.
I have looked at netmsmq binding and how it provides a queue between services so even if the server shuts down loss of data can be avoided.

Will I have to hook it up with my current mechanism??
Or is there any other way this can be achieved??
And are there any standard mechanisms of handling this?
Jun 4, 2015 at 5:26 AM
I'm afraid you are cleanly outside what Prism pub-sub events were designed for. They were designed for loosely coupled components that are all in memory at the same time on the client side but you don't want to introduce coupling between those client components for them to communicate. For the kind of scenario you are talking about server side queues of some sort are the right answer, whether they are MSMQ-based, RabbitMQ, or Service Bus queues for Service Bus for Windows Server (or many other options along those lines depending on whether you want the queue to be on premise or in the cloud).

But bottom line if you want process isolation and independent process lifetimes, queueing technologies are the only way I know to solve that and sit cleanly outside the realm of what Prism was designed to address.
Marked as answer by syedosamamaruf on 6/3/2015 at 11:32 PM
Jun 4, 2015 at 6:31 AM
Thanks Brian for pointing me in the right direction. I have already taken a look at MSMQ based queues and they look promising for what I want to do.