Есть некое приложение.
В приложении присутствует такое понятие, как сервис.
В приложении может быть создано несколько AppDomain'ов.
К сервисам доступ может осуществляться различными способами:
как осуществить 1,2 и 4 ясно.
Как поступить с кроссдоменными — не совсем понятно
Хочется по аналогии с 1 и 2, через контейнер сервисов.
То есть, в результате необходим контейнер, к которому есть доступ из всех доменов приложения.
Как это сделать... в голову приходят несколько вариантов, каждый из которых не до конца нравится:
1. создать контейнер в основном домене, контролировать создание новых доменов и пропихивать в него через SetData отмаршаленную ссылку на контейнер из основного домена
2. опубликовать фабрику для контейнера на IPC канале с уникальным для процесса uri в главном домене при инициализации приложения либо, чтоб уйти от от понятия главного — создавать в первом, который не найдёт существующий.
3. каким то способом получить все домены приложения и из каждого получать с использованием GetData опубликованный в нём контейнер. В итого можно получить аггрегированный контейнер, который может считаться общим для всех доменов приложения
вообще более интереснен подход #3, так как не очень хочется централизовывать
остаётся вот вопрос, как получить все домены приложения.
видится примерно такой подход(для данной конретной ситуации)
получить через рефлекшн метод класса AppDomain
Здравствуйте, Smirnov.Anton, Вы писали:
SA>К сервисам доступ может осуществляться различными способами: SA>
SA>1. прямые вызовы SA>2. кроссконтекстные вызовы SA>3. кроссдоменные вызовы SA>4. кросспроцессные вызовы SA>SA>как осуществить 1,2 и 4 ясно. SA>Как поступить с кроссдоменными — не совсем понятно
3 — это то же самое, что и 4. Отличние — домены находятся в разных процессах.
Я бы вообще не стал различать эти случаи — просто опубликовал бы контейнер сервисов и единообразно обращался к нему отовсюду, при необходимости меняя физику канала связи.
Здравствуйте, 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
Здравствуйте, Smirnov.Anton, Вы писали:
SA>изначально проектировалось только для классического ремоутинга (ipc, tcp, ...)
Что такое не-классический ремоутинг?
Я правильно понял, что в каждом домене может быть создано N сервисов, и к каждому из этих сервисов может обращаться различное число клиентов из различных доменов/процессов?
Здравствуйте, HowardLovekraft, Вы писали:
HL>Здравствуйте, Smirnov.Anton, Вы писали:
SA>>изначально проектировалось только для классического ремоутинга (ipc, tcp, ...) HL>Что такое не-классический ремоутинг?
надо было в кавычки поставить
просто кроссдоменный ремоутинг вес спрятан внутри с учётом того, что он будет использоваться автоматически при CrossAppDomainCallback или AppDomain.CreateObjectAndUnwrap
а каналы c IPC, TCP, ... открыты так что ими можно пользоваться и настраивать в отрытую
согласен что неудачный термин
неклассическим его назвал, так как добираюсь до сервисов сейчас через
RemotingServices.Connect(type, url, channeldata)
конечно с url аля
/bf6ef9f4_1693_42d1_a1d9_fe698dbbc03d/qamkyau2eusvk0vumndifxv_20.rem
тоже пройдёт, только вот хранить его негде
это конечно можно устроить, только вот ничего хорошего имхо не получится в любом случае
придерживаюсь мнения, что всё же кроссдомен больше похож на кроссконтекст или прямое взаимодействие, чем на кросспроцессное
HL>Я правильно понял, что в каждом домене может быть создано N сервисов, и к каждому из этих сервисов может обращаться различное число клиентов из различных доменов/процессов?
да, верно
Здравствуйте, Smirnov.Anton, Вы писали:
SA>придерживаюсь мнения, что всё же кроссдомен больше похож на кроссконтекст или прямое взаимодействие, чем на кросспроцессное
Вам нужно абстрагировать клиентов от того, где находится конкретный сервис. Напрашивается Service Locator.
Здравствуйте, HowardLovekraft, Вы писали:
HL>Здравствуйте, Smirnov.Anton, Вы писали:
SA>>придерживаюсь мнения, что всё же кроссдомен больше похож на кроссконтекст или прямое взаимодействие, чем на кросспроцессное HL>Вам нужно абстрагировать клиентов от того, где находится конкретный сервис. Напрашивается Service Locator.
я этим и занимаюсь в данный момент
попросил совета, как быть с кроссдоменом
