0

I am writing an application that has one Windows Service that needs to communicate with another Windows Service. The "target" service will accept a request from the "source" service and will perform a task. The "source" service will not wait for a response, so the request should return as soon as possible.

The plan was to have the "target" service host a WCF service which the "source" will communicate with. Once the request is received I need to communicate with the host Windows Service to tell it to do the work. I was thinking that the "target" WCF service would put a message on a MSMQ which the "target" Windows service will monitor. Once this is done the WCF service can return back to the caller.

Does this sound like a sensible approach for allowing a WCF service to tell a hosting Windows Service to perform a task?

Kind Regards

Michael

Matt Davis
  • 45,297
  • 16
  • 93
  • 124
Michael
  • 1

3 Answers3

1

Allow me to disagree. Based simply on what you've described, using MSMQ to communicate between the "target" WCF service and the hosting Windows service seems extremely heavyweight to me. MSMQ allows different processes to communicate in a failsafe manner. In your case, the WCF service is hosted in the same process as the Windows service. Thus, while MSMQ as a commmunication mechanism between the two would work, it's not necessary.

Additionally, using the MSMQ binding between the "target" WCF service and the "source" WCF service makes sense if the two WCF services are not always running at the same time. For example, if the "target" WCF service is not always running, the MSMQ binding would allow the "source" WCF service to still send tasks. These tasks would be stored in the MSMQ to be retrieved when the "target" WCF service begins running. However, it sounds like both services will be running, so I can't see the need for the MSMQ binding.

For selecting WCF bindings, refer to this SO post.

C# - WCF - inter-process communication

Let me address one other thing. When your "target" WCF service receives a task request from the "source," simply communicating the task back to the Windows service is not going to do anything in and of itself. The Windows service is running, yes, but it does not have a thread of execution that you can leverage. The point is that in order to make task processing asynchronous, you'll need to start a thread to manage the task(s). I would suggest leveraging the ThreadPool to do this.

Hope this helps.

Community
  • 1
  • 1
Matt Davis
  • 45,297
  • 16
  • 93
  • 124
0

Yeah, that is a good approach. MSMQ is perfect for this task - the source service can send a request to the target by putting a message on the queue via WCF. MSMQ is good anytime you want to send a request to a service for asynchronous processing, especially if you don't need to get a response back. If you do need a response, you can setup the source as a WCF service as well, and the target can send a message back if needed. There are several different ways to accomplish this with the MSMQ binding.

Andy White
  • 86,444
  • 48
  • 176
  • 211
  • So would you have the WCF service use MSMQ binding and have it do the actual task rather than, say, having a TcpBinding WCF Service that puts a message on a queue and have the Win Service monitor the queue then do the work? – Michael Mar 17 '11 at 06:20
  • You can do it without a TcpBinding, and all you need are your source and target windows services. I would just use an MSMQ binding on both the client (source) and server (target) side. The target can be a windows service that hosts a WCF service host with a MSMQ endpoint. The source side would have a WCF MSMQ client binding that connects to the target endpoint. The source sends a message via WCF MSMQ, and the target will automatically pick up the message, at which point you can process it however you need to directly in the target service. – Andy White Mar 17 '11 at 06:25
0

@Matt

Thanks for your help.

After thinking about it a bit more and see how your approach would make things easier to setup and use. I need to have the "target" service send the outcome of the work back to the "source", so I will probably use nettcp and use a callback. The plan then is to setup a new thread, do the work and once its finished send a response back to the "source".

@Andy

Thanks for you help.

I took a look at msmq, but seeing as I would probably have to setup a new thread once I receive the message I might as well let the web service do the work.

Michael
  • 1