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

HL>Здравствуйте, Smirnov.Anton, Вы писали:

SA>>К сервисам доступ может осуществляться различными способами:
SA>>

SA>>1. прямые вызовы
SA>>2. кроссконтекстные вызовы
SA>>3. кроссдоменные вызовы
SA>>4. кросспроцессные вызовы
SA>>

SA>>как осуществить 1,2 и 4 ясно.
SA>>Как поступить с кроссдоменными — не совсем понятно
HL>3 — это то же самое, что и 4. Отличние — домены находятся в разных процессах.
HL>Я бы вообще не стал различать эти случаи — просто опубликовал бы контейнер сервисов и единообразно обращался к нему отовсюду, при необходимости меняя физику канала связи.

в принице оно так, всё это Remoting
только вот:
изначально проектировалось только для классического ремоутинга (ipc, tcp, ...)
есть общий некое ядро, в котором хранятся адреса, на которых опубликованы экземпляры сервисов, хранятся только host+port (для IPC адрес получается ipc://[host]:port/)
uri сервиса получается из его описания(аттрибута интерфейса)
таким образом:
при старте сервиса он прописывает свой адрес в этом ядре
при активации сервиса — получается адрес сервиса из ядра, формируется url, поднимается если нужно требуемый канал, активируется
очень уж не хочется ChannelData от CrossAppDomain хранить в ядре, или что ещё хуже — его objref