2.4.2. Створення сом-клієнта

Крок 1. Створення нового проекту

Ланцюжок: File->New -> Application.

Створений проект зберігаємо, вказуючи його ім’я (наприклад MainClient).

Крок 2. Додавання до проекту клієнта файлу бібліотеки типів

Для забезпечення використання СОМ-об’єкту SimpleCom з інтерфейсом ІSimpleCOM необхідно додати до проекту модуль бібліотеки типів InProcCom_TLB.pas.

Ланцюжок: Project-> Add to Project.

Також необхідно в секції uses основного модуля передбачити підключення до нього цієї бібліотеки типів.

Крок 3. Оголошення інтерфейсів

У секції public форми MainClient оголошуемо дві змінні, типи яких – інтерфейси, що містяться в СОМ-об'єкті:

Interface1:ISimpleCom;

Interface2:ISimpleCom2;

2.4.3. Використання сом-об’єкту в клієнтській програмі

Крок 1. Створення СОМ-об’єкту в клієнтській програмі

Створення СОМ-об’єкту досягається за рахунок звернення до фабрики класу СОМ-об’єкту (метод Create). Таке звернення можна зробити, наприклад, у процедурі обробки події OnActivate головної форми клієнтського застосунка.

Метод створює СОМ-об’єкт та повертає вказівник на базовий (перший) інтерфейс СОМ-об’єкту. Для отримання вказівника на другий інтерфейс використовуємо метод QueryInterface(ім’я_інтерфейсу2, змінна2) для базового інтерфейсу, наприклад:

procedure TForm1.FormActivate(Sender: TObject);

begin

Interface1 := CoSimpleCom.Create;

Interface1.QueryInterface(ISimpleCom2, Interface2);

end;

Крок 2. Використання методів інтерфейсів

Для отримання необхідних програмі-клієнту результатів використовуємо методи інтерфейсів, наприклад:

procedure TForm1.Button1Click(Sender: TObject);

begin

label2.Caption:= IntToStr(Interface1.linear2x(SpinEdit1.Value));

label4.Caption:= IntToStr(Interface1.linear5x(SpinEdit1.Value));

end;

2.5. Механізм міжпроцесного обміну

Для здійснення міжпроцесного обміну COM-технологія використовує механізм локального виклику процедури (local procedure call, LPC). LPC являє собою спеціалізований засіб зв'язку між різними процесами в межах однієї машини, побудований на основі механізму віддаленого виклику процедури (remote procedure call, RPC).

Стандарт RPC визначений OSF (Open Software Foundation) у специфікації DCE (Distributed Computing Environment). RPC забезпечує комунікацію між процесами на різних машинах за допомогою різноманітних мережевих протоколів. Розподілена модель COM (Distributed COM, DCOM) використовує RPC для зв'язку мережею.

LPC використовує для своєї роботи системні виклики. Операційній системі відомі фізичні адреси, що відповідають логічному адресному простору кожного процесу. Отже, операційна система може викликати функції будь-якого процесу. Але викликати відповідну функцію ще недостатньо, треба передати параметри функції з адресного простору клієнта в адресний простір компонента. Для позначення цього процесу в англомовній літературі використовується термін marshaling (marsaling - у дослівному перекладі з англійської означає "розміщення у визначеному порядку").

Маршалінг − це механізм, що дозволяє клієнту виконувати виклики методів інтерфейсів СОМ-об'єктів, що входять до складу зовнішніх СОМ-серверів (СОМ-серверів, які виконуються в окремому процесі або на іншій машині) та передавати їм визначені параметри. Маршалінг використовує вказівники інтерфейсів СОМ-об’єктів, для забезпечення розробникам клієнтських застосунків можливості викликати методи його інтерфейсів. Основне призначення механізму маршалінгу − передавання сформованих клієнтським застосунком необхідних аргументів викликаним методам та повернення клієнтам результатів їх виконання. Передавання параметрів відбувається таким чином, щоб забезпечити коректне виконання сервером викликаних методів у своєму адресному просторі.

Якщо обидва процеси виконуються на одній машині, маршалінг здійснюється просто. Дані одного процесу необхідно скопіювати в адресний простір іншого процесу. Якщо процеси виконуються на різних машинах, то дані необхідно перетворити в стандартний формат, що враховує міжмашинні розходження, наприклад, порядок проходження байтів у слові. Механізм LPC здатний скопіювати дані з одного процесу в інший. Але для вибирання параметрів і пересилання їх в інший процес йому потрібно більше інформації, ніж та, котру він одержує програмним способом, наприклад із заголовкового файлу C++.

Наприклад, вказівники на структури варто обробляти інакше, ніж просто цілі числа. Маршалінг вказівника містить у собі копіювання в інший процес структури, на яку вказівник посилається. Однак, якщо вказівник – це вказівник на інтерфейс, то область пам'яті, на яку він посилається, копіюватися не повинна. Отже, для виконання маршалінгу треба зробити щось більше, ніж просто виклик memcpy().

Для маршалінгу компонента призначений інтерфейс IMarshal. У процесі створення компонента СОМ запитує в нього цей інтерфейс. Потім СОМ викликає методи цього інтерфейсу для маршалінгу і демаршалінгу параметрів до і після виклику функцій. Бібліотека СОМ реалізує стандартну версію інтерфейсу IMarshal, що працює для більшості інтерфейсів. Основною причиною створення власної версії IMarshal є прагнення підвищити продуктивність своїх компонентів.

Хоча більшість розробників для Windows цього і не знають, вони використовують LPC практично при будь-якому виклику функції Win32. Виклик функції Win32 викликає функцію в DLL, яка через LPC викликає код Windows, фактично виконуючи роботу. Така процедура ізолює програму, що перебуває у своєму процесі, від коду Windows. Програма не зможе зруйнувати операційну систему, внаслідок того, що в різних процесах використовуються різні адресні простори. Якщо програма використовує зовнішній СОМ-сервер, то вона розташовується в пам'яті за однією адресою, а сервер завантажується за іншою. Змінні, оголошені в клієнтському застосунку, завантажуються за визначеною адресою, яка є адресою у віртуальній пам'яті.

Нехай, наприклад, у клієнтському застосунку оголошено змінну MyInt типу Integer, чия адреса в пам'яті $00442830. Програма зовнішнього СОМ-сервера не зможе одержати доступ до пам'яті за цією адресою, оскільки одна програма не може одержати прямий доступ до адресного простору іншої програми. Windows передає дані від клієнтської програми до сервера за допомогою процесу маршалінгу. Операційна система може автоматично передавати таким чином змінні наступних визначених у Delphi типів: Smallint, Integer, Single, Double, Currency, TDateTime, WideString, IDispatch, SCODE, WordBool, OleVariant, IUnknown, Shortint, Byte, Word, UINT, int64, Largeint, SYSINT, SYSUINT, HResult, Pointer, SafeArray, PChar, і PWideChar.

Із перерахованих вище, типи Smallint, Integer, Single, Double, Currency, TDateTime, WideString, IDispatch, SCODE, WordBool, OleVariant, IUnknown, Shortint і Byte є сумісними з технологією автоматизації, тобто вони можуть вільно використовуватися серверами автоматизації СОМ.

Клієнт взаємодіє з системною СОМ-DLL, яка виконує за клієнта маршалінг і виклики LPC. У СОМ такий компонент (proxy) називається заступником (представником) СОМ-об’єкту. У термінах СОМ, заступник – це компонент, який входить до складу клієнта, але діє як компонент, який входить до складу сервера. Заступники повинні міститися в DLL, оскільки їм необхідний доступ до адресного простору клієнта для маршалінгу даних, переданих функціям інтерфейсу. Але маршалінг – це лише половина справи. СОМ-об'єкту потрібна DLL, яка називається заглушкою (stub), для демаршалінгу даних, отриманих від клієнта. Заглушка виконує також маршалінг даних, що повертаються компонентом клієнту.

Для виклику метода інтерфейсу СОМ-об’єкту клієнтом, аргументи методу заносяться у стек і здійснюється виклик методу, використовуючи вказівник інтерфейсу. У разі виклику зовнішнього СОМ-об’єкту, запит сприймається PROXY-представником сервера, який пакує аргументи в пакет маршалінгу і передає цей пакет до віддаленого СОМ-об’єкту, використовуючи встановлені мережеві протоколи. Клієнт спілкується саме з PROXY-представником, він навіть не підозрює про наявність віддаленого сервера. Саме PROXY-представник відповідає за з'єднання із сервером, передавання йому викликів клієнта, приймання відповіді від сервера і передавання відповіді клієнту.

У складі сервера функціонує аналогічний представник клієнта – STUB ("заглушка"), що розпаковує отриманий пакет, зчитує аргументи зі стека, і викликає на виконання метод сервера, який запитує клієнт. СОМ-об'єкт повторює виклик методу у своєму власному адресному просторі. У такий спосіб сервер також "не знає" про наявність клієнта, він спілкується лише з представником клієнта.

Таким чином система PROXY – КАНАЛ ЗВ'ЯЗКУ- STUB забезпечує взаємодію клієнта із СОМ-сервером, і така взаємодія відбувається прозорим для обох чином (рис. 2.5).

Я кий спосіб маршалінгу вибирається, залежить від того, як саме реалізовано COM-об'єкт. Об'єкти можуть використовувати стандартний спосіб маршалінга, наданий інтерфейсом IMarshal, тобто типовий механізм маршалінгу, що дозволяє здійснювати зв'язок сервера і клієнта через стандартний механізм RPC – (Remote Procedure Call) – механізм виклику віддалених процедур.

Розробнику клієнта необхідно мати на увазі також наступне: якщо деякий інтерфейс навіть такий, що не є спадкоємцем IDispatch, при зверненні до методів СОМ-об’єкту обмежує себе використанням сумісними з автоматизацією типами (і при цьому використовує зареєстровану бібліотеку типів), то в такому разі COM-технологія автоматично забезпечує підтримку маршалінгу.

Windows – застосунки, які не обмежують себе використанням тільки сумісних з автоматизацією типів (або не використовують зареєстровану бібліотеку типів), повинні забезпечити для них власний маршалінг.

Операційна система Windows, наприклад, не може стандартними методами передавати між застосунками змінні, що являють собою записи і масиви. У цьому разі для забезпечення маршалінгу необхідно забезпечити реалізацію власного інтерфейсу IMarshal або скористатися окремо створеними proxy/stub DLL. Однак, зауважимо, що Delphi не підтримує автоматичне генерування proxy/stub DLL.

Спеціальні випадки маршалінгу. Delphi підтримує маршалінг типів даних, що описують списки рядків, шрифти і зображення. Це дуже корисне нововведення, оскільки Delphi інтенсивно використовує ці типи в бібліотеці візуальних компонентів VCL. Оголошення наведених типів містяться у файлі stdvcl.pas. У цих файлах наведене оголошення інтерфейсу IStrings. Інтерфейси IFont і IPicture оголошені у файлі activex.pas.

Контрольні запитання та завдання:

1. Опишіть процес створення внутрішнього СОМ-сервера?

2. Опишіть процес створення СОМ-клієнта для внутрішнього сервера?

3. Які дії треба виконати для того, щоб скористатись СОМ-об’єктом у клієнтській програмі?

4. В чому полягає механізм міжпроцесного обміну?

5. Яке призначення маршалінгу?

6. Опишіть особливості маршалінгу різних типів даних?

7. Для чого використовується інтерфейс IMarshal?

8. Яку роль виконують заступник (proxy) та заглушка (stub)?