Subj.: возможно ли такое?

Более конкретно — мне нужно (по ряду причин) производить удаленные создание и (далее) вызов объектов COM, не используя стандартных средств, таких, как DCOMCFG и дальнейший CoCreateInstance/CoCreateInstanceEx через
Microsoft RPC. Однако я не хочу полностью реализовывать marshaling (т.е. полностью писать proxy и stub для каждой функции каждого интерфейса, заниматься вручную упаковкой параметров и т.д.). Интерфейсы у меня,естественно, описаны на IDL, поэтому эта самая упаковка/распаковка параметров в том или ином виде запрограммирована MIDL'ом, вопрос в том, как ее вызвать:

— для клиента — "попросив" записать все, например, в предоставленный мной IStream (который дальше передается моим собственным транспортом на другую машину);

— для сервера — "попросив" распаковать полученные данные и вызвать реальный объект через реальный интерфейс. (Ну и, естественно, все то же — при возврате из функции.)

P.S. Потребуется еще позаботиться о правильной передаче указателей на интерфейсы при удаленных вызовах, но это — меньшая из проблем: достаточно реализовать интерфейс IMarshal в каждом объекте, причем реализация эта будет довольно простой и почти одинаковой для разных объектов.

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

S>Subj.: возможно ли такое?

S>Более конкретно — мне нужно (по ряду причин) производить удаленные создание и (далее) вызов объектов COM, не используя стандартных средств, таких, как DCOMCFG и дальнейший CoCreateInstance/CoCreateInstanceEx через
S>Microsoft RPC. Однако я не хочу полностью реализовывать marshaling (т.е. полностью писать proxy и stub для каждой функции каждого интерфейса, заниматься вручную упаковкой параметров и т.д.). Интерфейсы у меня,естественно, описаны на IDL, поэтому эта самая упаковка/распаковка параметров в том или ином виде запрограммирована MIDL'ом, вопрос в том, как ее вызвать:

S>- для клиента — "попросив" записать все, например, в предоставленный мной IStream (который дальше передается моим собственным транспортом на другую машину);

S>- для сервера — "попросив" распаковать полученные данные и вызвать реальный объект через реальный интерфейс. (Ну и, естественно, все то же — при возврате из функции.)

S>P.S. Потребуется еще позаботиться о правильной передаче указателей на интерфейсы при удаленных вызовах, но это — меньшая из проблем: достаточно реализовать интерфейс IMarshal в каждом объекте, причем реализация эта будет довольно простой и почти одинаковой для разных объектов.

Испопользуй SOAP-формат для маршалинга при помощи объектов из MSSOAP SDK (не устаналивая при этом HTTPпишного соединения, пользуясь только соответсвующими обектами локально для сериализации в XML и гоня потом своим транспортом). На сервере, например, нужно всего 4 вызова, чтобы из стрима с XML получить реальный локальный вызов какого-нибудь COM объекта....
:))))))))))

А>Испопользуй SOAP-формат для маршалинга при помощи объектов из MSSOAP SDK (не устаналивая при этом HTTPпишного соединения, пользуясь только соответсвующими обектами локально для сериализации в XML и гоня потом своим транспортом). На сервере, например, нужно всего 4 вызова, чтобы из стрима с XML получить реальный локальный вызов какого-нибудь COM объекта....
А>:))))))))))

XML — это, однако, накладно, не по-человечески :). Мне временами придется перегонять через COM-вызовы не слишком маленькие объемы данных. И, кроме того, этот самый SOAP действительно использует стандартный marshaling (т.е. то, что генерирует MIDL), или ему нужна какая-нибудь другая информация об обрабатываемых интерфейсах?

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

А>>Испопользуй SOAP-формат для маршалинга при помощи объектов из MSSOAP SDK (не устаналивая при этом HTTPпишного соединения, пользуясь только соответсвующими обектами локально для сериализации в XML и гоня потом своим транспортом). На сервере, например, нужно всего 4 вызова, чтобы из стрима с XML получить реальный локальный вызов какого-нибудь COM объекта....
А>>:))))))))))

S>XML — это, однако, накладно, не по-человечески :). Мне временами придется перегонять через COM-вызовы не слишком маленькие объемы данных. И, кроме того, этот самый SOAP действительно использует стандартный marshaling (т.е. то, что генерирует MIDL), или ему нужна какая-нибудь другая информация об обрабатываемых интерфейсах?

Скорость сериализации зависит, конечно, от размера параметров, но XML тут уже не причем — разбор XML уже выполнен и сериализация значения практически эквивалентна sprintf...
MS SOAP использует typelib, чтобы сгенерить свою информацию об интерфейсе (конечно в XML :); делается соответсвующим визардом...)

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

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

А>>>Испопользуй SOAP-формат для маршалинга при помощи объектов из MSSOAP SDK (не устаналивая при этом HTTPпишного соединения, пользуясь только соответсвующими обектами локально для сериализации в XML и гоня потом своим транспортом). На сервере, например, нужно всего 4 вызова, чтобы из стрима с XML получить реальный локальный вызов какого-нибудь COM объекта....
А>>>:))))))))))

S>>XML — это, однако, накладно, не по-человечески :). Мне временами придется перегонять через COM-вызовы не слишком маленькие объемы данных. И, кроме того, этот самый SOAP действительно использует стандартный marshaling (т.е. то, что генерирует MIDL), или ему нужна какая-нибудь другая информация об обрабатываемых интерфейсах?

А>Скорость сериализации зависит, конечно, от размера параметров, но XML тут уже не причем — разбор XML уже выполнен и сериализация значения практически эквивалентна sprintf...
А>MS SOAP использует typelib, чтобы сгенерить свою информацию об интерфейсе (конечно в XML :); делается соответсвующим визардом...)

А-га... и получится и через COM и через http. Во ускорение. :)

Теперь по делу. А зачем нужны все эти трудности? Какой транспорт будет использоваться?

Если вопрос действительно интересен прочти вот это: http://www.optim.ru/cs/2000/3/marshaling/marsh.asp

2 аноним:
SOAP — не поканает :( . Я посмотрел пример — так там на вызов, практически не несущий параметров, тратится около 400 байт — это IMHO ЯВНЫЙ перебор! Ну, а "в пределе" при передаче массива бинарных данных XML-текст получится, как я подозраваю, в два раза длиннее, чем этот самый массив. Так что — SOAP не проходит. Хотя... если это все по-быстрому архивировать и распаковывать... :)

2 Vlad2D:
Если по делу — то мне нужно использовать "удаленный" COM, но нельзя (по достаточно идиотской причине, но нельзя :( ) оформлять серверную часть как COM-сервер. А в кач-ве транспорта планируется TCP/IP.

P.S. А статью я эту уже читал — достаточно интересно, но совсем о другом...

P.P.S. Посмотрел я код proxy, генерируемый MIDL — так там сплошные вызовы ф-ций с префиксом Rcp — т.е. они не формируют никакие запросы для внешнего применения, они их формируют как какие-то структуры и тут же отправляют. Придется, видимо, действительно писать весь код proxy/stub самостоятельно. Можно даже попробовать написать на этот счет нечто универсальное, со своим языком описания интерфейсов ;) .

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

VD>А-га... и получится и через COM и через http. Во ускорение. :)

Кто сказал HTTP?! Причем здесь транспорт?! Почитайте что-нибудь популярное про SOAP...:))

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

S>2 аноним:
S>SOAP — не поканает :( . Я посмотрел пример — так там на вызов, практически не несущий параметров, тратится около 400 байт — это IMHO ЯВНЫЙ перебор! Ну, а "в пределе" при передаче массива бинарных данных XML-текст получится, как я подозраваю, в два раза длиннее, чем этот самый массив. Так что — SOAP не проходит. Хотя... если это все по-быстрому архивировать и распаковывать... :)

Base64 encoded бинарный массив будет. Смотри, конечно, сам много-ли 400 байт на вызов.А сколко "байт" на DCOM "...вызов, практически не несущий параметров..." (я не знаю — просто ради интереса :))?

2 Аноним:

А>Base64 encoded бинарный массив будет. Смотри, конечно, сам много-ли 400 байт на вызов.А сколко "байт" на DCOM "...вызов, практически не несущий параметров..." (я не знаю — просто ради интереса :))?

Я тоже не знаю. Но полагаю, что вполне может быть не более 20 (не считая расходы на транспортный протокол) — ну не надо там передавать никакого текста, только какие-нибудь handle'ы.

Кстати — почему байты попали в кавычки? Ты пользуешься архитектурами, где вторичной (после бита) единицей информации является что-то иное??

А 400 — чисто по-человечески жалко :) Да и коллеги не поймут. И еще: Base64 во сколько (все-таки) раз увеличивает объем?