Привет all,

есть задача разработать application сервер, как прослойка между GUI клиентом и BD. Подскажите, какие технологии можно использовать. Одно из требований — это нотификация подключенных клиентов об изменениях в бд. Почитал форум, пришел к выводу, что использование remoting callback не есть хорошо. А что использовать тогда? пишу на c# net 2.0

Здравствуйте, <Аноним>, Вы писали:

А>есть задача разработать application сервер, как прослойка между GUI клиентом и BD. Подскажите, какие технологии можно использовать.

Любые

А> Одно из требований — это нотификация подключенных клиентов об изменениях в бд.

SQL Server Notification Services, WCF

А> Почитал форум, пришел к выводу, что использование remoting callback не есть хорошо.

Правильно.

А>А что использовать тогда? пишу на c# net 2.0

WCF

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

AVK>SQL Server Notification Services
Не, NS — это немного не то.. Это мыло, sms и прочий стаф, чтобы не дать человеку спокойно поспать...
для того чтобы дергать приложение есть Service Broker... =)

Здравствуйте, <Аноним>, Вы писали:

А>есть задача разработать application сервер, как прослойка между GUI клиентом и BD. Подскажите, какие технологии можно использовать. Одно из требований — это нотификация подключенных клиентов об изменениях в бд. Почитал форум, пришел к выводу, что использование remoting callback не есть хорошо. А что использовать тогда? пишу на c# net 2.0

А как клиенты работают с application сервером? Если это WCF то, там есть свои средства. Если remoting то, там тоже можно найти свои механизмы. Другой вопрос, какие действия должна порождать нотификация. Не получится так, что получив нотификацию клиенты устроят серверу DDoS атаку обновляя измененные данные?

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

TK>А как клиенты работают с application сервером? Если это WCF то, там есть свои средства. Если remoting то, там тоже можно найти свои механизмы. Другой вопрос, какие действия должна порождать нотификация. Не получится так, что получив нотификацию клиенты устроят серверу DDoS атаку обновляя измененные данные?

Предполагается после получения нотификаций вытягивать измененные данные. Использовать необходимо только NET 2.0. App сервер имеет список клиентов активных и рассылает им изменненные данные.

Спасибо за ответ.

К сожалению, использовать надо только net 2.0.

Как я пониманию при использовании SQL для нотификации делать app сервер вообще нету необходимости. После получения этой нотификации клиент сам может обновится. Но насколько я смог прочитать в интернете, при использовании sql нотификации, приходит сообщение о том, что данные были изменены, но какие данные были изменены — этого нету.

Спасибо за ответ.

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

Y>После получения этой нотификации клиент сам может обновится. Но насколько я смог прочитать в интернете, при использовании sql нотификации, приходит сообщение о том, что данные были изменены, но какие данные были изменены — этого нету.

И это правильно.

AndrewVK wrote:
> И это правильно.
Что в этом правильного? Если бы приходили обновленные данные — клиенту
не обязательно было бы делать запросы к базе для получения этих самых
обновлений.

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

>> И это правильно.
C>Что в этом правильного?

Это уже двести раз обсуждалось в топиках про сетевой колбек.

AndrewVK wrote:
>> > И это правильно.
> C>Что в этом правильного?
> Это уже двести раз обсуждалось в топиках про сетевой колбек.
Не вижу проблем. У меня используется подобный подход — в результате имею
сервер с кучей подключеных клиентов, не долбящих его всей толпой каждые
пару секунд.

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

C>Не вижу проблем. У меня используется подобный подход — в результате имею
C>сервер с кучей подключеных клиентов, не долбящих его всей толпой каждые
C>пару секунд.

У вас реализован application server? с использованием remoting? Можно услышать пару слов про архитектуру?

Спасибо за ответ.

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

>>> > И это правильно.
>> C>Что в этом правильного?
>> Это уже двести раз обсуждалось в топиках про сетевой колбек.
C>Не вижу проблем. У меня используется подобный подход — в результате имею
C>сервер с кучей подключеных клиентов, не долбящих его всей толпой каждые
C>пару секунд.

Надо думать не только о своей сиюминутной выгоде но и о развитии индустрии. Кто будет покупать большие сервера и толстые каналы???

ybouts wrote:
> C>Не вижу проблем. У меня используется подобный подход — в результате имею
> C>сервер с кучей подключеных клиентов, не долбящих его всей толпой каждые
> C>пару секунд.
> У вас реализован application server? с использованием remoting? Можно
> услышать пару слов про архитектуру?
Сервер написан на Java, с использованием Hibernate для общения с базой
данных. Клиенты для соединения с сервером используют аналог Remoting'а,
тут ничего интересного нет.

Более интересное — работа с событиями. При коммите из Hibernate я
получаю список событий, всего событий 6 штук: BlobUpdateEvent,
CollectionNukeEvent, CollectionUpdateEvent, DeleteEvent, InsertEvent,
UpdateEvent. Затем эти события скармливаются клиентам (попутно проходя
проверки на ACL). С базой на запись у нас напрямую никто не работает,
так что тут проблем нет.

Для доставки сообщений мы написали свою систему (ни одна существующих не
удовлетворяла по скорости). Клиенты подключаются к серверу по HTTP и
пытаются забрать сообщения, если сообщения есть — они тут же ему
отдаются. Если сообщений нет, то на сервер ждет с открытым каналом до
истечения таймаута (AFAIR, 40 секунд) или поступления сообщений. Это
сейчас называется модным словом Comet

Так как с транзакционными границами в такой системе все плохо (доставка
сообщения на клиент — суть асинхронна), то мы используем оптимистические
блокировки и автоматическое версирование всех объектов — благо Hibernate
это делает автоматически.

На клиентской стороне тоже есть свой кэш — он как раз обновляется этими
сообщениями. Этот кэш используют как источник данных локальные сессии
(естественно, с прозрачной ленивой загрузкой недостающих данных). Да,
еще при начале работы оказалось очень эффективно сразу скачать все
необходимые данные, которые пользователь может увидеть в приложении —
это спасает от тучи мелких запросов.

Это все кластеризовано и за-failover'ено. Общение клиентов с сервером
полностью stateless, для серверного кэша используется JBoss Cache и
Oracle Coherence.

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

Y>Предполагается после получения нотификаций вытягивать измененные данные. Использовать необходимо только NET 2.0. App сервер имеет список клиентов активных и рассылает им изменненные данные.

Можно написать простейший RemotingChannel который, будет рассылать уведомления клиентам через MailSlot или MultiCast группу — это не даст большой нагрузки на сервер (сама рассылка) хотя, данные способы не являются гарантированными способами доставки (но, можно предусмотреть превентивные меры). Кроме этого, можно попробовать решение в стиле WCF — через двунапрвленный канал и специальную очередь для исходящих сообщений...

Спасибо за ответ, буду теперь думать.

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

TK>Можно написать простейший RemotingChannel который, будет рассылать уведомления клиентам через MailSlot или MultiCast группу — это не даст большой нагрузки на сервер (сама рассылка) хотя, данные способы не являются гарантированными способами доставки (но, можно предусмотреть превентивные меры). Кроме этого, можно попробовать решение в стиле WCF — через двунапрвленный канал и специальную очередь для исходящих сообщений...

А не подскажите ресурсов, примеров, где можно прочитать про реализацию такого Remoting channel?

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

Y>А не подскажите ресурсов, примеров, где можно прочитать про реализацию такого Remoting channel?

Тут можно взять пример с реализацией любого канала (например, этого) — для MailSlot подобная реализация должна быть более чем простой.

Можно еще вопрос, а клиенты при загрузке данных обращается напрямую к БД или же обращаются к application server, и еще при обращении к app server вычитываются простые данные, или же передаются бизнес объекты?

Спасибо за ответы, очень помогли.

Аноним 47 wrote:
> Можно еще вопрос, а клиенты при загрузке данных обращается напрямую к БД
> или же обращаются к application server, и еще при обращении к app server
> вычитываются простые данные, или же передаются бизнес объекты?
И то, и другое

У меня используется ORM — объекты доменной модели напрямую отображаются
в базу данных. Они так же передаются клиенту.

Здравствуйте, Аноним, Вы писали:

<skipped>

По идее, в вашем случае можно использовать и .Net Remoting. Особенно, если
нагрузка не будет очень большой. Для обратной нотификации клиентов об изменениях
в СУБД можно воспользоваться другим механизмом, например MSMQ, UDP и т.д.

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

Удачи!