Is WCF the right choice for me?

Question

From the little that I know about WCF it seems to be the right solution to a particular problem I have but I'd like to get some input on it.

Problem Description:

Clients sequentially access domain objects from a list roughly once ever 1-10 minutes (average is 2 mins), but no 2 clients should ever access the same object. Certain orderings should be maintained within the list.

Example Usage:

Client X -> WCFService::GetNextObject() -> Fetch from DB, sort
         <- return nextObject

Where X is [1,~200)

The list of objects is basically a DB table where each object is annotated with a priority. All objects with priority 1 should be the next ones passed out. The ordering from there depends on the priority level. E.g. priority 1 objects should be handed out chronologically based on a datetime on the object, whereas priority 4 objects need to be handed out alphabetically based on a string value on the object.

[Edit]Some points of clarification: there are other sorting schemes for different priority levels which need to reference associated records in myriad other tables - it seems overly complicated but there is a valid business case for it. Likewise, objects are added and removed from this list potentially very frequently (but the average is rarely).[/Edit]

I am looking at using WCF so that people from any geographical location can use it via LAN/WAN and it will ensure that the ordering is maintained and that no two clients get the same nextObject. Am I right in thinking that WCF is a good choice for this?

The one thing I wonder about is the state of a WCF Service? Or, better put: Is it stateless? Will each client's access to the service create a new logical WCF instance? And if so, then how is synchronization/locking normally approached?

It should be noted that everything else at the company here is developed on the .NET stack, so there's obviously an existing affinity for .NET technologies. It's not, however, mandatory by any means.

Answer 1

It sounds to me like you're just grabbing data from a service in a queue with multiple clients.

If this is a case, you should just use SQL Server and this is literally a queue table in a database. Each time a client dequeues an item from the table, it updates the priorities of the other artifacts.

Or better yet, just use an identity primary key and always grab the lowest id, and delete it when you grab it, or move it to another table if you need to for some reason.

Just use SQL Server or SQL Server Express if you want it free, and you get all the locking and etc for free.

Answer 2

WCF is great for hiding the details of your server from your clients - it provides a layer of abstraction that will be very handy for handling a large number of clients. If this were a couple of people requesting data from the database then I would say that WCF would be overkill, but it sounds like this is the correct application of this technology.

Regarding the state of the WCF service, this is configurable. You can have the service run as a singleton, or have it generate a new instance with each session, or even each call.

Here is a (verbose!) explanation of WCF instances: http://msdn.microsoft.com/en-us/magazine/cc163590.aspx

Answer 3

I agree with Jake, but do want to add a few things:

1. Clients can fail or go away, so it's important not to just hand them the object and lost all control of it. The usual way is to lease is to them for a period of time, so that if they don't complete the processing then the object goes right back into the queue. In your case, I suspect it would go back into the front of the queue, but it's more commonly the end. You also want to track retries in case some object is toxic and cannot be processed.

2. Unless all of your clients are .NET, you're going to want to stick to the more universal parts of WCF.

Answer 4

It seems like a solution involving WCF and MSMQ might fit your requirements. You can use MSMQ to store the next items that need to get served to the clients, while your WCF service can be the front-end for MSMQ so that your clients don't have to interact with it directly. Since your state is being maintained in MSMQ, your WCF service can remain stateless.