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

Конкретная задача тривиальна : создание единого сервера в сети для обслуживания нескольких клиентов выполняющих одни и те же операции.

Буду благодарен за любые ссылки или примеры.

Откликнесь кто работал с этим, плиз.

Magnus

Спасибо за ответы.
Дело в следующем: начальник сказал Enterprise Services, аргументируя это тем что, судя по заявлениям команды разработчиков Longhorn "Remoting уйдет в страну вечной охоты а его место займут Web Services и Enterprise Services".

А так как система должна быть установлена у ОЧЕНЬ большого клиента и предположительно будет находится в эксплуатации как минимум следующие лет 10, то и прицеливатся надо тут да же...

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

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

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

С другой стороны, если найдутся хорошие примеры реализации, то возможно смогу уламать шефа.

Вот такие пироги.
Что думаете господа?

Magnus

Я об индиго и говорил
http://www.theserverside.net/common/printthread.tss?thread_id=27235
Она будет не только Longhorn, а и в XP и в 2003 Sever.

Сегодня снова беседовал с шефом на тему.

Проблем с клиентом слишком много. У них и сервера контролируются ремотно местным отделением IBM. В компании работает 10К+ человек И НИ ЕДИНОГО ДБА!! Впрочем это к делу не относится...
Решили все таки делать с Enterprise Services.

Вообщем все еще ищутся примеры реализации. Подкиньте плиз у кого чего есть :).

Или хотя бы пните в нужном направлении.

Magnus

В жизни бы не подумал что все так просто. После продолжительных копаний и собирания инфы "с миру по нитке" выработал таки более-менее четкий план действий.
Сейчас все это видится простым до неприличия.
Я тут для коллег циркуляр на английском написал с подробными обьяснениями. Сори, на английском, русского они не телепают. Если кому нужно, чуть позже переведу.



Magnus

2 SM
Нет, там есть 2 опции экспорта Server application и Client application.

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

Если уж тема народ действительно интересует(сам я не нашел в нете step by step описания как чего делать) то все-таки переведу и доработаю скринами. Тогда наверное и в фак можно будет закинуть.

Да. Точно. На днях сделаю.

Я на эту бодягу уже 2 проэкта перевожу, нужно только оттестировать хорошенько на предмет перформенса, а так выглядит очень даже ничего себе :).

На счет транзакций, это одна из фичей, но не в первую очередь.

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

Cool, не правда ли?

2 кузя
Ага, я вот на это дело тоже поглядываю. Т.к. для моих задач собственно - самое оно. И у клиента как раз 2К3 стоит. Но у меня то на тачке 2К, как я это все дело девелопить буду? :)
Менять не охота. 2К3 слишком тяжелый для девелоперской машины, ХП слишпком медленная и дырявая и ваще терпеть ее не могу, даже с отключеным интерфейсом. :)


Magnus

SMПравильно ли я понял что каждый раз когда тебе нужно будет обновить код компоненты, тебе нужно будет делать экспорт серверный и для прокси - а потом переустанавливать прокси компонент на всех твоих 5тыс клиентах? :)
Думаю нет, если оставишь те же методы, только изменишь код. А если уж изменения кардинальные, то тут уж ничего не попишешь :).

SMКакие из них будут stateless какие statefull, как будешь передавать в этот слой connectionString?
А в чем проблема? Строку передать вполне можно, простым параметром. А потом как обычно закатать в регистр или какой нить конфиг на сервере.

2 snake
Был, полезный ресурс. Но учитывая, что я с DCOM до этого никогда не работал, то сразу и не вьехал чего куда экспортировать чтоб все это заработало :).
Плюс, как оказалось, у меня был битый COМ+, долго искал как его переинсталить.

Короче все не так гладко как кажется.
На деле оказалось что та самая прокся для клиента из ремотинга выколупывается.
И все сообщения тоже через него. Выходит так что Enterprise Services херня какая-то. Говорили ж мне: Overhead, Overhead, Overhead...

Плюс еще начали выскакивать какие-то левые проблемы. Оттестеный код который был перенесен из сервиса в компонент вдруг начал вываливатся c StackOverflowException. При чем на строке которая делает вызов API из натиной dll, там никаких лупов и рекурсии в жизни не валялось. Точно так же валятся все API вытзовы.

Короче крыша у меня уже снова едет. Это как если бы вы пришли домой пешком с работы, сели перед телеком и тут к вам подходит инспектор ГИБДД и выписывает штаф за превышение.

Magnus