Best practice to share data and notifications between applications [closed]

Question

What is the best practice to share data between different applications on the same machine and notify them if the data has changed?

I have 4 applications which are using the same settings project to change their settings. When I change the setting in the project, other applications have to act on this change and have to know that the setting was changed.

I thought about IPC to make setting changes and then broadcast the change information to all users but it would be great if such a library already exists.

EDIT:

I found a solution that worked for me. We decided not to spend a lot of time in this functionality because its not extreme critically to update the other applications.

We save our settings, as we did before, in a XML-file and I registered the FileSystemWatcher on that file to get all changes. So if I change the settings all 4 applications go and read the settings file and determine if they have to take an action or not.

Answer 1

Solution to be chose depend on different parameters:

1. How much effort can you invest in implementation.
2. How critical is it that applications will be updated quickly.
3. Which environment is available for you/ yours customers.
4. ...

For example:

• saving changes to database/config file, and let the applications run a separate thread, which is dedicated to check for setting changes every n seconds. It's cheap and easy to implement this solution, yet not "nice", and many developers will reject such solution.
• Create a WCF service, which "publish" changes to the applications. That case, using Dual bindings, applications will be updated instantly. Of course, this solution is more costly....

Those are only 2 examples out of many available solutions (shared memory, shared application domain, etc).

Answer 2

What you have done seems wisely.And I have another experience using MSMQ . You can create Private or Public Queues,since you have all of your apps on the same machine, private queue is ok,otherwise, you should use Public queues. In that time I had choosen Spring.Net as my framework (object builder & dependency Injector). Spring.net has brilliant QuickStarts and one of them is using MSMQ as communicating bridge between applications. If I were you, I would utilize Queuing approach, because you can notify apps running on different machines.

Also,WCF provides convenient means for developing a distributed service over the underlying MSMQ component.

Furthermore,Publish-Subscribe is a common design pattern that is widely used in client/server communication applications. In WCF service development, the Publish-Subscribe pattern will also help in those scenarios where the service application will expose data to certain groups of clients that are interested in the service and the data is provided to clients as a push model actively (instead of polling by the client)