Основы COM. Рудалев В.Г - 14 стр.

UptoLike

ВУЗ: 

ВГУ | Воронеж

Составители: 

Рубрика: 

14
Если требуется создавать не COM, а обычные объекты с интерфейсами , то ре -
комендуется их наследовать от класса TInterfacedObject, в котором реа -
лизованы методы IUnknown, но нет поддержки специфичных для COM эле-
ментов - фабрик классов , GUID и др. Потомки TInterfacedObject созда-
ются обычными конструкторами .
Детальное изложение программирования с использованием интерфейсом выхо-
дит за рамки данного пособия, ему посвящена книга [4], содержащая множест-
во интересных примеров .
1.6. Маршаллинг
В общем случае клиент и сервер занимают различное адресное пространство.
Маршаллинг (marshalling, транспортировка ) – это механизм передачи аргумен-
тов функций и возвращаемых значений через «границу» адресных пространств
процессов или по сети . Маршаллинг не требуется при работе с DLL-серверами ,
что упрощает их программирование.
Маршаллинг выполняется следующим образом. Получаемый клиентом указа-
тель интерфейса ссылается на специальный proxy-объект (объект - заместитель),
который работает внутри клиентского процесса . Заместитель предоставляет
клиенту те же интерфейсы , что и вызываемый объект COM на локальном или
удаленном сервере . Получив вызов от клиента , заместитель упаковывает его
параметры в отдельную структуру и с помощью средств операционной системы
передает вызов в процесс сервера . При этом используются общие области па -
мяти и механизм удаленного вызова процедур (Remote Procedure Call, RPC),
широко применяемый в операционных системах фирмы Microsoft. На сервере
вызов передается stub-объекту (заглушке ), который распаковывает вызов (де-
маршаллинг ) и передает его требуемому объекту COM.
Следует помнить :
• для внутренних серверов маршаллинг не требуется
• серверы автоматизации (т.е. серверы , использующие дуальные интерфей -
сы ) имеют встроенную реализацию маршаллинга для OLE-совместимых
типов (см . таблицу 1). Поэтому автоматизация – рекомендуемый подход .
• ручное программирование маршаллинга необходимо лишь в случае ис-
пользования внешних серверов , основанных на потомках IUnknown и
для некоторых несовместимых с автоматизацией типов данных
1.7. Модели потоков
Windows – многозадачная и многопоточная среда с вытесняющей многозадач-
ностью . Модель потоков определяет, каким образом будет функционировать
объект в многопоточной среде. Проблема состоит в том, что сервер и клиент
могут оказаться в разных потоках одного процесса или в разных процессах, а к
одному серверу могут обращаться множество клиентов . Для COM-объектов ,
создаваемых при помощи Delphi, модель потоков выбирается в диалоговом ок-
не при запуске мастера (см . раздел 2) и в дальнейшем регистрируется в систем -
ном реестре вместе с другой информацией об объекте. 
                                          14
Е сли требуется соз д ав ать не COM, а обы чны е объекты с и нтерфей сами , то ре-
коменд уется и х наслед ов ать от класса TInterfacedObject, в котором реа-
ли з ов аны метод ы IUnknown, но нет под д ерж ки специ фи чны х д ля COM эле-
ментов - фабри кклассов , GUID и д р. Потомки TInterfacedObject соз д а-
ю тсяобы чны ми конструкторами .
Д етальноеи з лож ени епрограмми ров ани яси спольз ов ани ем и нтерфей сом в ы хо-
д и тз а рамки д анного пособи я, ему посв ящ ена кни га [4], сод ерж ащ ая множ ест-
в о и нтересны х при меров .
1.6.   М арш алли нг
В общ ем случае кли ент и серверз ани маю т раз ли чное ад ресное пространств о.
М арш алли нг(marshalling, транспорти ров ка) – это механи з м перед ачи аргумен-
тов функци й и в оз в ращ аемы х з начени й через «грани цу» ад ресны х пространств
процессов и ли по сети . М арш алли нг нетребуетсяпри работесDLL-серверами ,
что упрощ аети х программи ров ани е.
М арш алли нг в ы полняется след ую щ и м образ ом. Получаемы й кли ентом указ а-
тель и нтерфей са ссы лается на специ альны й proxy-объект (объект-з амести тель),
которы й работает в нутри кли ентского процесса. Замести тель пред остав ляет
кли енту те ж е и нтерфей сы , что и в ы з ы в аемы й объект COM на локальном и ли
уд аленном серв ере. Получи в в ы з ов от кли ента, з амести тель упаков ы в ает его
параметры в отд ельную структуру и спомощ ью сред ств операци онной си стемы
перед ает в ы з ов в процесс сервера. При этом и спольз ую тся общ и е области па-
мяти и механи з м уд аленного в ы з ов а процед ур(Remote Procedure Call, RPC),
ш и роко при меняемы й в операци онны х си стемах фи рмы Microsoft. Н а сервере
в ы з ов перед ается stub-объекту (з аглуш ке), которы й распаков ы в ает в ы з ов (д е-
марш алли нг) и перед аетего требуемому объекту COM.
След уетпомни ть:
   • д ляв нутренни х серверов марш алли нг нетребуется
   • серв еры ав томати з аци и (т.е. серверы , и спольз ую щ и ед уальны еи нтерфей -
     сы ) и мею тв строенную реали з аци ю марш алли нга д ля OLE-сов мести мы х
     ти пов (см. табли цу 1). Поэтому ав томати з аци я–рекоменд уемы й под ход .
   • ручное программи ров ани е марш алли нга необход и мо ли ш ь в случае и с-
     польз ов ани я в неш ни х серверов , основ анны х на потомках IUnknown и
     д лянекоторы х несов мести мы х сав томати з аци ей ти пов д анны х
1.7. М оде ли поток ов
Windows – многоз ад ачная и многопоточная сред а с в ы тесняю щ ей многоз ад ач-
ностью . М од ель потоков опред еляет, каки м образ ом буд ет функци они ров ать
объект в многопоточной сред е. Проблема состои т в том, что сервери кли ент
могутоказ аться в раз ны х потоках од ного процесса и ли в раз ны х процессах, а к
од ному серверу могут обращ аться множ еств о кли ентов . Д ля COM-объектов ,
соз д ав аемы х при помощ и Delphi, мод ель потоков в ы би рается в д и алогов ом ок-
непри з апускемастера (см. раз д ел 2) и в д альней ш ем реги стри руетсяв си стем-
ном реестрев местесд ругой и нформаци ей об объекте.

Страницы