Мова опису інтерфейсів і бібліотека типів

Тепер звернемося до питань про мовну незалежність і прозорість місця розташування. Як вже раніше згадувалося, це принципові для COM вимоги.

Перше означає, що як компоненти, так і клієнти, що використовують їх, можуть реалізовуватися на будь-кому підтримувальному COM мові програмування (зокрема, C++ і Visual Basic). Проте описані раніше інтерфейси (файли IPub.h, IBook.h і IJournal.h) представлені на C++. Це означає, що будь-який розробник, що бажає реалізувати ці інтерфейси у своєму коклассе повинний використовувати саме C++. неприємніше, що і будь-який клієнт, що бажає використовувати побудовані таким чином компоненти, також має бути написань на C++.

Прозорість місця розташування означає, що код клієнта не повинний мінятися поклад від того, де розміщений використовуваний клієнтом компонент (або це dll, що завантажується в адресний простір клієнта, або це exe -сервер, що виконується в іншому процесі на тій же машині, де виконується клієнт, або компонент встановлений на видаленому комп' ютері). Звичайно, клієнт може явно вказати, який тип сервера він бажає використовувати, але він може залишити вибір за системою, і тоді буде використовуватися тій сервер, зв'язок з яким для цього клієнта буде найбільш швидким. У разі виконання сервера і клієнта в різних процесах необхідно забезпечити передачу даних між цими процесами. Прозорість місця розташування означає що COM бере це на собі.

Що потрібне для забезпечення незалежності від мови і прозорості місця розташування? Треба описати усі інтерфейси і класи деяким стандартним чином, зробивши ці описи доступними компіляторам з усіх мов, підтримувальних COM. Це і забезпечить мовну незалежність. Для забезпечення прозорості місця розташування треба мати можливість автоматичний формувати посередників, що забезпечують взаємодію клієнта і сервера, що виконуються в різних процесах. У COM такий посередник на стороні клієнта називається проксі, а посередник на стороні сервера називається заглушкою. Сморід реалізуються у вигляді компонент, що завантажуються в адресні простори клієнта і сервера і забезпечують для останніх ілюзію безпосередньої взаємодії один з одним (у одному адресному просторі). Насправді проксі і заглушка реалізують видалений виклик процедур, використовуючи протокол LRPC або RPC відповідно при розташуванні на одній або різних машинах.

Отже, C++ не годитися для опису інтерфейсів у зв'язку з тим, що в цій мові багато неоднозначностей, які, звичайно успішно дозволяються компілятором з C++, але в яких не зможуть розібратися компілятори з інших мов. Потрібний спеціальна мова, на якій можна однозначно описати усі інтерфейси і класи. Це мова опису інтерфейсів IDL - Interface Definition Language, спочатку описів в специфікації DCE (Distributed Computing Environment - розподілене середовище обчислень) від Open Software Foundation і далі розширений Microsoft. На нім описуються усі коклассы і усі інтерфейси, що реалізовуються в них, які входитимуть в створюваний компонент. При цьому немає необхідності описувати раніше описані інтерфейси (наприклад, стандартні). Досить включити їх опису за допомогою ключового слова import. Разом з описом коклассов і інтерфейсів потрібно описати так звану бібліотеку типів. Саме ця бібліотека і вирішуватиме проблему мовної незалежності. Вона в бінарному виді зберігатиме інформацію про усіх інтерфейсах і класах цього компонента у формі, доступній для читання компіляторами з усіх підтримувальних COM мов.

Далі idl -файл з описом інтерфейсів, класів і бібліотеки типів транслюється транслятором MILD (Microsoft IDL) в сукупність файлів, що утримують оголошення на C++/C усіх інтерфейсів, визначення GUID для усіх інтерфейсів і класів коди проксі і заглушки, а також формується в бінарному виді бібліотека типів. Використовуючи ці файли можна побудувати dll проксі і заглушки. При реалізації клієнта або сервера на C++/C можна використовувати отримані файли з описами інтерфейсів і визначеннями GUID, при використанні інших мов програмування, використовуватиметься бібліотека типів.

Далі приведень файл PubInProcServerTypeInfo.idl, що дає описи на IDL інтерфейсів, класів і бібліотеки типів для

проекту PubInProcServer.

import "oaidl.idl";

////////IPub

[object

uuid(9A5DE9A0-7225-11d5-98C7-000001223694)

helpstring("Base publication")]

interface IPub: IUnknown

{

HRESULT SetTitle([in] BSTR bstrTitle);

HRESULT SetYear([in] int nYear);

HRESULT GetInfo([out, retval] BSTR* pbstrInfo);

};

////////IBook

[object

uuid(9A5DE9A1-7225-11d5-98C7-000001223694)

helpstring("Book")]

interface IBook: IPub

{

HRESULT SetAuthor([in] BSTR bstrAuthor);

}

////////IJournal

[object

uuid(9A5DE9A2-7225-11d5-98C7-000001223694)

helpstring("Journal")]

interface IJournal: IPub

{

HRESULT SetNumber([in] int nNumber);

}

[uuid(68A702C2-8283-11d5-98C7-000001223694)

version(1.0)

helpstring("PubInProcServer with TypeLib")]

library PubInProcServer

{

importlib("stdole 32.tlb");

[uuid(49F00760-7238-11d5-98C7-000001223694)]

coclass CoBook

{

[default] interface IBook;

};

[uuid(49F00761-7238-11d5-98C7-000001223694)]

coclass CoJournal

{

[default] interface IJournal;

};__

};

Видно, що цей файл дуже схожий на заголовний файл в C++. Основна відмінність - наявність атрибутів в квадратних дужках.

Конструкція import "oaidl.idl"; забезпечує імпорт ряду стандартних описів (у тому числі, інтерфейсу IUnknown). Далі йдуть опису усіх призначених для користувача інтерфейсів, що реалізовуються в компоненті,: IPub, IBook і IJournal.

Опису шкірного інтерфейсу передує сукупність атрибутів, що починається з атрибуту object. Саме цей атрибут говорити про ті, що далі йде опис інтерфейсу COM, а не інтерфейсу RPC, для описів яких і створювався спочатку IDL.

Атрибут uuid використовується для завдання GUID відповідного інтерфейсу.

Атрибут helpstring дозволяє приписати описуваному інтерфейсу деякий рядок, який зберігатиметься в бібліотеці типів і може використовуватися різними програмами для уявлення користувачеві інформації про семантику даного інтерфейсу.

При описі методів інтерфейсів використовуються атрибути in, out, retval, що дозволяють вказати напрям передачі значення параметра. Атрибут in призначається за умовчанням і означає, що значення цього параметра передається серверу.

Навпаки, атрибут out говорити про необхідність передачі значення параметра клієнтові. Атрибут retval означає, що для цей параметр є повертаним значенням для відповідної функції при використанні, наприклад, Visual Basic.

Вказівка цих атрибутів (можливі їх поєднання) оптимізує трафік в мережі при виконанні видаленого виклику процедур.

Після опису усіх інтерфейсів описується бібліотека типів (ключове слово library). Як атрибути для бібліотеки типів задаються унікальний ідентифікатор (GUID, який можна отримати за допомогою guidgen.exe), номер версії і helpstring.

Оператор importlib("stdole 32.tlb") має бути деремо серед усіх операторів бібліотеки. Він задає імпорт стандартній двійкової бібліотеки типів stdole32.tlb.

Дата добавления: 2014-01-04