В останній раз я був в Берліні ще до падіння стіни. Коли, залишаючи американський сектор у пропускного поста «Чекпойнт Чарлі», я в'їжджав в Східний Берлін, не виникало сумнівів, що тут проходить межа. Колючий дріт, автоматники і мінні поля робили її дуже чіткою. Але і за оборонною лінією відмінності були очевидні: зі східного боку від стіни дволітрові малолітражки вивергали густий дим, а біля магазинів стояли довгі черги.
Зміни чекають нас при всякому переході кордону, неважливо, наскільки мало відрізняється одна сторона від іншої. Ця глава присвячена перетину кордонів - головним чином, кордонів між різними процесами. Ми розглянемо також перетин кордонів між машинами.
Чому нам потрібно виходити за кордон процесу? Тому, що в деяких випадках краще реалізувати компонент в EXE, а не в DLL. Однією з причин може стати те, що ваша заявка вже реалізовано в EXE. Після невеликого доопрацювання можна зробити доступними сервіси додатки, так що клієнти зможуть автоматизувати його використання.
Якщо компонент і клієнт перебувають у різних EXE, вони будуть розташовані і в окремих процесах, оскільки для кожного EXE-модуля створюється свій процес. При передачі інформації між такими компонентом і клієнтом необхідно перетнути кордон між процесами. На щастя, при цьому немає потреби змінювати код компонента, хоча деякі зміни в клас CFactory. представлений в попередньому розділі, внести все-таки доведеться. Однак, перш ніж перейти до реалізації, слід розглянути проблеми і рішення, пов'язані зі зверненням до інтерфейсів СОМ через кордони процесів.
У той час як кожному EXE-модуля відповідає свій процес, DLL проектується в процес того EXE, з яким вони скомпоновані. З цієї причини DLL називають серверами всередині процесу (in process). а EXE - серверами поза процесом (out of process). Іноді EXE також називають локальними серверами. щоб відрізнити їх від іншого виду серверів поза процесом - віддалених серверів. Віддалений сервер - це сервер поза процесом, що працює на іншій машині.
доступу до пам'яті, пов'язаної з інтерфейсом, то він не зможе викликати і функції цього інтерфейсу. У такій ситуації наші інтерфейси стали б зовсім марні.
Для того, щоб з інтерфейсом можна було працювати через кордони процесу, необхідно наступне. "Процес повинен мати можливість викликати функцію в іншому процесі.
"Процес повинен мати можливість передавати іншому процесу дані.
"Клієнт не повинен турбуватися про те, чи є компонент сервером всередині або поза процесом.
Локальний виклик процедури
Є багато методів межпроцессной комунікації, включаючи DDE, іменовані канали і пам'ять, що розділяється. Однак СОМ використовує локальний виклик процедури (local procedure call, LPC). LPC - це засіб зв'язку між різними процесами на одній і тій же машині. LPC є спеціалізоване засіб зв'язку між різними процесами в межах однієї машини, побудоване на основі віддаленого виклику процедури (remote procedure call, RPC) (див. Рис. 10-2).
Стандарт RPC визначено OSF (Open Software Foundation) в специфікації DCE (Distributed Computing Environment) RPC. RPC забезпечує комунікацію між процесами на різних машинах за допомогою різноманітних мережевих протоколів. Розподілена модель СОМ (DCOM), яку ми будемо розглядати далі в цій главі, використовує RPC для зв'язку по мережі.
Локальний виклик процедури
Мал. 10-2 Клієнт в EXE використовує механізм Win32 LPC для виклику функцій компонента, реалізованого в іншому EXE
Для маршалинга компонента призначений інтерфейс IMarshal. У процесі створення компонента СОМ запитує у нього цей інтерфейс. Потім СОМ викликає функції-члени цього інтерфейсу для маршалинга і демаршалінга параметрів до і після виклику функцій. Бібліотека СОМ реалізує стандартну версію IMarshal. яка працює для більшості інтерфейсів. Основною причиною створення власної версії
Для продовження скачування необхідно зібрати картинку: