Вопрос .Net-чикам

[Andrej]

Есть некий windows service, в котором обрабатываются некие задачи в разных потоках. Есть также клиент на другом сервере, который может по желанию запросить состояние любой задачи. Каждая задача - инстанс класса, который поддерживает xml сериализацию. Вопрос - как это наиболее оптимально реализовать?
Пока есть 2 варианта- писать в базу при любом изменении состояния задачи или в определенный порт. Ни один ни другой мне особо не нравятся. Есть ли еще варианты?
ПС: сорс код для обоих сервера и клиента доступны.

[ABQ]

Если эта относительно простая система, не претендующая на "enterprise", можешь заюзать Remoting (хотя он уже считается "устаревшим").
Если хочесь сделать "по-взрослому" - сделай WCF сервис.

Я вопрос правильно понял? Или ты спрашиваешь как передать состояние задач из разных потоков в одно место, откуда они и будут запрашиваться?

[Andrej]

Если эта относительно простая система, не претендующая на "enterprise", можешь заюзать Remoting (хотя он уже считается "устаревшим").
Если хочесь сделать "по-взрослому" - сделай WCF сервис.

Я вопрос правильно понял? Или ты спрашиваешь как передать состояние задач из разных потоков в одно место, откуда они и будут запрашиваться?

Вся система не простая, но конкретно эта задача простая. Ремоутинга было б достаточно, но насколько я помню, что при ремоутинге, что при wcf на клиенте через прокси интерфейс по указанному каналу создается объект на сервере. А если объект уже создан и клиент пришел запросить его статус?

[007]

Я бы сохранял данные в базу. Мало ли чем и для чего они потом будут смотреться, обрабатываться, сравнивать результаты ранов и т.д. А WCF уже бы читал бы оттуда и передавал данные клиенту. Опять же, с доступной историей.

[Andrej]

Я бы сохранял данные в базу. Мало ли чем и для чего они потом будут смотреться, обрабатываться, сравнивать результаты ранов и т.д. А WCF уже бы читал бы оттуда и передавал данные клиенту. Опять же, с доступной историей.

Ну это то как раз понятно. вся история будет хранится в несколько другом виде. Динамику выполнения задач мне хранить не надо, да и потенциальная нагрузка на базу увеличится без необходимости.

Пока единственный нормальный выход - делать запрос в определенный порт и посылать сериализованный объект в ответ. Но как-то неохота заморачиваться с портами.

[leonidvp]

Можно сделать реестр текущих тасков. Каждая таска при запуске регистрируется в реестре. При подключении создается объект, который лезет в реестр и берет оттуда нужный статус.

[Andrej]

Можно сделать реестр текущих тасков. Каждая таска при запуске регистрируется в реестре. При подключении создается объект, который лезет в реестр и берет оттуда нужный статус.

Не, ну это совсем как-то по-уродски.
Короче, похоже придумал я тут более-менее решение, чтоб и базу не загрязнять и с портами и ремоутингом не заморачиваться. Буду юзать МQ.

[RomZes]

memached + DB?

[RomZes]

Вся система не простая, но конкретно эта задача простая. Ремоутинга было б достаточно, но насколько я помню, что при ремоутинге, что при wcf на клиенте через прокси интерфейс по указанному каналу создается объект на сервере. А если объект уже создан и клиент пришел запросить его статус?

разве обьект пересоздается? при ремоутинге?

[Andrej]

разве обьект пересоздается? при ремоутинге?

При ремоутингe oбьект создается и исполняется на сервере. Инициирует процесс создания - клиент через прокси интерфейс. Клиент дергает методы обьекта, которые исполняются на сервере.
как только обьект отработал или лиз кончился - GC его вычишает.

Моя задача с точностью до наоборот. Обьект живет своей жизнью на сервере. Если клиент хочет посмотреть его статус, то серверный код сериализует обьект и передает его клиенту. Серверный обьект удаляется независимо от клента.
Мой изначальный вопрос и был как это сделать, скажем, с помошью ремоутинга?

[RomZes]

создать обьект на сервере и держать его, потом с помощью проксирующего обьекта как то к нему обращатся? может тогда все таки БД + memached?

[Igorp]

При ремоутингe oбьект создается и исполняется на сервере. Инициирует процесс создания - клиент через прокси интерфейс. Клиент дергает методы обьекта, которые исполняются на сервере.
как только обьект отработал или лиз кончился - GC его вычишает.

Моя задача с точностью до наоборот. Обьект живет своей жизнью на сервере. Если клиент хочет посмотреть его статус, то серверный код сериализует обьект и передает его клиенту. Серверный обьект удаляется независимо от клента.
Мой изначальный вопрос и был как это сделать, скажем, с помошью ремоутинга?

You can use WCF instead.
So the idea is you have a windows service running on the server.
Being a service it runs all the time. The object you are after can be instantiated on the service start-up.
The client sends request to the server. The server code clones the instance of the object you are after and sends it back to the client.
Implementing this using WCF is a piece of cake.
Just remember you have to host the WCF in the windows service so it (the object) is alive all the time.

[Andrej]

You can use WCF instead.
So the idea is you have a windows service running on the server.
Being a service it runs all the time. The object you are after can be instantiated on the service start-up.
The client sends request to the server. The server code clones the instance of the object you are after and sends it back to the client.
Implementing this using WCF is a piece of cake.
Just remember you have to host the WCF in the windows service so it (the object) is alive all the time.

Хорошая идея. Подумаю. Только есть еше одна проблемка.[Win service может быть не один, а несколько на разных машинах. У каждого свой пул задач. В этом случае каждый сервер должен иметь [WCF] интерфейс, а клиент (say, IIS) определять какой из серверов дергать.
Вообше идея хорошая, спасибо.

[Andrej]

создать обьект на сервере и держать его, потом с помощью проксирующего обьекта как то к нему обращатся?

Вот в этом "как-то" и есть корень проблемы

может тогда все таки БД + memached?

как-то не рекомендуют это чудо в продакшне пользовать. Мне нужны проверенные технологии.

Вот Игорь предложил неплохую идею захостить WCF в сервисе и по TCP дергать его методы.
Ну еше MQ со cчетов не сбрасываю. Будет слегка помедленнее конечно, но тоже неплохо.

[ABQ]

При ремоутингe oбьект создается и исполняется на сервере. Инициирует процесс создания - клиент через прокси интерфейс. Клиент дергает методы обьекта, которые исполняются на сервере.
как только обьект отработал или лиз кончился - GC его вычишает.

Моя задача с точностью до наоборот. Обьект живет своей жизнью на сервере. Если клиент хочет посмотреть его статус, то серверный код сериализует обьект и передает его клиенту. Серверный обьект удаляется независимо от клента.
Мой изначальный вопрос и был как это сделать, скажем, с помошью ремоутинга?

Не правильно. Я помню делал что объект на сервере, переданный по remoting'у жил до остановки приложения. Не помню подробностей, но в простейшем случае ты можешь просто присвоить ссылку на него статическому полю.