using WCF as a master-slave command model.

Question

I'm developing a master-slave command model by which some application "Master" sends commands to homogenous processes called "Slave" to do some task and then respond back with status complete or process failure. they should also expose some data to the master available on request.

What would this model look like in WCF?

would Master and each instance of Slave host thier own services? would only Master host? only Slave? Should I be using Callback Contracts? Data Contracts? or just Service Contracts.

As a side note, this is a low bandwidth, low intensity, internal only distribution project used for product testing and should not be considered as a "large high demand" project.

Answer 1

If the slave processing will take a long time, then callback contracts might be in order. Otherwise you could just block in the Master waiting for the slave to complete (you might have to adjust your WCF client configuration so that it doesn't time out).

Based on your description, I think you'd really only need to host the WCF service on the Slave nodes and the Master could just be a client consuming the WCF services exposed by the Slaves.

Answer 2

You will definitely have service contracts - a must - in some shape or form. This just defines your service and the operations (methods) on it (OperationContract).

If it's an internal "behind-the-firewall" system, you could look at a duplex binding, e.g. have the Master call the Slave, and the Slave report back on a duplex channel when it's done. Out of the box, there's only the WsDualHttpBinding to support duplex, but since you're internal, behind-the-firewall, you might want to look at creating your own TCP-based duplex binding (it's not as hard as it might sound at first!).

In this scenario, both involved apps really are server and client at the same time.

You will have DataContracts in some way, shape or form to define the DATA that is being moved around between Master and Slave - so again, yes, you will have to have Data Contracts.

EDIT: Of course, another approach might be to use two MSMQ message queues; the Master drops his "job" request into a queue, which the Slave listens on and picks up the job request. When the Slave is done, it in turn drops a response into the response queue to which the Master is a listener, and gets notified of the job being done that way.

Marc

Answer 3

I agree with Jeremy here.. What you're describing doesn't need the complexity of callback contracts. The worker nodes could simply expose a WCF service (or even a WSDL or REST web service for that matter...) and then the controller would simply need to know the URLs of each of the child nodes and send messages to the worker nodes.

If you want the controller to be able to broadcast a single message and have all of the worker (I really dislike the master/slave analogy... I long ago switched to calling it controller/worker) nodes do something in response and post their progress back to the group, then you might want to use the often underrated P2P channel available within WCF. This allows a group of services written in WCF to talk to each other all at once as peers with URLs being used almost like topic/conversation separators.

So, for example, you might issue commands on the net.p2p://labs/commands channel. Only the controller sends commands on that channel but all of the worker nodes listen. When they're done doing their thing asynchronously, they can report progress back on the net.p2p://labs/status channel. An added benefit of this approach is that (if you need this feature), the individual workers would gain the ability to know what all the other workers are doing.

Keep in mind, however that if you use P2P then you'll have to deal with contention - you may end up with 2 nodes accepting the same command. If this is fine, then P2P is your tool. If you need commands to be issued and only picked up serially by individual nodes as they become free (a more likely scenario when telling remote nodes to run individual test scripts, etc) then you can use a MSMQ binding instead of P2P. Then all of the workers become clients which receive messages from the queue and you can more easily counteract the situation of multiple workers accepting the same request.

For additional reference: A blog post I wrote a while back on the Peer Channel.

Peer Channel Scenarios on MSDN - This is good because you can go from here to Peer Channel concepts to the reference guide.

Peer Channel Team Blog