views:

76

answers:

1

I'm building an application that will distribute its processing over a farm. In my basic design I have two services:

A "controller" which watches for new work, queues it up, and manages the results.

A "worker" which binds to a particular controller. The worker will check out work from its controller, and push the results back.

In the breif look I've had at WCF, it seems to imply a MEST style message-passing SOA. This mechanism doesn't seem to jive with the types of communication & coordination I'll be doing.

Am I mixed up on what WCF is? Is there still a place in this world for .NET remoting? Or am I thinking about the problem in a jurassic, pre-WCF mindset.

Edit:
Left out some detail. The rub is that I need to timebox the work. If a workitem is checked out for too long, I should be able to error the whole thing. The examples I've seen all seem to take a "send and forget" stance towards the outgoing messages. I need a deterministic result or error in a reasonable timeframe. Hope that clarifies.

+3  A: 

I don't recommend remoting for most scenarios; it is non-portable, a little painful to manage sometimes, and BinaryFormatter is brittle (version intolerant).

WCF is a pretty good fit for most cases; if you are working on a farm you'll probably want to run without sessions etc, but I do that anyway (for performance) - just using the http basic profile.

I don't fully understand the scenario you are describing. Of course, you can always roll your own RPC using xml/json/binary - or use any of the other pre-canned comms stacks... or middleware like MSMQ or BizTalk.


Re the edit; WCF can be used synchronously (blocking on the response, with (I believe) a configurable timeout). You can do more sophisticated things (rollback etc) with distributed transactions etc, but it adds complexity rapidly. You'd need to weigh the importance of the drop-dead time, etc.

If the timeframe is longer than you'd want to wait for an invoke, you could also consider things like workflow - there are a range of workflow products around, in addition to WF.

Marc Gravell