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

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

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

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

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

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

Здравствуйте, 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 сделать не проблема, соответственно события в твоём распоряжении.

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

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

Authentication
3:1

Здравствуйте, 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 (они то вообще существуют для простых запросов и никак не катят на центальное звено)

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

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