Здравствуйте все!
Помогите мне пожалуйста разобраться. Стал потихоньку смотреть .Net, экспериментирую с Remoting...
Итак:
Если я всё правильно понял, существует два способа активации: серверная и клиентская.
При серверной на сервере следует зарегистрировать тип вызовом RemotingConfiguration.RegisterWellKnownServiceType, затем, чтобы создать proxy на клиентской стороне, на клиенте сделать Activator.GetObject (либо всё то же но с помощью конфигурационных файлов).
При клиентской на сервере -- RemotingConfiguration.RegisterActivatedServiceType, на клиенте -- Activator.CreateInstance (либо RemotingConfiguration.RegisterActivatedServiceType, а потом new, либо опять же регистрировать с помощью конфигов и потом new).
При серверной активации объект работает в процессе сервера, вызов Activator.GetObject фактически создаёт proxy для серверного объекта. Здесь всё понятно. Всё зашибись работает.
Теперь вопрос. При клиентской активации мне не понятно. Почему процесс, в котором была выполнена регистрация сервера должен существовать, если активация клиентская? Оно работает только когда серверный процесс, в котором был выполнен вызов RemotingConfiguration.RegisterActivatedServiceType работает. Не понимаю тогда, причём тут клиентская активация, если процесс на сервере надо создать "ручками", т.к. именно там выполняется регистрация. Я же хочу сказать с клиента: "создай мне экземпляр такого-то класса вот там-то". .Net не может сам создать на сервере процесс и поместить в него экземпляр класса, а мне на клиента вернуть proxy (подобно тому, как мы делаем в DCOMе)? Как так сделать, подскажите, люди добрые... В какую сторону хоть глядеть? Или в .Net сплошные Web-сервисы и я принудительно должен класс-сборку как-нибудь хитро прорегистрировать на сервере или затащить куда (в IIS)? Не может быть чтобы было так неудобно... (Нет, понятно, когда я сознательно делаю Web-сервис, к которому обращаться собираюсь через SOAP, но "простое"-то обращение по TCP как сделать?) Может, с Global Assembly Cashe чего-нибудь шаманить надо, регистрировать как-то там? Но "указивок" на это дело в доке я что-то не увидал... Да и доки наидерьмовейшие, описания чересчур краткие, хрен чего найдёшь вообще, в примерах используются методы, каких вообще нету, и т.п.

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


Ну тут ты загнул хост сервер можно загнать в сервис...и проблем нет...
Но дело не в этом чтоб сдлать как в DCOM надо:
сервер-активированые обьеты бывают 3 типов:
Singleton , SingleCall.
и третий
CAO или Client Activated Object вот он работает как ДСОМ
когда на клиенте делаешь new то на сервере этот обьект сразу создается.
Чтоб сделать нужно чтоб небыло
wellknown mode=... в конфиг файле
а надо вот так на сервере
<service>
<activated type="MyServer.Hello,MyServer">
</activated>
</service>

и так на клиенте

<client url="http://localhost:8085">
<activated type="MyServer.Hello,MyServer"/>
</client>

Удачи.

Погоди, Archer, я не понял.
Есть у меня класс, который MarshalByRefObject, назовём его Messager. Он помещён в сборку MessagerSrv.dll Как мне к этой сборке "привернуть" конфигурационный файл?? Просто штоли назвать его MessagerSrv.dll.config?

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

AK>Погоди, Archer, я не понял.
AK>Есть у меня класс, который MarshalByRefObject, назовём его Messager. Он помещён в сборку MessagerSrv.dll Как мне к этой сборке "привернуть" конфигурационный файл?? Просто штоли назвать его MessagerSrv.dll.config?

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

RemotingConfiguration.Configure(@"..\..\hostapp.exe.config");

ну удачи ..

Дык вот, Archer, я никак и не пойму, как сервера вообще могут хоститься и где. Когда Web-сервис или виндатый сервис -- всё понятно. А как распределённую обработку устраивать, как это было в DCOM, не понимаю... Неужели всегда надо вручную хостить... Нет, ну должны же сервера, к которым по TCP обращаешься как-то хоститься? Иначе как потом COM+, транзакционности всякие работают...

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

AK>Дык вот, Archer, я никак и не пойму, как сервера вообще могут хоститься и где. Когда Web-сервис или виндатый сервис -- всё понятно. А как распределённую обработку устраивать, как это было в DCOM, не понимаю... Неужели всегда надо вручную хостить... Нет, ну должны же сервера, к которым по TCP обращаешься как-то хоститься? Иначе как потом COM+, транзакционности всякие работают...

помоему .НЕТ ремотинг не замена СОМ+ или ДСОМ а просто .НЕТ технология....
так как .НЕТ коипонент можна использовать как СОМ то значит "возможно" его можно и для ДСОМ использовать... с этим еще не разбирался.

Да нет, я думаю DCOM тут не причём. Понятно, что можно сделать TLBEXP и потом пользовать как будто бы по DCOM, но это не выход...
Ну, пока ладно. Может кто-нибудь ещё сюда напишет, буду надеяться... :)

Это я ответил! И никакой не "Аноним" ;)

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

AK>Дык вот, Archer, я никак и не пойму, как сервера вообще могут хоститься и где. Когда Web-сервис или виндатый сервис -- всё понятно. А как распределённую обработку устраивать, как это было в DCOM, не понимаю... Неужели всегда надо вручную хостить... Нет, ну должны же сервера, к которым по TCP обращаешься как-то хоститься? Иначе как потом COM+, транзакционности всякие работают...
Ну во первых в качестве хоста может выступать IIS. Для этого достаточно положить в каталог веб-приложения
web.config примерно такого содержания

<configuration>
  <system.runtime.remoting>
    <application>

      <service>
        <wellknown mode="SingleCall" type="Hello.HelloService, Hello" objectUri="HelloService.soap" />
      </service>

    </application>
  </system.runtime.remoting>
</configuration>

В каталог bin кладешь свои сборки

Здравствуйте AndrewVK!
Я понимаю, что так можно, но нельзя же для элементарного вызова по локальной сети использовать Web-сервис (через SOAP и регистрацию сборки в IIS). Ерунда какая-то. Мне нужно просто создать удалённо экземпляр класса и повыполнять его методы.

Здравствуйте Аноним, Вы писали:

А>Здравствуйте AndrewVK!
А>Я понимаю, что так можно, но нельзя же для элементарного вызова по локальной сети использовать Web-сервис (через SOAP и регистрацию сборки в IIS). Ерунда какая-то. Мне нужно просто создать удалённо экземпляр класса и повыполнять его методы.
За каким тебе Web Service понадобился? И никакой сборки в IIS регистрировать тоже не нужно. Нужно создать в IIS виртуальную директорию и положить в нее файлы.
И я так и не понял — чем не устраивает хост?

Я про работу через TCP спрашиваю...
И потом, что, теперь все сборки, чьи классы я хочу пользовать удалённо необходимо класть в виртуальную директорию IISа???

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

AK>Я про работу через TCP спрашиваю...
AK>И потом, что, теперь все сборки, чьи классы я хочу пользовать удалённо необходимо класть в виртуальную директорию IISа???

Ты наверное ищешь аналог DCOM, когда объект создаётся на сервере по требованию клиента, при этом при необходимости загружается и сам исполняемый модуль? В DCOM этим занимается та часть COM, которая встроена в ОС и всегда на "чеку" или COM+, который тоже должен быть активизирован. В .NET такого нет, ты должен сам стартануть модуль, который будет хостить объекты, помоему в CORBA сделано также. К тому же этот модуль можно сделать NT сервисом, что бы не было проблем с запуском на машинах без залогиненного пользователя. Мне почему то кажеться, что возможность писать сервисы на C# была добавлена исключительно по этой причине, т.е. чтобы присать хосты для ремотинга.

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

AK>Я про работу через TCP спрашиваю...
AK>И потом, что, теперь все сборки, чьи классы я хочу пользовать удалённо необходимо класть в виртуальную директорию IISа???
Те которые не лежат в GAC

Да, IT, спасибо!
Кажется я всё понял. Промучавшись вчерась ещё полдня, я ничего нового не нашёл. Видать, сервер обязательно должен где-то хоститься (явно). При распределённой архитектуре с выделенным слоем бизнес-логики, это видать COM+. А если простой ремоутинг устраивать, то видать нужно действительно писать сервис для хостения серверных объектов. Конечно, по-идее, это правильно и логично, т.к. становится ясно чего в каком процессе работает и этим можно более гибко управлять. Но, неудобно. Мдааа... Надо думать, как апгрейдить существующую DCOM-архитектуру наших систем...