Веб-сервисы исключительно как 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
