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

IT>Здравствуйте, MikaRSDN Soukhov, Вы писали:

MS>>Елы-палы Если бы было без коллбеков то я и спрашивать то не стал В том то и фишка В общем сервер без event-ов это что то не полноценное Типа Web Service (они то вообще существуют для простых запросов и никак не катят на центальное звено)

IT>Сервер он хоть с калбеками, хоть без калбеков сервер. Калбеки, решая определённый круг задач, значительно усложняют всю структуру приложения. А как известно, усложнять просто, упрощать сложно.

IT>Ты мне лучше скажи, какую ты задачу решаешь, а то мы так с тобой долго будем препираться.

Ну вообщем слухай сюды

Есть у нас тарификационный модуль (телефонные переговоры) Так вом есть клиент-программа, которые пересылает данные о телефонных звонках. В ответ на это сервер начинает обрабатывать этот запрос и принимает решение (все это роисходит за один синхронный вызов метода)
Допустим через некоторый момент звонит человек и говорит что мол надо бы обрубить его телефонный звоном. Это обрабатывает еще одна клиент-программа которая полылает опять серверу. Серверу надо переслать reject-ору (еще одна клиент-программа ) чтобы он убил сессию
Ну и как тут? Заходить в сетод и висеть в ней до искончания веков ? Лано Вообщем это только малая толика того модуля что это описал Мы тоже когда хотели переписать все на Web Service но потом посмотрели что это только усложнит логику

а как известно, усложнять просто, упрощать сложно

Пока

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

MS>Есть у нас тарификационный модуль (телефонные переговоры) Так вом есть клиент-программа, которые пересылает данные о телефонных звонках. В ответ на это сервер начинает обрабатывать этот запрос и принимает решение (все это роисходит за один синхронный вызов метода)
MS> Допустим через некоторый момент звонит человек и говорит что мол надо бы обрубить его телефонный звоном. Это обрабатывает еще одна клиент-программа которая полылает опять серверу. Серверу надо переслать reject-ору (еще одна клиент-программа ) чтобы он убил сессию
MS> Ну и как тут? Заходить в сетод и висеть в ней до искончания веков ? Лано Вообщем это только малая толика того модуля что это описал Мы тоже когда хотели переписать все на Web Service но потом посмотрели что это только усложнит логику

Ну и к чему тут события? Если программа целиком пассивна значит это сервер, а никак не клиент. Делается как обычная транзакция. Клиент открывает сессию и закрывает. Другой клиент посылает команду на обрыв, на что сервер обращается к reject-ору. И никаких эвентов.

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

MS>Ну и как тут?

Ну батенька, тебе тут сам бог велел MSMQ использовать. Второе решение — опрашивать сервер периодически на предмет завершения обработки. Кстати, самый надёжный из возможнных вариантов.

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

AVK>Ну и к чему тут события? Если программа целиком пассивна значит это сервер, а никак не клиент. Делается как обычная транзакция. Клиент открывает сессию и закрывает. Другой клиент посылает команду на обрыв, на что сервер обращается к reject-ору. И никаких эвентов.

Сорри Забыл написать что rejector не просто исполняет какие то действия Ему тоже отведится временной период через который он должен обратися к серверу не передумал ли клиент, и если временной период закончился то рубит Если сделать так чтобы сервер еще и создавал таймер по которому он сам отсчитывает время, то тогда уж совсем как-то не то... Всю логику в сервер...
Тем более что запрос об отрубке это не секундное решение Сначала подсчитаем трафик раз двадцть(кстати сервер в любой момент времени может все это оборвать) На это уходит порядком 3 часа И вдруг случилось что то не придвиденное Тогда он должен оповестить сервер И что получается Сервер висит 3 часа пока не выполится метод или не произойдет исключение (Exception)...

Да и что говорить о без-эвентной технологии когда половина логики (если не больше) завязана как раз в такой узел

Web Service создавались не для этого Они не могут выступать в роли сервера Они клиенты (или транзакционные клиенты, или вспомогательные модули) но никак не логика многоуровневой системы

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

MS>Тем более что запрос об отрубке это не секундное решение Сначала подсчитаем трафик раз двадцть(кстати сервер в любой момент времени может все это оборвать) На это уходит порядком 3 часа И вдруг случилось что то не придвиденное Тогда он должен оповестить сервер И что получается Сервер висит 3 часа пока не выполится метод или не произойдет исключение (Exception)...

Что если за эти три часа клиент отвалиться? Кому сервер будет посылать ивент? При таком подходе твоя система будет супер ненадёжная.

MS>Да и что говорить о без-эвентной технологии когда половина логики (если не больше) завязана как раз в такой узел

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

MS>Web Service создавались не для этого Они не могут выступать в роли сервера Они клиенты (или транзакционные клиенты, или вспомогательные модули) но никак не логика многоуровневой системы

Это смотря как на это хозяйство посмотреть. Задача сервера — обрабатывать запросы. По-твоему получается, что RSDN.ru не сервер, так как на нём используются веб-сервисы

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

K>>А как у тебя с безопасностью, СОМ+ сажает на прослушивание MarshalByRefObject объекты, клиент первоначально обращается к СОМ+, аутентифицируется, СОМ+ фозвращает ему MarshalByRefObject объект с которым клиент работает в дальнейшем. Так?

IT>Нет, я же говорю, что COM+ отдыхает, я его не использую по религиозным убеждениям.

Тогда может расскажешь как?

K>>А как же тормоза с XML, насколько я понял этот клиент выполняет осоновные бизнес задачи, и общается исключительно через веб сервисы.

IT>Смотри статью в RSDN Mag #2 где сравнивается производительность ремотинга, вебсервисов и DCOM. Веб-сервисы на моём оборудовании примерно в 5-6 раз медленнее, чем ремотинг. Это не мало, но если пересчитать затраты на один вызов, то это 1 ms против 6 ms. Но я надеюсь, что твои объекты делают что-то разумное, и если эти действия занимают 10 ms, то это уже 11 ms против 16 ms, т.е. 1.45 раз (уже не 6). А если твои действия длятся 100 ms, то 101 притив 106 — 1.05 раз. Делай выводы.

Иногда приличные объемы данных путем простой выборки приходится тянуть на клиента и тогда уже могут начаться тормоза не в 1,05 раза, а в 2-3

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

MS>Сорри Забыл написать что rejector не просто исполняет какие то действия

На кой черт он тогда нужен?

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

Что то ты все с ног на голову ставишь. Я же тебе говорю — коль скоро он пассивен то это сервер, ничего он ждать не должен, его самого должны дернуть.

MS> то тогда уж совсем как-то не то... Всю логику в сервер...

Кой черт нужнен сервер, кроме как для реализации логики?

MS> Тем более что запрос об отрубке это не секундное решение Сначала подсчитаем трафик раз двадцть(кстати сервер в любой момент времени может все это оборвать) На это уходит порядком 3 часа И вдруг случилось что то не придвиденное Тогда он должен оповестить сервер И что получается Сервер висит 3 часа пока не выполится метод или не произойдет исключение (Exception)...

Хе хе, ты думаешь сообщение дает гарантию что он таки отрубится? Тут у тебя что то не то в структуре, и события тебе не помогут.

MS> Web Service создавались не для этого Они не могут выступать в роли сервера

Ик.

MS>Они клиенты (или транзакционные клиенты, или вспомогательные модули) но никак не логика многоуровневой системы

Веб-сервис это просто внешний интерфейс и ничего более.

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

....
IT>Что если за эти три часа клиент отвалиться? Кому сервер будет посылать ивент? При таком подходе твоя система будет супер ненадёжная.
....

А такой вариант реализации ивентов: — посылка (синхронного) запроса на сервер (из отдельного клиентского потока). Ответ сервера — это и будет "посылка" ивента клиенту? (Естественно с отработкой всяких таймаутов)

Сервер при этом остается самым пассивным из пассивных.

С уважением, Евгений.

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

MS>>Тем более что запрос об отрубке это не секундное решение Сначала подсчитаем трафик раз двадцть(кстати сервер в любой момент времени может все это оборвать) На это уходит порядком 3 часа И вдруг случилось что то не придвиденное Тогда он должен оповестить сервер И что получается Сервер висит 3 часа пока не выполится метод или не произойдет исключение (Exception)...

IT>Что если за эти три часа клиент отвалиться? Кому сервер будет посылать ивент? При таком подходе твоя система будет супер ненадёжная.

Да точно так же может и отвалится сервер Ну и если у тебя отвалится клиент и вместе с ним перестанет работать сервер (больше некому ему пинать будет) Ничем не лучше чем у нас

MS>>Да и что говорить о без-эвентной технологии когда половина логики (если не больше) завязана как раз в такой узел

IT>Хреновая логика. Ивенты нормально работают в пределах одной машины, но не в сети. В сети есть куча причин, по которым твой ивент может быть не доставлен клиенту никогда. Я почти уверен, что твоя логика не предполагает такой возможности, если бы предполагала, то ты с самого начала искал бы другое решение.

Вы решили избавится от эвентов только из-за того что они не проходят проксю? Если так то это круто Изменять логику системы по причине прокси Вообще я с начала думал что вы пришли в Web Service только из за поддержки win-клиентов Тоесть отказались от чистого C# в пользу старых технологий Теперь ты говоришь что не хочешь использовать эвенты только из-за религиозных соображений (я начинаю склонятся в сторону Влада с его COM+) В чем истина? Мы оградили своих старых клиентов именно интеропом а внутри осталось все ремотингнутое и эвентное Да, у нас пока все внутри-локальное Но я уверен что когда мы перейдем на Web (что в принципе уже начинается частично) то мы и тогда будет искать выход

MS>>Web Service создавались не для этого Они не могут выступать в роли сервера Они клиенты (или транзакционные клиенты, или вспомогательные модули) но никак не логика многоуровневой системы

IT>Это смотря как на это хозяйство посмотреть. Задача сервера — обрабатывать запросы. По-твоему получается, что RSDN.ru не сервер, так как на нём используются веб-сервисы

Я не это имел ввиду Сервис которые складывает 2 числа не может быть сервером Он является калькулятором Ну да ладно Когда появятся эвенты для HTTP тогда вы по другому заговорите

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

AVK>Что то ты все с ног на голову ставишь. Я же тебе говорю — коль скоро он пассивен то это сервер, ничего он ждать не должен, его самого должны дернуть.

Да ни то ни другое пассивно Оно параллельно выполняется Просто одно имеет дело с 40 дочерними программами о другая ни с одной

MS>> то тогда уж совсем как-то не то... Всю логику в сервер...

AVK>Кой черт нужнен сервер, кроме как для реализации логики?

Всю логику на сервер ?

MS>> Тем более что запрос об отрубке это не секундное решение Сначала подсчитаем трафик раз двадцть(кстати сервер в любой момент времени может все это оборвать) На это уходит порядком 3 часа И вдруг случилось что то не придвиденное Тогда он должен оповестить сервер И что получается Сервер висит 3 часа пока не выполится метод или не произойдет исключение (Exception)...

AVK>Хе хе, ты думаешь сообщение дает гарантию что он таки отрубится? Тут у тебя что то не то в структуре, и события тебе не помогут.

Как и все в нашей жизни ни что не дает 100% гарантию

MS>>Они клиенты (или транзакционные клиенты, или вспомогательные модули) но никак не логика многоуровневой системы

AVK>Веб-сервис это просто внешний интерфейс и ничего более.

Так что же выступит в роли сервера?

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

IT>>Что если за эти три часа клиент отвалиться? Кому сервер будет посылать ивент? При таком подходе твоя система будет супер ненадёжная.

MS>Да точно так же может и отвалится сервер Ну и если у тебя отвалится клиент и вместе с ним перестанет работать сервер (больше некому ему пинать будет) Ничем не лучше чем у нас

Намного лучше
У тебя клиент отвалился и тут серверу вздумалось послать ему ивент, опа, а получателя нет. Событие пропало и никогда больше не появится в системе.
Без ивентов, например, клиент периодичекси опрашивает сервер. Клиент отвалился, ну и ладненько, сервер о нём всё равно ничего не знает. Отвалился сервер, клиент запросит данные позже, когда сервер оживёт. Всё работает.

MS>Вы решили избавится от эвентов только из-за того что они не проходят проксю?

Вот тебе ещё одна причина.

MS>Если так то это круто Изменять логику системы по причине прокси Вообще я с начала думал что вы пришли в Web Service только из за поддержки win-клиентов Тоесть отказались от чистого C# в пользу старых технологий

Не отказались в пользу старых технологий, а решили зачехлить шашки и обойтись без лозунгов "Мы наш, мы новый мир построим!". Всему своё время, всё будет переписано, но little by little.

MS>Теперь ты говоришь что не хочешь использовать эвенты только из-за религиозных соображений (я начинаю склонятся в сторону Влада с его COM+) В чем истина?

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

MS>Мы оградили своих старых клиентов именно интеропом а внутри осталось все ремотингнутое и эвентное Да, у нас пока все внутри-локальное Но я уверен что когда мы перейдем на Web (что в принципе уже начинается частично) то мы и тогда будет искать выход

Периодический опрос сервера клиентом

IT>>Это смотря как на это хозяйство посмотреть. Задача сервера — обрабатывать запросы. По-твоему получается, что RSDN.ru не сервер, так как на нём используются веб-сервисы

MS>Я не это имел ввиду Сервис которые складывает 2 числа не может быть сервером Он является калькулятором Ну да ладно Когда появятся эвенты для HTTP тогда вы по другому заговорите

А что тогда в твоём понимании сервер? И когда появяться ивенты для HTTP?

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

IT>Намного лучше
IT>У тебя клиент отвалился и тут серверу вздумалось послать ему ивент, опа, а получателя нет. Событие пропало и никогда больше не появится в системе.
IT>Без ивентов, например, клиент периодичекси опрашивает сервер. Клиент отвалился, ну и ладненько, сервер о нём всё равно ничего не знает. Отвалился сервер, клиент запросит данные позже, когда сервер оживёт. Всё работает.

Клиент отвалится Эвент выкинули и когда снова подключился то получили новый
Что пропало то?

MS>>Вы решили избавится от эвентов только из-за того что они не проходят проксю?

IT>Вот тебе ещё одна причина.

Да Тут единственно место где single call лучше Но только здесь (и до поры до времени)

IT>Не отказались в пользу старых технологий, а решили зачехлить шашки и обойтись без лозунгов "Мы наш, мы новый мир построим!". Всему своё время, всё будет переписано, но little by little.

Тоже и у нас Просто на эвентах много было всего посторено и чтобы не ломать логику решили таким путем Хорошим путем

MS>>Теперь ты говоришь что не хочешь использовать эвенты только из-за религиозных соображений (я начинаю склонятся в сторону Влада с его COM+) В чем истина?

IT>Дело в том, что мне не надо было отказываться от ивентов, т.к. я их не применял. Почему я уже сказал, ивенты в сети пораждают больше проблем, чем решают, к тому же их всегда можно заменить другими решениями. На локальной машине пользуйся ими сколько хочешь.

Да чем раздражают то !? Все нормально Может ты и изменения файла будешь отсматривать путем сканирования его 50 раз в сек ?

MS>>Мы оградили своих старых клиентов именно интеропом а внутри осталось все ремотингнутое и эвентное Да, у нас пока все внутри-локальное Но я уверен что когда мы перейдем на Web (что в принципе уже начинается частично) то мы и тогда будет искать выход

IT>Периодический опрос сервера клиентом

Докажешь что лучше, сделаем так.

IT>>>Это смотря как на это хозяйство посмотреть. Задача сервера — обрабатывать запросы. По-твоему получается, что RSDN.ru не сервер, так как на нём используются веб-сервисы

MS>>Я не это имел ввиду Сервис которые складывает 2 числа не может быть сервером Он является калькулятором Ну да ладно Когда появятся эвенты для HTTP тогда вы по другому заговорите

IT>А что тогда в твоём понимании сервер? И когда появяться ивенты для HTTP?

Про когда я проигнорирую с ответом Ну а насчет сервера По-моему я уже сказал Сервер это активная субстанция которая сама может реагировать на действия и их возбуждать А у тебя это простой вызов функции из DLL

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

MS>Да Тут единственно место где single call лучше Но только здесь (и до поры до времени)

До поры до времени почему? ИМХО события через прокси не будут ходить никогда.

MS>Тоже и у нас Просто на эвентах много было всего посторено и чтобы не ломать логику решили таким путем Хорошим путем

Вот с этого надо и начинать.

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

AVK>Здравствуйте, MikaRSDN Soukhov, Вы писали:

MS>>Да Тут единственно место где single call лучше Но только здесь (и до поры до времени)

AVK>До поры до времени почему? ИМХО события через прокси не будут ходить никогда.

Будут, будут Это точно Но вот вопрос времени, когда?

MS>>Тоже и у нас Просто на эвентах много было всего посторено и чтобы не ломать логику решили таким путем Хорошим путем

AVK>Вот с этого надо и начинать.

Подожди Тут я не утверждаю что у нас система была завязана на эвентах потому и не ломал ее Я не ломал потому, что это было правильным решением А спрашивать сервер до опупения, не случилось ли что нить,- это ИМХО не правильно.

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

MS>Клиент отвалится Эвент выкинули и когда снова подключился то получили новый
MS>Что пропало то?

Т.е. у тебя ивенты персистентные, в базе храняться или как? И наверное есть механизм отслеживания получения события клиентом, транзакции всякие? Я правильно понимаю

IT>>Вот тебе ещё одна причина.

MS>Да Тут единственно место где single call лучше Но только здесь (и до поры до времени)

Он всегда лучше, ну почти всегда, поверь мне. SingleCall должен идти по умолчанию, над применением остальных нужно неслабо пораскинуть мозгами, прежде чем принимать решение

IT>>Не отказались в пользу старых технологий, а решили зачехлить шашки и обойтись без лозунгов "Мы наш, мы новый мир построим!". Всему своё время, всё будет переписано, но little by little.

MS>Тоже и у нас Просто на эвентах много было всего посторено и чтобы не ломать логику решили таким путем Хорошим путем

Понятно. Если у вас логика выползает на сторону клиента, до дело дрянь. А так можно было бы всё это хозяйство локализовать на сервере.

IT>>Дело в том, что мне не надо было отказываться от ивентов, т.к. я их не применял. Почему я уже сказал, ивенты в сети пораждают больше проблем, чем решают, к тому же их всегда можно заменить другими решениями. На локальной машине пользуйся ими сколько хочешь.

MS>Да чем раздражают то !? Все нормально Может ты и изменения файла будешь отсматривать путем сканирования его 50 раз в сек ?

А файлы тут причём? Всё это делается на локальной машине.

IT>>Периодический опрос сервера клиентом

MS>Докажешь что лучше, сделаем так.

Не докажу, пробовал я уже доказывать подобные вещи, сложно это. Если ты не видишь проблем, то ты их и не увидишь, пока сам на них не нарвёшься и через них на пузе не проползёшь. Вот я тебе говорю, что событие в сети потерять как два байта переслать, например, тётя Маша зацепила ногой сетевой провод или выдернула из розетки не ту вилку (заметь, твоя программа работае супернадёжно). Ты же мне говоришь что это всё фигня, ну и что мне после этого доказывать?

IT>>А что тогда в твоём понимании сервер? И когда появяться ивенты для HTTP?

MS>Про когда я проигнорирую с ответом Ну а насчет сервера По-моему я уже сказал Сервер это активная субстанция которая сама может реагировать на действия и их возбуждать А у тебя это простой вызов функции из DLL

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

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

IT>Т.е. у тебя ивенты персистентные, в базе храняться или как? И наверное есть механизм отслеживания получения события клиентом, транзакции всякие? Я правильно понимаю

Ну знаешь Точно так же можно и спросить о вас. А запросы если не дошли до сервера у вас сохраняются? Ложатся в базу? Просто у нас это должно работать в обе стороны, а у вас только в одну. Да, тут твоя правда

MS>>Тоже и у нас Просто на эвентах много было всего посторено и чтобы не ломать логику решили таким путем Хорошим путем

IT>Понятно. Если у вас логика выползает на сторону клиента, до дело дрянь. А так можно было бы всё это хозяйство локализовать на сервере.

Сервер центральное звено У него своя логика, у клиента своя Пришел ему запрос допустим расквазитронить пучок света И что он должен делать? Расквазитронивать !? Да он и не знает что это такое. Зато то вот какой нить клиент знает об этом Он то и проделает все работу. Да и тем более ошибки так легче исправлять (деление больших задач на подзадачи)

MS>>Да чем раздражают то !? Все нормально Может ты и изменения файла будешь отсматривать путем сканирования его 50 раз в сек ?

IT>А файлы тут причём? Всё это делается на локальной машине.

Локально говоришь? Тогда так Есть программа, отслеживающая изменение файла с название fileName на машине А. Есть программа, которая задает название файла (fileName) который надо отслеживать. Этот (админ) находится на машине B
Как только произойдет изменение программа А пересылает инфу (ну там во сколько изменилось и кем) И само собой об этом должен узнать админ (если он активен) Как ты это сделаешь без эвентов
Ты наверное щас предложишь обращатся к серверу (у меня это представляется машина В) с какой то частотой и спрашивать его а не пришли ли изменения? Так?
Хорошо, пойду навстречу и напишу еще так У машины А и Б есть свои прокси (тоесть они уже не локально соединены)

MS>>Докажешь что лучше, сделаем так.

IT>Не докажу, пробовал я уже доказывать подобные вещи, сложно это. Если ты не видишь проблем, то ты их и не увидишь, пока сам на них не нарвёшься и через них на пузе не проползёшь. Вот я тебе говорю, что событие в сети потерять как два байта переслать, например, тётя Маша зацепила ногой сетевой провод или выдернула из розетки не ту вилку (заметь, твоя программа работае супернадёжно). Ты же мне говоришь что это всё фигня, ну и что мне после этого доказывать?

От эвентов я уже порядочно намучался Начиная еще с СОМ Но все равно считаю что без них нормальная система не может быть хорошо спроектирована

IT>Ещё раз. Сервер обрабатывает запросы клиентов, именно поэтому он и является сервером. То что ты подразумеваешь под сервером тоже конечно сервер, у нас тоже есть отдельный сервер, который нашпигован задачами с расписанием и стартует их время от времени. Но по твоему тот же SQL сервер вовсе не сервер, потому что он не генерирует запросы самому себе

Да я не то совсем хотел сказать !!! Наоборот У тебя выходит, что сервер это то, что выполняет какие-то запросы, а то, что уже само что-то делает, это уже не сервер.
Насчет SQL server, то это сервер Из названия видно

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

MS>Сервер центральное звено У него своя логика, у клиента своя Пришел ему запрос допустим расквазитронить пучок света И что он должен делать? Расквазитронивать !? Да он и не знает что это такое. Зато то вот какой нить клиент знает об этом Он то и проделает все работу. Да и тем более ошибки так легче исправлять (деление больших задач на подзадачи)

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

MS>От эвентов я уже порядочно намучался Начиная еще с СОМ Но все равно считаю что без них нормальная система не может быть хорошо спроектирована

Если честно — во всех тех тяжелых системах, которые я видел, эвентов не было. Серверные эвенты это вобще относительно новое веяние.

MS>Да я не то совсем хотел сказать !!! Наоборот У тебя выходит, что сервер это то, что выполняет какие-то запросы, а то, что уже само что-то делает, это уже не сервер.

То есть SQL-сервер сам ничего не делает? Ты не путай сервер приложений, и сервер в технологии клиент-сервер, это не одно и то же.

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

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

IT>>Т.е. у тебя ивенты персистентные, в базе храняться или как? И наверное есть механизм отслеживания получения события клиентом, транзакции всякие? Я правильно понимаю

MS>Ну знаешь Точно так же можно и спросить о вас. А запросы если не дошли до сервера у вас сохраняются? Ложатся в базу? Просто у нас это должно работать в обе стороны, а у вас только в одну. Да, тут твоя правда

Не, ну ты как маленький студебеккер

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

Теперь другой вариант. Я дома есть, ты меня запрягаешь и говоришь, чтобы я как только закончу, доставил данные тебе по такому-то адресу. Я, конечно, всё как положено делаю и тащу тебе результат. А тебя дома нет Забухал может, по девкам там, дело молодое. Что я сделаю? Правильно, проследую к мусоропроводу, у меня нет ни времени тебя ждать (сервер же всё-таки), ни места где твоё барахло хранить (дизайном не предусмотрено). Но отметку в базе данных о том что ты должен оплатить счёт я поставил, да и ещё кучу транзакций и изменений в данных наворотил.

Другое дело, если бы я тебе по e-mail сообщение послал (MSMQ) приходи забирай, либо ты сам бы мне позвонил и забрал результат (только часто звонить тоже не надо).

Но когда сервер начинает разносить результат работы клиентам, тут всё и начинается. Это же всё-таки не pizza delivery

MS>Сервер центральное звено У него своя логика, у клиента своя Пришел ему запрос допустим расквазитронить пучок света И что он должен делать? Расквазитронивать !? Да он и не знает что это такое. Зато то вот какой нить клиент знает об этом Он то и проделает все работу. Да и тем более ошибки так легче исправлять (деление больших задач на подзадачи)

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

IT>>А файлы тут причём? Всё это делается на локальной машине.

MS>Локально говоришь? Тогда так Есть программа, отслеживающая изменение файла с название fileName на машине А. Есть программа, которая задает название файла (fileName) который надо отслеживать. Этот (админ) находится на машине B

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

MS>От эвентов я уже порядочно намучался Начиная еще с СОМ Но все равно считаю что без них нормальная система не может быть хорошо спроектирована

Ты хотел сказать "с ними"

MS>Да я не то совсем хотел сказать !!! Наоборот У тебя выходит, что сервер это то, что выполняет какие-то запросы, а то, что уже само что-то делает, это уже не сервер.

Сервер, конечно, я обратного и не утверждал, даже пример тебе привёл, что у нас есть batch сервер, который по расписанию выполняет разнообразные задачи.

MS>Насчет SQL server, то это сервер Из названия видно

Так он же сам ничего не делает

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

AVK>Клиент может откинуть серверу нужный ему код (ну как типа программы на SQL для SQL-сервера), если ты не хочешь ручками логику на сервер класть. А в товем варианте надежность системы очень низкая, вероятность сбоя равна сумме вероятностей сбоя каждого компа. Администрирование такой системы при большом количестве клиентов превратится в ад. Не зря так народ тащится от интранет-приложений с веб-интерфейсом и терминал-сервисов. Это почти идеальный для администратора вариант.

Не согласен Пойдем по твоему пути У тебя получается что администратор знает и всю систему в целом и что такое расквазитронивание. Что есть не реально (или он знаток поверхностной информации) Тогда получается что должно быть 2 админа и оба они сидят в одном месте (на сервере) Зачем? Каждый бы мог управлять у себя.

MS>>От эвентов я уже порядочно намучался Начиная еще с СОМ Но все равно считаю что без них нормальная система не может быть хорошо спроектирована

AVK>Если честно — во всех тех тяжелых системах, которые я видел, эвентов не было. Серверные эвенты это вобще относительно новое веяние.

новое это относительно чего?

MS>>Да я не то совсем хотел сказать !!! Наоборот У тебя выходит, что сервер это то, что выполняет какие-то запросы, а то, что уже само что-то делает, это уже не сервер.

AVK>То есть SQL-сервер сам ничего не делает? Ты не путай сервер приложений, и сервер в технологии клиент-сервер, это не одно и то же.

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

IT>Здравствуйте, MikaRSDN Soukhov, Вы писали:

IT>Другое дело, если бы я тебе по e-mail сообщение послал (MSMQ) приходи забирай, либо ты сам бы мне позвонил и забрал результат (только часто звонить тоже не надо).

Тоесть вместо эвентов клиент должен проверять почту от тебя? И ты говоришь что тут ты решил без эвентов?
Про MSMQ я понял твою идею Но опять же это всего лишь жалкая попятка эвентов

IT>Какая разница где он находиться, ивент он получает от локальной машины, а не от удалённой. А как удалённая машина сообщает об изменении локальной это совсем другое дело, дело тёмное и непонятное.

Вот как раз это то я и хотел узнать как бы ты решил такое

MS>>От эвентов я уже порядочно намучался Начиная еще с СОМ Но все равно считаю что без них нормальная система не может быть хорошо спроектирована

IT>Ты хотел сказать "с ними"

Это ты сказал

MS>>Да я не то совсем хотел сказать !!! Наоборот У тебя выходит, что сервер это то, что выполняет какие-то запросы, а то, что уже само что-то делает, это уже не сервер.

IT>Сервер, конечно, я обратного и не утверждал, даже пример тебе привёл, что у нас есть batch сервер, который по расписанию выполняет разнообразные задачи.

И кто у него клиенты? Локальные или нет?