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

MS>Не согласен Пойдем по твоему пути У тебя получается что администратор знает и всю систему в целом и что такое расквазитронивание.

Это к чему?

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

Ничего не понял. Из чего ты такие выводы сделал?

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

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

Относительно цикла жизни технологий в корпоративном софте.

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

AVK>Это к чему?
AVK>Ничего не понял. Из чего ты такие выводы сделал?

Ты же хочешь чтобы вся логика хранилась на серваке ну и как с хранимыми процедурами А вот если есть такой человек который захочет что то изменить в процедуре ентой Он изменяет на сервера Так? А что если он хочет изменить локигу не серверную а клиентскую Опять на сервер? А кто ему доступ даст? Ведь сервер-админ >>> клиент-админ

Вот что я хотел сказать

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

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

AVK>Относительно цикла жизни технологий в корпоративном софте.

Круто сказал

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

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

Не хранилась, а выполнялась. Это немножко разные вещи.

MS>А вот если есть такой человек который захочет что то изменить в процедуре ентой Он изменяет на сервера Так?

Нет конечно. Ты хранимые процедуры и SQL-запросы на сервере меняешь?

MS>А что если он хочет изменить локигу не серверную а клиентскую

Опять 25. Не должно быть на клиенте никакой логики. Только тупой прием, передача и вывод данных.

MS>Опять на сервер? А кто ему доступ даст? Ведь сервер-админ >>> клиент-админ

Не понял. Если меняем логику, то меняет ее программер. А у него доступ к серверу есть.

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

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

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

AVK>Не хранилась, а выполнялась. Это немножко разные вещи.

Ессесно выполнялись Зачем же их тогда хранить !?

MS>>А вот если есть такой человек который захочет что то изменить в процедуре ентой Он изменяет на сервера Так?

MS>>А что если он хочет изменить локигу не серверную а клиентскую

AVK>Опять 25. Не должно быть на клиенте никакой логики. Только тупой прием, передача и вывод данных.

AVK>Не понял. Если меняем логику, то меняет ее программер. А у него доступ к серверу есть.

Вот у нас есть сервак У него своя логика А есть клиентская программа логику которой захотел поменять сам клиент (ну знает он скрипты и что тут поделаешь Захотел он Клиент ведь всегда прав ) Меняет он не много но МЕНЯЕТ И что же? Мы должны дать ему доступ на сервер? Конечно это все его (он же заплатил ) но чтобы это чудо что нить там на портило? И я говорю не правы доступы на все тачке (аккаунты) Машина то с сервером это целая платформа на которой может спокойно ходить только хороший девелопер

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

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

AVK>>Не хранилась, а выполнялась. Это немножко разные вещи.

MS>Ессесно выполнялись Зачем же их тогда хранить !?

Мало ли . Это я к тому что хранится логика может и не на сервере.

AVK>>Не понял. Если меняем логику, то меняет ее программер. А у него доступ к серверу есть.

MS>Вот у нас есть сервак У него своя логика А есть клиентская программа логику которой захотел поменять сам клиент (ну знает он скрипты и что тут поделаешь Захотел он Клиент ведь всегда прав )

Значит надо обрубить ему такую возможность.

MS> Меняет он не много но МЕНЯЕТ И что же? Мы должны дать ему доступ на сервер?

Ну если очень хочется, то в ограниченных количествах да.

MS>Конечно это все его (он же заплатил ) но чтобы это чудо что нить там на портило?

Про sandbox ака песочница слыхал? Обрубаешь ему лишние пермишенсы и все.

MS>И я говорю не правы доступы на все тачке (аккаунты) Машина то с сервером это целая платформа на которой может спокойно ходить только хороший девелопер

Слыхал про хостинг на ASP.NET серверах? И ничего, работают.

Здравствуйте, MikaRSDN Soukhov, Вы писали:
MS>Тоесть вместо эвентов клиент должен проверять почту от тебя? И ты говоришь что тут ты решил без эвентов?
MS>Про MSMQ я понял твою идею Но опять же это всего лишь жалкая попятка эвентов
Нет. В отличие от евентов, MSMQ гарантирует доставку. IT прав.
Вообще архитектура, существенно использующая колбэки как часть логики, обречена. Почему? А потому, что у тебя получается двусторонняя зависимость между сервером и клиентом. Т.е. tight coupling, единогласно проклинаемый всеми гуру от архитектуры. Надежность системы начинает резко зависеть от надежности связи между клиентом и сервером.
Успех клиент-серверной архитектуры связан с тем, что вся логика крутится на сервере, и, таким образом, является "защищенной" от помех в канале. В случае обрыва связи сервер остается в детерминированном состоянии. Состояние клиента роли не играет — он всего лишь отражает состояние сервера. При обрыве соединения клиент можно тупо перестартовать без потери целостности приложения.
Евенты можно применять в двух случаях:
1. "Сервер-серверная" архитектура, или распределенный сервер с сильно связанными компонентами. В таком кластере надежность связи обеспечивается прямым контролем всех соединений, и, тем не менее, требуются специальные усилия по обеспечению целостности в случае потери связи (типа двухфазного коммита)
2. Несущественная зависимость. Клиент остается клиентом, и использует евенты исключительно для косметических эффектов. Пример — нотификации файловой системы. Фар корректно отлавливает изменения содержимого фолдера в файловых системах, которые его поддерживают. Но! Логика файлового сервера не зависит от получения фаром этих нотификаций. Кроме того, сам фар использует евенты всего лишь как альтернативу обязательно поддерживаемому Ctrl-R — который гарантированно запрашивает состояние с сервера.

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

AVK>Это я к тому что хранится логика может и не на сервере.

Дык я тебе тоже самое и говорю уже 3 поста если не больше

[skipped]

AVK>Слыхал про хостинг на ASP.NET серверах? И ничего, работают.

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

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

AVK>>Это я к тому что хранится логика может и не на сервере.

MS>Дык я тебе тоже самое и говорю уже 3 поста если не больше

Опять повторюсь — хранится это совсем не значит что выполняется.

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

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

MS>>Про MSMQ я понял твою идею Но опять же это всего лишь жалкая попятка эвентов

S>Нет. В отличие от евентов, MSMQ гарантирует доставку. IT прав.

Точно так же как сохранять эти эвенты Только MSMQ это что-то стандартное а логировангие это выдумывание своего (+ технология самодоставки клиенту)
На счет MSMQ я соглашусь Да конечно это лучше че писать что-то новое
Тогда следует такой вопрос а в Web Service можно использовать MSMQ Если нет то COM+ лучше в этом случае

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

AVK>Опять повторюсь — хранится это совсем не значит что выполняется.

Тогда получится что сервер это что-то монолитное и не поворотное

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

AVK>>Опять повторюсь — хранится это совсем не значит что выполняется.

MS>Тогда получится что сервер это что-то монолитное и не поворотное

С чего бы это?

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

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

AVK>>>Опять повторюсь — хранится это совсем не значит что выполняется.

MS>>Тогда получится что сервер это что-то монолитное и не поворотное

AVK>С чего бы это?

Нет уж Я тут уже устал писать Давай лучше ты расскажи, почему именно гибко получается
У тебя сервер закачивает "код" с клиента, который правит каждый программист свой и далее выполнение все происходит на сервере. Тогда чисто с программной точки зрения тут я вижу плохо только то, что если где нить пошло на перекосяк (косяк c перекосом ) тогда у тебя и все упадет (или придется писать лишний код об отказе устойчивости и возможности горячей замены частей)
А так можно отключить клиента, переделать его и снова в бой. Представляешь, что если бы система жизниобеспечения была бы на космодроме, а не в самом шатле. Малейшая ошибка и все, гробы.

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

MS> У тебя сервер закачивает "код" с клиента,

У меня? Нет, не закачивает. У меня нет необходимости выполнять чужой код.

MS> который правит каждый программист свой и далее выполнение все происходит на сервере. Тогда чисто с программной точки зрения тут я вижу плохо только то, что если где нить пошло на перекосяк (косяк c перекосом ) тогда у тебя и все упадет

Вот тут то и проявляется весь кайф джавы и дотнета — ничего не произойдет. При грамотно написанном сервере скорее всего не будет работать только кривой кусок. В крайнем случае можно просто убить домен с этим куском. А сервер при этом по прежнему будет работать и обслуживать запросы. А вот в том что ты предлагаешь косяки на клиентах и проблемы со связью однозначно залочат всю систему. О чем тебе уже трое и пытаются рассказать.

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

AVK>Вот тут то и проявляется весь кайф джавы и дотнета — ничего не произойдет. При грамотно написанном сервере скорее всего не будет работать только кривой кусок. В крайнем случае можно просто убить домен с этим куском. А сервер при этом по прежнему будет работать и обслуживать запросы. А вот в том что ты предлагаешь косяки на клиентах и проблемы со связью однозначно залочат всю систему. О чем тебе уже трое и пытаются рассказать.

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

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

Можешь рассказать чем хорош MSMQ (можно и линки на статьи)
А пока один конкретный вопрос. Мы располагаем очереди сообщений на клиентской части или серверной (если на последней то как тогда получить эвент о том что пришло сообщение от сервера)?

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

IT>http://rsdn.ru/team/it/src/wsgen.zip

Попробовал сделать прокси. В сгенеренном коде появился ws_base64Binary — такого типа нет в wsgen.h? Или это мои глюки?

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

N>Попробовал сделать прокси. В сгенеренном коде появился ws_base64Binary — такого типа нет в wsgen.h? Или это мои глюки?

Этот тип пока не поддерживается, но его легко добавить в wsgen.h. Если получится, поделись ;)

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

IT>В принципе, да. Колбэки я не долюбливаю так же как и интероп, по причине всяких возможных неохиданностей К тому же основные задачи этого и не требуют, всё на самом деле очень стэйтлес. Есть специфические задачи, которые требуют синхронизации работы пользователей, но они нужны не для сотен клиентов, а для небольшой группы, максимум 10 рабочих станций. В этом случае клиент на .NET сделать не проблема, соответственно события в твоём распоряжении.

Недавно появилось решение http://www.msgconnect.com/
Оно существует под лицензией Open Source и под коммерческой.
Некий общий мессаговый базис для .NET, Native Win32, Java...

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

IT>"Остальная софтяра" тоже делом занимается. Или тебе интересно что вообще делается в конторе?

Ну хотя бы общие задачи софтяры.

VD>>Про глючность интеропа ты гонишь. Но про сложности с регистрацией согласен.

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

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

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

IT>>"Остальная софтяра" тоже делом занимается. Или тебе интересно что вообще делается в конторе?

VD>Ну хотя бы общие задачи софтяры.

Задачи любой софтяры — обеспечить работу конторы, задача любой конторы — окучить побольше кастомеров и стрясти с них побольше бабулек.

Способ, который используется в моей конторе — предоставление телекоммуникационных услуг. До 1996 года в штатах была одна телефонная компания — AT&T. Правительству надоел этот антимонопольный беспредел и её разделили на штук десять-двадцать паблик-контор поменьше. К тому же обязали этих поменьше предоставлять по первому требованию аренду каналов любому желающему, кто хочет быть реселлером, тарифы тоже узаконили. Моя контора как раз один из таких реселлеров, крупнейший во Флориде, а может и в штатах (никто не знает).

Соответственно задачи:

1. Customer care. В штатах народ простой, чуть что сразу за телефон и complain, все вопросы решаются только по телефону (сейчас ешё и по интернету). Любая контора, имеющая больше 2-х кастомеров имеет соответсвующее подразделение, обычно оно самое многочисленное. Всё производство из страны уже давно вывезено в Китай и прочие, теперь начали вывозить и call-центры, в частности у нас один в Коста-Рике, будет в Сан-Даминго, собираются также открывать один в Африке и закрывать два внутри страны.
   
2. Billing. Нужно посчитать сколько нам должны, напечатать билы и разослать по почте. А это 300000 конвертиков в месяц.
   
3. Payment. В штатах никто в сберкассу не ходит. Из полученного конверта с билом извлекается счёт, выписывается чек, всё это вкладывается в конверт, который тоже присылается, наклеивается марка и отсылается обратно. Далее в конторе сидят тётки, которые всё это распаковывают и вводят оплату в базу данных (сканеры и прочая дребедень). В день вводиться порядка 10000 чеков.
   
4. Accounting. Тут куча всяких мелких и крупных задач. Налоги, отслеживание неплательщиков и прочее.
   
5. Маркетинг. Начальство желает видеть всё в разных разрезах, чтобы принимать праильные решения.
   
6. Веб-сайт. Чем больше народу будет пользоваться сайтом, тем лучше. Меньше слать конвертов и вводить чеков.
   
7. Данные от провайдеров. Мы регулярно получаем гигабайтные файлы от наших провайдеров с call details, bills и пр. Всё это надо распарсить, обработать и положить в базу.
   
8. Мы начинаем ставить своё собственное оборудование, соответственно к нему тоже надо писать софт и стыковать с системой.

Это крупные задачи. Мелочи ещё наберётся примерно на половину от всего этого. Кроме того всё очень запущено, начиналось делаться какими-то консультантами, которых заботило только одно — побыстрее сделать и побольше срубить. Вот теперь приходится всё выправлять по живому.

Короче без .NET никак

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

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

А причём тут интероп, я говорю что наверняка было бы легче всё написать на чистом нете с нуля.