MSMQ/.EXE vs. Web Service.... MEF IoC?

Question

We are debating to correct way to setup a notification service. This serivce will be called by various apps and the service will need to return relevant data back.

My feeling is you just create a Web service that the intranet portal (or anything) could access by sending the user ID and in return getting any information (User 425 report is 90 days due, Application has been rejects.. etc..) We have multiple intranet apps as well as the portal (Lets call them App A, B, and C).

Another person here said we need to use MSMQ.. so I did some research and as far as I can tell the point of MSMQ is for when you have a user the performs some sort of request that is long and cannot be run synchronously .. If these calls take 0.02 seconds.. What is a advantage of MSMQ? All I am doing is sending back a message...

So which makes more sense?

Bonus: App A, B, and C all have thier own Business Logic for determining what messages to send back to the main portal app... So I can.

1. Have the notification web service contain all the logic for Apps A B and C? Problem there is now I am invovled in understanding how app A B and C work so I can have the WS post back the appropriate message..

2. Use MEF/IoC and as part of the build process I get a MEF .DLL that implements a certain interface. So My notification program jsut goes to the various apps and says GIVE ME YOUR BIZ LOGIC DLL.... so once I have all the DLLs and know the interface I can just loop through thme and get the data I need... That way its up to the devs of A, B, and C that are expoerts of thier domain to implement this message passing interface.

Help. (I barely understand MEF so I could be way off there)

Answer 1

I think part of the issue here is that there is some confusion about exactly what the role that MSMQ would be playing in this. Basically you have two methods of doing these notifications:

1. Have a series of web services which can be queried to get the required notifications (a pull model lets say)
2. Have the applications publish status changes that occur during the course of them doing their job, some of which can be picked up by the notification service and then processed (a push model)

Now, in the case of option 2, you can use something like NServiceBus to set up a Publish/Subscribe messaging system which would allow applications to publish the important events in the system, and a notification service to subscribe to the messages that need to generate notifications. It just so happens that NServiceBus uses MSMQ under the covers as the default transport, so in that case MSMQ would come into the picture, but only as an implementation detail.

In the case of option 1, you could implement that in any number of ways, including WCF web services.

Personally, I find the Pub/Sub model to be the most scalable and flexible of the options, plus the documentation for the project is above par, which is nice.