Windows Service or any other alternative

I'm in dilema whether to use windows service for my application or not, below is the description about my application please could anyone suggest what is the best approach for my requirement, if possible with pros and cons as well.

There is Application "A" which is a closed application and any data I need from that application is exposed only via WCF services. My application "M" has to call one of the WCF service exposed by "A" and then get the data and process it and throw out a file. Similarly if some file is injected into my application "M" then I need to process it and push that information into Application "A" using its WCF service. This is the requirement in brief.

problems-

1) Here my application "M" needs to continously poll application "A" wcf service to check if some开发者_JS百科thing is availabel for it to process. I dont like polling but any other alternatives, please suggest. I thought of MSMQ, that application "A" sends message to my application "M" whenever a new data comes in. My application "M" then processes that from Queue. Not sure how to do it. Please advise if this is right approach.

2) Another thing is if a new file comes onto some server folder then my application "M" has to pick it up and process it and send it to Application "A". so in order to acheive this I may have to have a file system watcher and as soon as something becomes available then it has to kick off my application. Again struck at what technology( only in .Net) to use. Is MSMQ best approach ?

So am now struck at which tech (only in .Net) I need to use to efficiently complete my requirement. Is windows Service best approach by constantly polling Application "A" and implement MSMQ along with it. Please advise.

Thanks in advance

Sai

---

For requirement 1, I would use a WCF service hosted via the Windows Process Activation Service (WAS) - see the MSDN reference. That requires WAS (Windows Vista/7 or Windows Server 2008/2008R2), however, so if those are not available then a regular NT service would be the appropriate fallback.

For requirement 2, you can implement an NT service that uses the FileSystemWatcher class (MSDN reference).

So, you could implement a single NT service with the FileSystemWatcher and a polling thread, or you could implement both an NT service with the FileSystemWatcher and a separate WAS-hosted WCF service that listens via MSMQ.

The latter is perhaps a little cleaner since it follows the separation of concerns principle. But it's only possible if application "A" can be configured to send messages via MSMQ (i.e., your service "M" would become the "server" and application "A" would act as a client). So, the former option (a single NT service to do both) may fit your scenario better, but I'm not completely sure from your description of "A".

As for sending messages to application "A", MSMQ may or may not be the appropriate choice. Are both applications on the same machine? Then use named pipes. Are they on different machines? Then use a TCP binding if application "A" is always running (i.e., a running service), but use an MSMQ binding if you require guaranteed delivery of your messages and application "A" may be offline occasionally while application "M" is sending it messages. (Also, note that using MSMQ requires that the MSMQ Windows component be installed on the receiving machine.)

---

It sounds like option A is immutable and therefore you cannot change it. ("Closed")

Application M should be a windows service, as Lars describes. But, do not ever use the file system watcher unless you like to rip out code later and replace it with a polling mechanisim. Your best bet is to start one thread to poll application A, and another to poll the filesystem.

There is nothing wrong with polling. Use a Thread.Sleep(10), and you will be fine. FileSystemWatcher will often give you a file that has been 'changed', but that has not completed writing. This results in you getting a truncated file.

Don't bother with MSMQ, unless you absolutely need to. It's just another piece to maintain, and cant handle complex retrieval operations..