Здравствуйте.

Есть некое веб-приложение, написанное на .NET 1.1. А точнее это не одно, а целый комплекс связанных друг с другом веб-приложений, веб-сервисов и т.д. Так вот, есть стандартная задачка — выгрузка данных из БД в промежуточный формат (в моем случае XML). Изначально я реализовал данную функциональность в виде веб-сервиса. В его задачу входило просто формирование XML-файла (а точнее папки с файлами, но не буду загромождать деталями). Причем, чтобы не заставлять клиента ожидать, из контекста веб-сервиса запускался отдельный поток (или потоки) который непосредственно "формировал" файл. Но я нарвался на серьезную проблему. Процесс выгрузки может занимать значительное время (более 2-3 часов за милую душу). При стандартной настройке же IIS поток убивается если он находиться в режиме ожидания больше 20 минут. Вызов ХП из веб-сервиса как раз и считается "ожиданием" ну или простоем, не помню как правильно назвать, но идея должна быть ясна. Итак, я понял, что веб-сервисы просто по своей природе не предназначены для выполнения длительных операций. Итого, я решил сделать из текущего веб-сервиса просто координатор запросов. Т.е. вычленить всю эту долговыполнимую логику в отдельную сущность, а веб-сервис ее просто будет вызывать (веб-сервис по сути "фасад" полного функционала).

Итого, вопрос:
Какой тип приложения выбрать в качестве вот такой теневой лошадки, которую будет вызывать веб-сервис?

Необходимо учесть:
— не должно быть необходимости в доп. настройке чего-либо (того же IIS, к примеру). Вся настройка должна быть в инстольнике.
— была возможность выполнять длительные операции без намека на ограничение времени выполнения!

Сейчас я склоняюсь в сторону вин-сервиса. Меня смущает пока только (я плохо в них разбираюсь):
— много одновременных запросов. Как себя ведет вин-сервис при поступлении 2х одновременных запросов?
— так и не понял пока как комфортно цеплять методы вин-сервиса. Есть кошмарное предположение, что вин-сервис ОЧЕНЬ не похож на веб-сервис в смысле вывешивания интерфейса )). Итого встает проблема передачи параметров необходимых для выгрузки.

Реализация в виде DLL:
— сомневаюсь, что уйду от проблемы ограничения времени выполнения. Наверняка ведь код будет выполняться в контексте IIS-процесса и будет "подпадать" под все ограничения.

Или плюнуть на все и реализовать в виде какого-нибудь windowless console/form application. Но тут:
— без понятия, уйду ли я от ограничений по времени.
— будет ли это эффективно при сравнительно большом к-ве одновременных вызовов (20-30).

P.S. Рассматриваю так же вариант вин-сервиса, который будет просматривать некую табличку в БД в поисках задач выгрузки на выполнение. Если бы еще можно что-то типа оповещателя повесить, чтобы не сервис опрашивал по таймеру БД, а она при вставке новой строки в таблицу задач дергнул .NET-код. Типа триггер "after insert" вызывает event каким-то образом...

Вот такая вот кучка вопросов )). Буду очень признателен любым советам/комментариям

Здравствуйте, Byter, Вы писали:

Помнится, в ASP.NET можно настроить тайм-аут сессии, не пробовали?

Здравствуйте, rsn81, Вы писали:

R>Помнится, в ASP.NET можно настроить тайм-аут сессии, не пробовали?

Тайм-аут сессии — немного не то. То про что я говорю (сейчас не поленился посмотрел как точно называтеся) — Idle Timeout. Причем задается не для одного сайта, а для всего пула приложения. У меня IIS 6:
1) Application Pools -> DefaultAppPool (там веб-сервис висит) -> right-click, Properties -> закладка Performance -> Самая верхняя строка:

Shutdown worker process after being idle for (time in minutes)

По умолчанию стоит 20 минут, что совпадает со значением по умолчанию времени простоя без потери для сессии. Но я так понимаю, что влияет на веб-сервис именно этот параметр, а не time-out сессии. Для сервиса понятие сессии собственно говоря довольно размытое.

Более того, по умолчанию веб-сервис сессии не использует. Но я специально ее включал и ставил большое время — не помогло.

Здравствуйте, Byter, Вы писали:

B>Необходимо учесть:
B>— не должно быть необходимости в доп. настройке чего-либо (того же IIS, к примеру). Вся настройка должна быть в инстольнике.
B>— была возможность выполнять длительные операции без намека на ограничение времени выполнения!
Виндовый сервис.

B>— много одновременных запросов. Как себя ведет вин-сервис при поступлении 2х одновременных запросов?
Как напишешь, так и поведет. Создай пул потоков и обрабатывай кучу запросов.

B>— так и не понял пока как комфортно цеплять методы вин-сервиса. Есть кошмарное предположение, что вин-сервис ОЧЕНЬ не похож на веб-сервис в смысле вывешивания интерфейса )). Итого встает проблема передачи параметров необходимых для выгрузки.
Есть куча средств. Я бы заюзал MSMQ. Хотя можно и просто через Remoting.

Здравствуйте, AndrewJD, Вы писали:

B>>— много одновременных запросов. Как себя ведет вин-сервис при поступлении 2х одновременных запросов?
AJD>Как напишешь, так и поведет. Создай пул потоков и обрабатывай кучу запросов.

О! А вот по этой теме нет случайно ссылочки какой-нибудь интересной? Что такое пул потоков я понимаю, а вот как реализовывать в вин-сервисе — хоть убей ))

B>>— так и не понял пока как комфортно цеплять методы вин-сервиса. Есть кошмарное предположение, что вин-сервис ОЧЕНЬ не похож на веб-сервис в смысле вывешивания интерфейса )). Итого встает проблема передачи параметров необходимых для выгрузки.
AJD>Есть куча средств. Я бы заюзал MSMQ. Хотя можно и просто через Remoting.

Ага, спасибо.

А вообще, как по-твоему, это нормально что веб-сервис вызывает вин-сервис? Нормальна ли вообще такая компоновка?

Здравствуйте, Byter, Вы писали:

B>О! А вот по этой теме нет случайно ссылочки какой-нибудь интересной?
К сожалению нет под рукой конкретных ссылок

B>Что такое пул потоков я понимаю, а вот как реализовывать в вин-сервисе — хоть убей ))
Используй стандартный System.Threading.ThreadPool

B>А вообще, как по-твоему, это нормально что веб-сервис вызывает вин-сервис? Нормальна ли вообще такая компоновка?
Собственно для этого сервисы и нужны

Здравствуйте, Byter, Вы писали:

B>Здравствуйте, AndrewJD, Вы писали:

B>>>— много одновременных запросов. Как себя ведет вин-сервис при поступлении 2х одновременных запросов?
AJD>>Как напишешь, так и поведет. Создай пул потоков и обрабатывай кучу запросов.

B>О! А вот по этой теме нет случайно ссылочки какой-нибудь интересной? Что такое пул потоков я понимаю, а вот как реализовывать в вин-сервисе — хоть убей ))

попробуй посмотреть на эту реализацию пула потоков

Здравствуйте, Byter, Вы писали:
B>Итого, вопрос:
B>Какой тип приложения выбрать в качестве вот такой теневой лошадки, которую будет вызывать веб-сервис?
Вариант ровно один: вин сервис.
DLL не проходит, т.к. она собственно работает в контексте вызывающего процесса, и естественно никак не влияет на его время жизни.
Консольное/оконное приложение живет только в рамках пользовательской сессии. Логаут — и приплыли, нету приложения.

А вот как раз за то, чтобы 100% времени находиться в ожидании/работе, отвечает win service.
Бояться его не стоит; это всего лишь специальный тип приложения, которое работает не по схеме "исполнил main() — вернул результат — закрылся". Вариантов взаимодействия с вин.сервисом очень много, точнее, сама спецификация вин сервиса никак не оговаривает способы его взаимодействия с клиентами.

Это совершенно стандартная практика: например, MS SQL Server Reporting Services представляют конгломерат из трех приложений:
— веб приложение для UI
— web service, обслуживающий UI и других клиентов
— win service, выполняющий длительную работу, работу по расписанию, и так далее.

Здравствуйте, Byter, Вы писали:

B>Здравствуйте.

B>Есть некое веб-приложение, написанное на .NET 1.1. А точнее это не одно, а целый комплекс связанных друг с другом веб-приложений, веб-сервисов и т.д. Так вот, есть стандартная задачка — выгрузка данных из БД в промежуточный формат (в моем случае XML). Изначально я реализовал данную функциональность в виде веб-сервиса. В его задачу входило просто формирование XML-файла (а точнее папки с файлами, но не буду загромождать деталями). Причем, чтобы не заставлять клиента ожидать, из контекста веб-сервиса запускался отдельный поток (или потоки) который непосредственно "формировал" файл. Но я нарвался на серьезную проблему. Процесс выгрузки может занимать значительное время (более 2-3 часов за милую душу). При стандартной настройке же IIS поток убивается если он находиться в режиме ожидания больше 20 минут. Вызов ХП из веб-сервиса как раз и считается "ожиданием" ну или простоем, не помню как правильно назвать, но идея должна быть ясна. Итак, я понял, что веб-сервисы просто по своей природе не предназначены для выполнения длительных операций. Итого, я решил сделать из текущего веб-сервиса просто координатор запросов. Т.е. вычленить всю эту долговыполнимую логику в отдельную сущность, а веб-сервис ее просто будет вызывать (веб-сервис по сути "фасад" полного функционала).

B>Итого, вопрос:
B>Какой тип приложения выбрать в качестве вот такой теневой лошадки, которую будет вызывать веб-сервис?

Я думаю, что тут решение нужно принимать из ходя из самой задачи. А задача следующая, выгрузить базу в XML (CSV, ...). По описанию, база содержит значительный объем данных, если даже выполнение этой задачи может достигать 2-3 часа. Здесь появляется сразу несколько проблем, которые необходимо решать. Главные из них, это
1) таймаут,
2) актуальность данных. — После выполнения задачи, данные, вернувшиеся первыми, могут быть неактуальными по отношению к данным, вернувшимися последними.

Т.е. задачу надо изменить. Я думаю, что задача должна быть в следующем: Создание snapshot'a. Тогда клиентам можно отдавать ссылки на последний snapshot. Здесь, отпадают проблемы с веб-сервисами. Остаётся только один веб-сервис с методами:
1) DateTime[] GetAvailableSnapshots()
2) string[] GetLatestSnapshot()
3) string[] GetSnapshot(DateTime timestamp)
4) ... можно ещё придумать....

Для приложения, как опцию, можно рассмотреть MSSQL DTS (или также MSSQL Agent Jobs). Создаешь пакет трансформации данных (достаточно сложный, но реалитзовать можно). Далее пишешь простой батник с вызовом DTSRun <DTS_PACKAGE_ID>. В Windows Scheduled Tasks вешаешь запуск этого батника по расписанию. Главное запускать его под админом.

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

Более, того можно разработать веб-сервис для администрирования и мониторинга снимков, с методами:
1) DateTime[] GetAvailableSnapshots()
2) bool DeleteSnapshot(DateTime timestamp)
3) void StartSnapshot(). Raise exception if there is active snapshot
4) SnapshotStatus GetSnapshotStatus() — статусы:
Not Ready — нет снимков,
Starting — запускается (подготовка, инициализация ресурсов),
Started — запущен (подготовка закончена),
In Progress — в процессе, процент можно узнать вызвав GetSnapshotStatus()
Finishing — заканчиваем (очистка выделенных ресурсов),
Finished — закончен (окончательная очистка),
Ready — есть готовый снимок.
5) int GetSnapshotProgress(). Raise exception if there's no active snaphot, otherwice % of work done.
6) void CancelSnapshot().

Вот примерно какое надо решение. его конечно можно (нужно) улучшить. Чтобы выполнялся пункт 2.
Возможно нужно или 1) блокировать базу данных (только для чтения), или 2) работать с копией.

Здравствуйте, Byter, Вы писали:

B>Здравствуйте.

B>Есть некое веб-приложение, написанное на .NET 1.1. А точнее это не одно, а целый комплекс связанных друг с другом веб-приложений, веб-сервисов и т.д. Так вот, есть стандартная задачка — выгрузка данных из БД в промежуточный формат (в моем случае XML). Изначально я реализовал данную функциональность в виде веб-сервиса. В его задачу входило просто формирование XML-файла (а точнее папки с файлами, но не буду загромождать деталями). Причем, чтобы не заставлять клиента ожидать, из контекста веб-сервиса запускался отдельный поток (или потоки) который непосредственно "формировал" файл. Но я нарвался на серьезную проблему. Процесс выгрузки может занимать значительное время (более 2-3 часов за милую душу). При стандартной настройке же IIS поток убивается если он находиться в режиме ожидания больше 20 минут. Вызов ХП из веб-сервиса как раз и считается "ожиданием" ну или простоем, не помню как правильно назвать, но идея должна быть ясна. Итак, я понял, что веб-сервисы просто по своей природе не предназначены для выполнения длительных операций. Итого, я решил сделать из текущего веб-сервиса просто координатор запросов. Т.е. вычленить всю эту долговыполнимую логику в отдельную сущность, а веб-сервис ее просто будет вызывать (веб-сервис по сути "фасад" полного функционала).

Посмотри ещё здесь. Возможно будет интересно.

B>P.S. Рассматриваю так же вариант вин-сервиса, который будет просматривать некую табличку в БД в поисках задач выгрузки на выполнение. Если бы еще можно что-то типа оповещателя повесить

Я бы так и сделал. Пинать сервис, чтобы табличку посмотрел, можно через named Win32 event. Можно и вовсе не пинать

S>Консольное/оконное приложение живет только в рамках пользовательской сессии. Логаут — и приплыли, нету приложения.

Переопределяется logoff event — и все консольные приложения, запущенные из-под IIS или из вин-сервиса — живут себе.

Другое дело, что, если его запускать из веб-сервиса и ждать, то IIS наложит то же самое ограничение по времени.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Я бы так и сделал. Пинать сервис, чтобы табличку посмотрел, можно через named Win32 event. Можно и вовсе не пинать

ИМХО оверхед. Remoting/WCF с бинарным каналом здесь будут уместнее.