CODEWITHSUNDEEP
c#wcfserializationqueue
Scott
Scott

Reputation: 904

Building a Queue Service - Serializing Tasks for later use

I am working on creating a “Queue Manager” service and its sole responsibility is to add work items to the queue and remove work items from the queue. I have implemented the service as a singleton because I have some unique synchronization issues I have to deal with. Any time a new task is needed, I create a new Task object, set the parameters and then send it to the QueueManager service and have it added to a SQL Database. The Task object is serialized to the database at that time. When a process requests an item from the QueueManager, the service finds the next available work item and deserializes it back to a Task object – from there it gets returned to the client.

Technically, this works great. However, I’m not happy with having to shoehorn all types of tasks into a Task object. Work items can range from anything from copying files to updating databases. I have to add a lot of properties to the Task object that don’t mean anything to many other task types – it’s getting pretty sloppy. My first thought on how to fix this would be to have Task implemented as a base class, and then have all other tasks derive from Task. This would allow me to have work items such as CopyFileTask, UpdateDatabaseTask, DoLaundryTask, etc. I would then serialize the object to the database and add a column to tell me what the type is so I know how to deserialize it later.

The first problem I see doing it this way would be that the WCF Service needs to return just one type. That would require the service to down cast the work item (CopyFileTask for example) to Task. However, I now need to cast it back to its real type, but the client will have no idea what that type is.

I’m probably not doing a good job explaining this. In a nutshell, I need to:

My Queue needs to be very generic since many other applications are adding and removing work items. This is being designed for a massive parallel system and will be the hub for all distributed work items. Any and all help and ideas will be greatly appriciated.

Thanks,

Scott

Upvotes: 3

Views: 1317

Answers (2)

tom redfern
tom redfern

Reputation: 31760

Have you looked at ServiceKnownTypeAttribute? Have a look at the sample code on this MSDN: http://msdn.microsoft.com/en-us/library/system.servicemodel.serviceknowntypeattribute.aspx

Upvotes: 1

esskar
esskar

Reputation: 10950

this is actually the perfect scenario to use a NOSQL database like CouchDB. Such database are peferct if you have to store data that is not bound to a hard schema but is more document (or in your case) task based. you destinguish them by a type, but the underlying structure is not bound.

Is CouchDB an option? then checkout relax - a .NET API for CouchDB.

If not, just store basic data like type, created, ... (basic data you need to setup a query to get the next task in the queue) in seperate columns in your SQL task table. and then you have a column called details or workitem, that holds the detailed information of your task as XML.

Upvotes: 0

Related Questions