Создание службы очереди - сериализация задач для последующего использования - PullRequest
3 голосов
/ 01 декабря 2011

Я работаю над созданием службы «Администратор очередей», и его единственная обязанность - добавлять рабочие элементы в очередь и удалять рабочие элементы из очереди. Я реализовал сервис как одиночный, потому что у меня есть некоторые уникальные проблемы синхронизации, с которыми мне приходится иметь дело. Каждый раз, когда требуется новая задача, я создаю новый объект Task, устанавливаю параметры, а затем отправляю его в службу QueueManager и добавляю его в базу данных SQL. В это время объект Task сериализуется в базу данных. Когда процесс запрашивает элемент у QueueManager, служба находит следующий доступный рабочий элемент и десериализует его обратно в объект Task - оттуда он возвращается клиенту.

Технически, это прекрасно работает. Тем не менее, я не доволен тем, что все типы задач включаются в объект Task. Рабочие элементы могут варьироваться от чего угодно, от копирования файлов до обновления баз. Я должен добавить множество свойств к объекту Задача, которые ничего не значат для многих других типов задач - это становится довольно небрежным. Моей первой мыслью о том, как это исправить, было бы реализовать Task в качестве базового класса, а затем все остальные задачи были получены из Task. Это позволило бы мне иметь рабочие элементы, такие как CopyFileTask, UpdateDatabaseTask, DoLaundryTask и т. Д. Затем я бы сериализовал объект в базу данных и добавил столбец, чтобы сообщить мне, что это за тип, поэтому я знаю, как его десериализовать позже.

Первая проблема, которую я вижу при этом, заключается в том, что службе WCF необходимо возвращать только один тип. Для этого потребуется, чтобы служба завершила преобразование рабочего элемента (например, CopyFileTask) в Task. Однако теперь мне нужно привести его к реальному типу, но клиент не будет знать, что это за тип.

Я, наверное, не очень хорошо объясняю это. В двух словах, мне нужно:

  • Создание рабочего объекта любого типа
  • Передайте его службе WCF, чтобы сохранить его в БД
  • Позвоните в службу WCF, чтобы получить новый рабочий элемент (все, что он найдет)
  • Верните клиенту этот рабочий элемент как реальный (не приведенный) объект

Моя очередь должна быть очень общей, так как многие другие приложения добавляют и удаляют рабочие элементы. Это разработано для массивной параллельной системы и будет центром для всех распределенных рабочих элементов. Любая помощь и идеи будут очень ценны.

Спасибо

Скотт

Ответы [ 2 ]

1 голос
/ 02 декабря 2011

Вы смотрели на ServiceKnownTypeAttribute?Посмотрите пример кода на этом MSDN: http://msdn.microsoft.com/en-us/library/system.servicemodel.serviceknowntypeattribute.aspx

0 голосов
/ 02 декабря 2011

это действительно идеальный сценарий для использования базы данных NOSQL, такой как CouchDB . Такая база данных полезна, если вам нужно хранить данные, которые не связаны с жесткой схемой, но основаны на задачах, связанных с документами (или в вашем случае). вы определяете их по типу, но основная структура не связана.

Является ли CouchDB опцией? затем оформить заказ relax - .NET API для CouchDB.

Если нет, просто храните базовые данные, такие как тип, созданный, ... (базовые данные, которые необходимо настроить для запроса для получения следующей задачи в очереди) в отдельных столбцах таблицы задач SQL. а затем у вас есть столбец с названием details или workitem, который содержит подробную информацию о вашей задаче в виде XML.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...