K>>Как ты организовываешь обмен данными между клиентом и сервером, каким способом (Web Service, Remoting or COM+) и в чем (Dataset, binary or XML)?

Веб-сервисы исключительно как presentation layer для не-.NET клиентов. Для .NET клиентов — Remoting. COM+ идёт лесом.
В чём — не вопрос, в чём удобнее. XML конечно никто специально не использует, только в особых случаях, например, взаимодействие с Sun'ом, и в веб-сервисах. Dataset'ы оспользуются в основном для передачи данных между бизнес и дата лэйерами на сервере, для передачи данных клиенту редко, хотя особых ограничений на это нет.

Так что получается, что в основном binary. Вообще-то, на самом деле всё проще Классы бизнес логики пишутся просто как классы унаследованные от наследника MarshalByRefObject. Для входных/выходных параметров используются структуры и массивы. Затем для них делается рапер в виде веб-сервиса и готово. Если кому-то нравятся датасеты, нет проблем... пока их нет, появяться будем с ними бороться

MS>А лучше расскажи как ты организовывал переход к .Net?

Давно это было... Решил я однажды организовать преход к .Net...

MS>если можно то по подробнее Сейчас передо мной стоит такая задача и хотелось бы услышать бывалого Какие есть подводные камни и еще еще?

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

Вот мой вариант. Исходная позиция:

1. Один основной клиент, написанный на MFC. Большая программа, включающая в себя столько функций, сколько можно в неё запихнуть.
2. Куча мелких программ, написанных на чём зря.
3. DCOM компоненты и COM+ приложения, которые интенсивно пишутся чуть больше года, но уже успели порядком всех задолбать по причине см. пп. 4-5.
4. Частые обновления софта, фикс глюков и постоянное добавление новых фич.
5. Порядка 600-800 клиентских машин, находящихся в нескольких центрах в разных штатах и странах, на которых нужно обновлять весь этот софт.

В общем полный бардак.

Главная проблема — деплоймент. Служба поддержки начала практически сразу пищать как только началось применение COM, а по истечении года они просто начали выть. В принципе, если релиз делаеться раз в пол года на 10 машинах, то в КОМе нет ничего страшного, но регистрировать всё это хозяйство каждую неделю-две на таком количестве клиентов — это можно застрелиться. Я понимю, что есть скрипты и всякие другие приближённые к человеческим способы регистрации объектов, но всё равно это всё должно делаться централизовано, что в наших условиях практически невозможно.

Вторая проблема — КОМ сам по себе. К сожалению (счастью), C++ + COM требует более высокой квалификации чем программирование на той же Джаве, поэтому, не смотря на все предосторожности от глюков избавиться практически невозмножно.

Эту проблему я пытался решить ещё на VS.NET beta 2 с помошью замены C++ на C#. Вывод такой — затраты на разработку компонент значительно сокращаются, но вот деплоймент становиться ещё хуже. И хотя в релизе студии кое-что подправили и почти через год на RSDN'е было найдено (Владом и AVK, если не ошибаюсь) решение, позволяющее обойтись без перерегистрации объекта после каждой сборки, но тем не менее поддержка COM в .NET, на мой взгляд, остаётся пока самым глючным местом. Поэтому, было принято командирское решение полностью отказаться от COM.

Далее всё пошло в соответствии с теми картинками, которые приводятся в MSDN при описании архитектуры .NET приложений. Middleware строится полностью на pure .NET, общение с .NET клиентами осуществляется через Remoting, а с другими инородными системами через веб-сервисы. Здесть важно понять одну вешь, что-бы там не говорили, но Win-приложения являются для .NET инородными и интероп не решает эту проблему полностью, а только пытается это делать, хотя иногда это у него получается более менее приемлемо.

Таким образом, пришлось смириться с мыслью, что наш самый толстый клиент, написанный на MFC — инородная вещь в новой архитектуре
После этого всё пошло значительно веселее. Общение через веб-сервисы полностью устранило проблему деплоймента, т.е. совсем. Ничего нигде не надо регистрировать, не надо писать скриптов, оставаться после работы и обзванивать тёток по телефону, что бы заставить их перегрузить комп.

.NET приложения общаются с сервером напрямую через Remoting, но у нас таких не очень много. Есть идея развалить нашего монстра на несколько частей, но и здесь видимо всё не пройдёт так гладко. Проблема в том, что на все машины нужно будет проинсталлировать framework, а это задача не простая, хотя уже запланированная. Пока же серьёзно рассматривается решение о применении веб-интерфейса для некоторых задач. То что будем его комбинировать с GUI — это уже точно, а дальше будем поглядеть.

ЗЫ: Для доступа к веб-сервисам из Win-клиентов можно использовать SOAP Toolkit, но это опять COM , поэтому я нацарапал вот такой тул, который строит по WSDL обычный C++ класс. Сам рапер (файл wsgen.h) поддерживает MFC либо классы #import, но его можно легко переделать на что угодно другое.

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

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

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

AVK>Да все вроде правильно, только аутентификация по английски Authentification

Authentication
3:1

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

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

Это к чему?

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

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

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

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

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

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

M>1) — в стиле Web-интерфейса.

Ну в вебе есть такие вещи как скрипты и програмы на Яве или .Нэт. Вот они могут являться презантационной логикой. Иначе это мертвый хтмл который и логикой то не обладает.

M>2) — Поведением всех визуальных компонентов управляет клиент. Который, в свою очередь, кроме
M> презентативной логики должен знать и о части бизнес-логики, от которой презентативная логика
M> полностью зависит.

Да знать он может все что угодно и зависить может от чего угодно. Презиетационная логика может быть даже иногда копией серверной. Главное чтобы от нее не зависил сервер.

M> Вот это уже более стандартизировано — например ADO.NET с их
M> "отсоединенными" датасетами.

Отсоединенный адасет — это не более чем массив данных. Только динамический и разными наворотим. Сервер отдает его клиенту, и тот должен отобразить данные пользователю (отформатировав их как ему нравится) и позволить пользователю изменить эти данные. Далее она должна взять дельту (изменения) и отослать на сервер. И тут уже начнется вторая часть бизнеслогики. Сервер долен сделать нужные проверки и записать изменения в БД. При этом сервер приложений может выпендриваться как хочешь. Да и клиент волен делать все что угодно. Например он может с дублировать вычисления производимые на сервере чтобы пользователь чувствовал интерактивность. И все это будет правильно и не будет нарушать "правильную" модель. Но вот если клиент начнет делать некую логику которую не в силах отследить сервер. И эта логика начнет влить на данные. Вот здесь то и могут появиться проблемы.

Вот живой (и довольно безобидный) пример с нашего сайта. На RSDN есть бизнеслогика которая говорит, что нельзя постить сообщения которые не имеют названия темы. Серверная логика реализована в некой хранимой процедуре (да не важно где). Но она не проверяет это правило. Зато проверкой занимается или скрипт на клиенте или ASP.NET страничка. Так вот появляется вторая точка в которой можно добавить сообщение (Хоум) в нем проверка не сделана и в базу попадают темы без названия. Это совсем безобидная ошибка. Но она хорошо показывает принцип разделения логики. Вся серьезная логика должна проверяться и отрабатываться на сервере. Так вот с кобэками зачастую бывает именно так что часть логики начинает выполняться на клиенте. Причем эта часть встроена между общей логикой сервера и сервер начинает очень сильно зависит от этого промежуточного звена.

M> И в частности, клиент должен уметь хранить массу справочной (т.е. редко меняющейся)
M> информации, дабы не обращаться постоянно к серверу.

Только в виде кэша. Информация должна быть первична на сервере. А клиент должен ее отображать. Он может кэшировать ее, но нужно подразумевать что кэш может измениться в любое время. Можно даже придумать систему автоматической перечитки. Но вот события здесь не лучший вариант. Дело в том что очень не просто создать систему событий которая будет "умно" уведомлять клиента. Обычно все скатывается на то что на каждый апдэйт данных рассылается уведомление каждому клиенту. Такой подход (даже если проблемы с надежностью решены) может привести к проблемам с производительностью. Ну и в любом случае нужно предусмотреть полную ручную перечитку данных, так как уведомление может попросту потеряться.

M> А вот тут и возникает вопрос о неких
M> "событиях" об изменениях, получаемых с сервера. И вопрос, соответственно, именно о том, как
M> реализовать поставку этих "событий" с сервера на клиента. Просто периодический опрос сервера
M> насчет изменений:
M> во-первых, создает лишнюю нагрузку на сеть/сервер,

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

M> во-вторых принципиально не отличается от простого "перечитывания" информации с сервера
M> ну и во-третьих, выглядит как-то неэлегантно

Возможно и не элегантно, но зато:
1. Это работает.
2. Легко реализуемо.

В общем если говорить об уведомлениях, то здесь нужно понимать две вещи:
1. События нужно делать так чтобы от них ничего не зависело, т.е. чтобы если произойдет ошибка, то не должны пострадать данные, и нужно иметь возможность легко устранить рассинхронизацию.
2. Нужно очень серьезно продумать тактику уведомлений чтобы минимизировать количество клиентов которых нужно уведомлять. Например если изменился заказ, нужно точно знать какой клиент имеет его открытым и уведомлять только его. Поверь, это очень непростая задача.
3. Уведомления нужно делать на МОМ. Чтобы избежать реализации МОМ своими силами.

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

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

_>Еще ButtonBase и наследники

Во-во.

Как ты организовываешь обмен данными между клиентом и сервером, каким способом (Web Service, Remoting or COM+) и в чем (Dataset, binary or XML)?

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

K>Как ты организовываешь обмен данными между клиентом и сервером, каким способом (Web Service, Remoting or COM+) и в чем (Dataset, binary or XML)?

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

Заранее благодарю

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

А что делает твой монстр ну и остальная сотяра?

PS

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

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

VD>А что делает твой монстр ну и остальная сотяра?

Я же говорю — всё! Начиная от customer representative, заканчивая администрированием системы. Кто это только придумал?... Ну, вообще-то, я знаю кто, и он уже покаялся во всех грехах много раз, но теперь вот стоит задача развалить всё это хозяйство на части.

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

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

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

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

IT>Веб-сервисы исключительно как presentation layer для не-.NET клиентов.
IT>Для .NET клиентов — Remoting. COM+ идёт лесом.

не-ДотНет нет, поэтому мне на веб сервисы даже не смотреть?

IT>В чём — не вопрос, в чём удобнее. XML конечно никто специально не использует, только в особых случаях, например, взаимодействие с Sun'ом, и в веб-сервисах.

Закладывая потенциал выхода в инет, задался вопросом, можно ли Remoting прикрутить к HTTP протоколу и сериализить бинари форматтером.

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

IT>Так что получается, что в основном binary. Вообще-то, на самом деле всё проще Классы бизнес логики пишутся просто как классы унаследованные от наследника MarshalByRefObject. Для входных/выходных параметров используются структуры и массивы. Затем для них делается рапер в виде веб-сервиса и готово. Если кому-то нравятся датасеты, нет проблем... пока их нет, появяться будем с ними бороться

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

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

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

IT>.NET приложения общаются с сервером напрямую через Remoting, но у нас таких не очень много. Есть идея развалить нашего монстра на несколько частей, но и здесь видимо всё не пройдёт так гладко. Проблема в том, что на все машины нужно будет проинсталлировать framework, а это задача не простая, хотя уже запланированная. Пока же серьёзно рассматривается решение о применении веб-интерфейса для некоторых задач. То что будем его комбинировать с GUI — это уже точно, а дальше будем поглядеть.

А то, что 2 клиентов надо будет поддерживать, это не пугает?

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

IT>>Веб-сервисы исключительно как presentation layer для не-.NET клиентов.
IT>>Для .NET клиентов — Remoting. COM+ идёт лесом.

K>не-ДотНет нет, поэтому мне на веб сервисы даже не смотреть?

А что в них такого хорошего?

K>Закладывая потенциал выхода в инет, задался вопросом, можно ли Remoting прикрутить к HTTP протоколу и сериализить бинари форматтером.

Можно.

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

IT>>>Веб-сервисы исключительно как presentation layer для не-.NET клиентов.
IT>>>Для .NET клиентов — Remoting. COM+ идёт лесом.

K>>не-ДотНет нет, поэтому мне на веб сервисы даже не смотреть?

AVK>А что в них такого хорошего?

Я понимаю, что веб сервисы нужны для интернета, и если речь идет об интранет приложении, то, на самом деле, я не вижу ни одного серьезного довода.
Меня интересует: может ли веб сервис вернуть MarshalByRefObject, т.е. можно ли их использовать как аутентификаторы.

K>>Закладывая потенциал выхода в инет, задался вопросом, можно ли Remoting прикрутить к HTTP протоколу и сериализить бинари форматтером.

AVK>Можно.

Ограничения? Или их нет?

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

K>Я понимаю, что веб сервисы нужны для интернета, и если речь идет об интранет приложении, то, на самом деле, я не вижу ни одного серьезного довода.
K>Меня интересует: может ли веб сервис вернуть MarshalByRefObject, т.е. можно ли их использовать как аутентификаторы.

Так можно и ремоутинг-сервис пустить под IIS с его контролем доступа.

K>>>Закладывая потенциал выхода в инет, задался вопросом, можно ли Remoting прикрутить к HTTP протоколу и сериализить бинари форматтером.

AVK>>Можно.

K>Ограничения? Или их нет?

Такие же как у сервисов.

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

AVK>Так можно и ремоутинг-сервис пустить под IIS с его контролем доступа.

Где бы почитать?

А если без IIS и COM+, то самому реально реализовать аутентификатор ввиде ремоутинг-сервиса? Который возвращал бы другие сервисы, но чтобы их в обход аутентификатора невозможно было бы получить.

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

AVK>>Так можно и ремоутинг-сервис пустить под IIS с его контролем доступа.

K>Где бы почитать?

Я читал в MSDN. Здесь есть по ремоутингу небольшая статья.

K>А если без IIS и COM+, то самому реально реализовать аутентификатор ввиде ремоутинг-сервиса? Который возвращал бы другие сервисы, но чтобы их в обход аутентификатора невозможно было бы получить.

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

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

IT>Далее всё пошло в соответствии с теми картинками, которые приводятся в MSDN при описании архитектуры .NET приложений. Middleware строится полностью на pure .NET, общение с .NET клиентами осуществляется через Remoting, а с другими инородными системами через веб-сервисы. Здесть важно понять одну вешь, что-бы там не говорили, но Win-приложения являются для .NET инородными и интероп не решает эту проблему полностью, а только пытается это делать, хотя иногда это у него получается более менее приемлемо.

Что то я не понял каким образом общаются Win-клиенты с .Net. Ты говоришь что центр + C# клиенты у тебя общаются по ремотингу. У нас так же. Но в ремотинге есть такое понятие как event-ы, чего нет в Web Service-ах (нормальным путем не добится).
Если ты отделил Win32 клиентов от Remoting с помощью Web Service то как ты решил эту проблему? Или же у тебя как то по другому?

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

K>>А если без IIS и COM+, то самому реально реализовать аутентификатор ввиде ремоутинг-сервиса? Который возвращал бы другие сервисы, но чтобы их в обход аутентификатора невозможно было бы получить.

AVK>Реально. В ремоутинге, в отличие от сервисов, можно поменять почти все, архитектура намного более открытая и гибкая (ну и как следствие более сложная конечно).

В принципе и менять то не надо. Я сделал так:
Сначала интерфейсы:

// Аутентификатор
    public interface IAutentService
    {
        void Test();
        MarshalByRefObject GetService();
    }

// Простой сервис
    public interface ISimpleService
    {
        void Test();
    }

Их имплементация:

    public class AutentService: MarshalByRefObject, IAutentService
    {
        public AutentService(){}

        public void Test()
        {
            Console.WriteLine("AutentService.Test()");
        }
        public MarshalByRefObject GetService()
        {
            return new SimpleService();
        }
    }

    public class SimpleService: MarshalByRefObject, ISimpleService
    {
        public SimpleService(){}

        public void Test()
        {
            Console.WriteLine("SimpleService.Test");
        }
    }

Запускаю сервисы так:

            ChannelServices.RegisterChannel(new TcpChannel(666));
            RemotingConfiguration.ApplicationName = "TestApp";
            RemotingConfiguration.RegisterWellKnownServiceType(typeof(AutentService), "AutentServiceUri", WellKnownObjectMode.Singleton);
            Console.ReadLine();

Проверяю на клиенте:

            IAutentService aServ = (IAutentService)Activator.GetObject(typeof(IAutentService), "tcp://localhost:666/TestApp/AutentServiceUri");
            aServ.Test();
            ISimpleService sServ = (ISimpleService)aServ.GetService();
            sServ.Test();

Отлично, работает, только может быть я чего недопонял.

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

K>Отлично, работает, только может быть я чего недопонял.

Да все вроде правильно, только аутентификация по английски Authentification

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

MS>Что то я не понял каким образом общаются Win-клиенты с .Net. Ты говоришь что центр + C# клиенты у тебя общаются по ремотингу. У нас так же. Но в ремотинге есть такое понятие как event-ы, чего нет в Web Service-ах (нормальным путем не добится).

Ненормальным тоже. Вывод — если хочешь и веб-сервисы и ремоутинг — эвенты не используешь. Без них тоже можно нормально жить.

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

MS>>Что то я не понял каким образом общаются Win-клиенты с .Net. Ты говоришь что центр + C# клиенты у тебя общаются по ремотингу. У нас так же. Но в ремотинге есть такое понятие как event-ы, чего нет в Web Service-ах (нормальным путем не добится).

AVK>Ненормальным тоже. Вывод — если хочешь и веб-сервисы и ремоутинг — эвенты не используешь. Без них тоже можно нормально жить.

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

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

K>не-ДотНет нет, поэтому мне на веб сервисы даже не смотреть?

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

K>Закладывая потенциал выхода в инет, задался вопросом, можно ли Remoting прикрутить к HTTP протоколу и сериализить бинари форматтером.

Можно, но AVK как-то приводил убедительнае аргументы против, один из них — файерволы не пропускают двоичную информацию.

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

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

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

Смотри статью в 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 раз. Делай выводы.

IT>>.NET приложения общаются с сервером напрямую через Remoting, но у нас таких не очень много. Есть идея развалить нашего монстра на несколько частей, но и здесь видимо всё не пройдёт так гладко. Проблема в том, что на все машины нужно будет проинсталлировать framework, а это задача не простая, хотя уже запланированная. Пока же серьёзно рассматривается решение о применении веб-интерфейса для некоторых задач. То что будем его комбинировать с GUI — это уже точно, а дальше будем поглядеть.

K>А то, что 2 клиентов надо будет поддерживать, это не пугает?

Если я перевожу какую-нибудь форму или отчёт на веб интерфейс, то это автоматически означает, что она же заменяется и в GUI вместо стандартных окон, благо дело MFC поддерживает CHtmlView.

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

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

MS>>>Что то я не понял каким образом общаются Win-клиенты с .Net. Ты говоришь что центр + C# клиенты у тебя общаются по ремотингу. У нас так же. Но в ремотинге есть такое понятие как event-ы, чего нет в Web Service-ах (нормальным путем не добится).

AVK>>Ненормальным тоже. Вывод — если хочешь и веб-сервисы и ремоутинг — эвенты не используешь. Без них тоже можно нормально жить.

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

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

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

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

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

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

Здравствуйте, 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 сервер, который по расписанию выполняет разнообразные задачи.

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

Здравствуйте, 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 серверах? И ничего, работают.

Здравствуйте, 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>Скожу тебе по сикрету... в МС++ интеропа нет. Там просто есть код на смиле использующий напрямую все что захочет. Но думаю ты это и сам знаешь.

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

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

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

Я очень ленивый человек. Если было бы проще, написал бы на Шарпе. Первая попытка была именно на нем. Но писать все с абсолютного нуля — это слишком, а писать а WinAPI-шного нуля на Шарпе дико не удобно. Ошибок в разы больше чем на плюсах, да еще каждую функцию и константу нужно вручную описывать... В общем по сравнению с проблемами вызываемыми Шарпом пробшемы МС++ в данном случае просто смехотворны. К тому же я давно автоматизировал копирование, а замена версии на статически заданную решила проблемы несовместимости.

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

VD>Я очень ленивый человек. Если было бы проще, написал бы на Шарпе.

Не понял, ты чё гридов никогда не писал? Зачем тебе апишные функции? Всё что тебе надо — кисточка и карандаш

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

VD>>Я очень ленивый человек. Если было бы проще, написал бы на Шарпе.

IT>Не понял, ты чё гридов никогда не писал? Зачем тебе апишные функции? Всё что тебе надо — кисточка и карандаш

Вот потому что писал (см. ascDB), потому так и не делаю. Это трах на пол кода с отрывом от производства. Хотя может и стоило бы. А то грид из .нэт тормозной и кривой.

Кстати, в МС тоже много линивых. Их только на кривенький гид хватило. Все остальное обертки над апи, только хреновые и на Шарппе.

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


MS>Но в ремотинге есть такое понятие как event-ы, чего нет в Web Service-ах (нормальным путем не добится).
MS>Если ты отделил Win32 клиентов от Remoting с помощью Web Service то как ты решил эту проблему? Или же у тебя как то по другому?

И слава бугу что нет! Ты еще мало носом тыкался в нешениях основанных на колбэках. В сети (особенно в Интернет) — это самое худшее решение. Ты сразу снижаешь надежность всей системы до надежности самой ненадежной части сети. Стоит одному клиенту подвеснуть или выдернуть шнур из компьютера и ты приплыл.

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

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

Они еще надежность снижают. И нехило.

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

MS>Всю логику в сервер...


Держите меня семеро. 30 лет люди борются чтобы всю логику на сервере, а емеу

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

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

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

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

Ты не прав. У вас просто пока маленькие объемы колбэков и давольно надежная сеть. Если эти услвия изменятся, ты поймешь почему ты не прав.

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

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

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

А ты вот к примеру на Хоум глять. Там как раз изменения отслеживаются и без единого колбэка.

IT>>Периодический опрос сервера клиентом
MS>Докажешь что лучше, сделаем так.

Сам когда нибудь поймешь почему.

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

Может, но с клиентами по своему усмотрению общаться не имеет права. Только с серверами связанными надежными каналами. В общем единственным разумным выходом в твоей ситуации является использование МОМ. А их можно и на веб сервисах писать.

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

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

Более того MSMQ позволяет легко организовать асинхронную доставку сообщений.


S>Вообще архитектура, существенно использующая колбэки как часть логики, обречена. Почему? А потому, что у тебя получается двусторонняя зависимость между сервером и клиентом. Т.е. tight coupling, единогласно проклинаемый всеми гуру от архитектуры. Надежность системы начинает резко зависеть от надежности связи между клиентом и сервером.

И от самого клиента! Т.е. клиентом (причем каждый) становится частью сервера.

В общем я бы сформулировал так. События допустимы в надежных клиент-срверных системах только при соблюдениях следующих правил:

1. Сервер не имеет зависимости от клиента (ни временной ни локической)
2. Клиент умеет объходиться без данных передаваемых через события.

Качественно такие условия можно выполнить только используя MOM типа того же MSMQ.

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

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

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

ms-help://MS.VSCC/MS.MSDNVS/dnmqqc/html/msdn_msmqoverview.htm

и вообще все ветки за ms-help://MS.VSCC/MS.MSDNVS/dnmqqc/html/bldappmq.htm

Ну из нашего: Система поддержки событий COM+

Автор(ы): А. Новик

, Queued-компоненты Windows 2000

Автор(ы): А. Новик

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

MS>Тогда следует такой вопрос а в Web Service можно использовать MSMQ

Нет конечно. MSMQ — это почти протокол. Работает поверх TCP так что в Интернете его приенять можно, но по HTTP он не работает.

MS>Если нет то COM+ лучше в этом случае

В COM+ есть кьюед-компоненты. Они реализованы на MSMQ. Причем они значительно медленнее чем прямая работа с MSMQ. Да и работать с ними не проще. COM+ же без кьюед-компонентов используемый для колбэков — это неверное решение. Почему? Да тебе сдесь уде многи об этом рассказывали.

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

AVK>Серверные эвенты это вобще относительно новое веяние.

Ошибаешся. Просто на обычном RPC они не надежны быи, и потому не прижились. За то есть MOM. Там все на эвентах. Там даже вызов сервера (прямой) — это в чистом виде эвент.

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

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

В классическом клиент-сервере еслть понятие логики данных, прикладной логики и презентационной логики. Призентационная — это и есть клиентская. Но в отличии от твоего представления — не логика приложения. Это всголишь код занимающийся локальной обработкой информации для идинственного клиента. Локальной — значит, что эта логика никак не влияет на сервер. Если приложение влияет на сервер, оно само становится сервером и о клиент-серевер речь еже не идет. В этом случае у тебя получается большое распределенное приложение. И сделать надежным такое приложение очень и очень сложно. Решения есть только два (ну можне быть пока ):

1. Использование для связи МОМ и виделение главных серверо. При этом второстепенные серверы используют обратную связь только в асинхронном режиме. Надежность передачи обеспечивается МОМ-ом.

2. Помещение приложения в кластре. Для клиентов неприемлемо.

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

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

Когда МОМ заточат под вэб. Возможно уже ходят.

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

Так не обязательно до отупения. Мделай кнопку рефешь. Ну или используй для событий МОМ.

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

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

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

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

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

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

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

Я согласен. Вот только смущают такие моменты.
Презентативная логика. Здесь возможны 2 варианта:
1) — в стиле Web-интерфейса. Поведением всех визуальных компонентов управляет сервер.
На который при этом явно ложится лишняя нагрузка. И, главное, в отличие от Web-интерфейса
не стандартизированы визуальные компоненты — т.е. каждый разработчик сам
конструирует передачу событий от кнопок etc. на сервер, прием и отображение свойст визуальных
компонентов.

2) — Поведением всех визуальных компонентов управляет клиент. Который, в свою очередь, кроме
презентативной логики должен знать и о части бизнес-логики, от которой презентативная логика
полностью зависит. Вот это уже более стандартизировано — например ADO.NET с их
"отсоединенными" датасетами.
И в частности, клиент должен уметь хранить массу справочной (т.е. редко меняющейся)
информации, дабы не обращаться постоянно к серверу. А вот тут и возникает вопрос о неких
"событиях" об изменениях, получаемых с сервера. И вопрос, соответственно, именно о том, как
реализовать поставку этих "событий" с сервера на клиента. Просто периодический опрос сервера
насчет изменений:
во-первых, создает лишнюю нагрузку на сеть/сервер,
во-вторых принципиально не отличается от простого "перечитывания" информации с сервера
ну и во-третьих, выглядит как-то неэлегантно

Евгений.

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

VD>Вот живой (и довольно безобидный) пример с нашего сайта.

RSDN внутри никогда не делался как клиент-серверное приложение (не путать с веб-сервером). Слишком дорого.

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

IT>RSDN внутри никогда не делался как клиент-серверное приложение (не путать с веб-сервером). Слишком дорого.

Ничего там другого нет. Чистый к-с.

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

IT>>RSDN внутри никогда не делался как клиент-серверное приложение (не путать с веб-сервером). Слишком дорого.

VD>Ничего там другого нет. Чистый к-с.

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

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

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

Блин, да любой сервер внутри обычное...

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

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

VD>Блин, да любой сервер внутри обычное...

Влад, не чуди. Ты же сам только что Мике всё правильно рассказывал и примеры приводил.

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

IT>Влад, не чуди. Ты же сам только что Мике всё правильно рассказывал и примеры приводил.

А я и не чудю. Веб это чистый клиент-сервер. Дву с половиной уровневый.

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

IT>>Влад, не чуди. Ты же сам только что Мике всё правильно рассказывал и примеры приводил.

VD>А я и не чудю. Веб это чистый клиент-сервер. Дву с половиной уровневый.

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

Здравствуйте, IT:
Не могли бы вы дать ссылки на статьи, в которых описываются методы создания клиент-серверного ПО — "методы" создания "правильного" клиент-серверного ПО.

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

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

Я вообще-то говорил об ошибке дизайна. Когда у тебя серверная логика не проверяла бизнес-правил. Тут уже не важно даже как построено приложение. Это правило дизайна к-с систем. Оно полезно даже при разработке одноуровневого приложения.

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

VD>Я вообще-то говорил об ошибке дизайна. Когда у тебя серверная логика не проверяла бизнес-правил. Тут уже не важно даже как построено приложение. Это правило дизайна к-с систем. Оно полезно даже при разработке одноуровневого приложения.

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

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

VD>>Я вообще-то говорил об ошибке дизайна. Когда у тебя серверная логика не проверяла бизнес-правил. Тут уже не важно даже как построено приложение. Это правило дизайна к-с систем. Оно полезно даже при разработке одноуровневого приложения.

IT>Да нет там никакой серверной бизнес логики, точнее вся она перемешана с обработкой кнопок, как в обычном двух-уровневом десктоп приложении. Разница только в том, что результат есть html код, а не отрисовка на экране.

Значит пора рефакторить

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

S>Не могли бы вы дать ссылки на статьи, в которых описываются методы создания клиент-серверного ПО — "методы" создания "правильного" клиент-серверного ПО.

Поиск типа "client near server near application near architecture" в MSDN выдаст кучу ссылок на статьи и все они будут правильные, каждая для своей задачи.

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

Я знаю только одно 100% правильное правило при проектировании любого ПО: чем меньше связей между отдельными модулями и подсистемами, тем правильнее ПО, если оно конечно делает то, что от него требуется Многие методы создания ПО как раз и предназначены для поиска и устранения ненужных, вредных и порочных связей.

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

IT>>Да нет там никакой серверной бизнес логики, точнее вся она перемешана с обработкой кнопок, как в обычном двух-уровневом десктоп приложении. Разница только в том, что результат есть html код, а не отрисовка на экране.

AVK>Значит пора рефакторить

Точно

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

S>Не могли бы вы дать ссылки на статьи, в которых описываются методы создания клиент-серверного ПО — "методы" создания "правильного" клиент-серверного ПО.

Вот, кстати, интересная статейка Application Architecture for .NET: Designing Applications and Services. Сам ещё не читал, но собираюсь, уже даже распечатал

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

IT>Вот, кстати, интересная статейка Application Architecture for .NET: Designing Applications and Services. Сам ещё не читал, но собираюсь, уже даже распечатал

Спасибо большое за ссылку.

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

VD>Кстати, в МС тоже много линивых. Их только на кривенький гид хватило. Все остальное обертки над апи, только хреновые и на Шарппе.

Еще ButtonBase и наследники

IT>ЗЫ: Для доступа к веб-сервисам из Win-клиентов можно использовать SOAP Toolkit, но это опять COM , поэтому я нацарапал вот такой тул, который строит по WSDL обычный C++ класс. Сам рапер (файл wsgen.h) поддерживает MFC либо классы #import, но его можно легко переделать на что угодно другое.

IT>http://rsdn.ru/team/it/src/wsgen.zip
К сожалению, счас эта ссылка не работает.
Можно где-нибудь получить эту утиль?
Спасибо.

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

IT>>http://rsdn.ru/team/it/src/wsgen.zip
LD>К сожалению, счас эта ссылка не работает.
LD>Можно где-нибудь получить эту утиль?

http://files.rsdn.ru/1/wsgen.zip

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

LD>Можно где-нибудь получить эту утиль?

http://files.rsdn.ru/1/wsgen.zip