конспект лекцій (ТСПП). Конспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки
 Скачать 14.87 Mb.
|
Тема 7. CORBA - технологія .План лекції 1.Технологія CORBA. 2.Середовище Delphi. Самостійна робота 3. CORBA технології при програмуванні в середовищі Delphi. 4. Елементи ActiveX, що управляють. Зміст лекції CORBA - це набір специфікацій, що виникає в результаті найширшого обговорення реальних проблем, що накопичилися, в якому беруть участь і розробники і споживачі технологій. В результаті такого обговорення створюється документ, що пропонує вирішення даних питань на рівні існуючих технологій і технологій найближчої перспективи. Гідністю випереджаючої розробки специфікації в порівнянні з реалізацією є можливість для незалежних розробників створювати потенційно сумісні продукти, не обмежуючи свободи вибору мов, ОС, апаратних платформ, і не диктуючи вибору конкретного технологічного рішення. Альтернативні підходи, найбільш яскраво виражені в політику Microsoft і Sun, не відповідають сучасним тенденціям розвитку технологій, згідно з якими диктат одного виробника (хоч би і з самими кращими намірами) загалом, створює більше проблем, чим вирішує. Тут маються на увазі не лише технології. Прикладом цього служить ОС Windows, яка має більше користувачів, чим усі інші разом узяті, і при цьому більшість розглядає цей вибір як вимушений. Будь-який приватний стандарт, підтримуваний окремим виробником (залишаючи збоку питання про його відкритість) вимушений наслідувати лінію розвитку, що історично склалася, що рано чи пізно входить в протиріччя з інтересами споживача. 7.1. Технологія CORBA.Проблема монопольних стандартів полягає у свідомо протекціоністській політиці власника стандарту, що проявляється на інших пов'язаних ринках, у випадку з Microsoft, це ОС. Посилене просування СОМ на платформі Windows робить перенесення цього стандарту на інші платформи економічно невигідним, примушуючи розробника вступати у свідомо програшну конкуренцію з Microsoft. CORBA є концепцією, а не її реалізацією. Коли ми говоримо "COM", то розуміємо під цим швидше набір конкретних засобів - елементів операційної системи, бібліотек, утиліт і тому подібне, що є складовою частиною того, що називається Microsoft Windows. Під терміном "CORBA" розуміється саме складна і розвинена концепція, сформульована на рівні спеціальної мови описів, - IDL. Реалізації ж цієї концепції можуть сильно відрізнятися один від одного за різними критеріями, найбільш важливими в тому або іншому випадку. VisiBroker (розробки Visigenic/Borland/Inprise/Corel) і Application Server, BEA WebLogic, Iona Orbix, Oracle Application Server і "картріджи" Oracle, IBM BOSS - усі ці продукти використовують ті або інші можливості CORBA. Під "стандартом" стосовно CORBA розуміється те, що офіційно затверджене консорціумом OMG. Слід сказати, що це дуже високий рівень "легітимності", оскільки авторитет OMG у комп'ютерному світі надзвичайно високий. OMG є некомерційною організацією, що є співдружністю розробників програмного забезпечення і його споживачів, що об'єднали свої зусилля для створення специфікацій цієї технології. Зараз в OMG полягає більше 800 членів, включаючи усіх скільки-небудь серйозних виробників програмного забезпечення (і навіть c недавнього часу Microsoft). Перша специфікація CORBA з'явилася в 1991 р. Нові можливості офіційно вважаються доданими в CORBA у момент затвердження відповідної специфікації. Як правило, в розробці специфікації беруть участь видатні фахівці в цій області. Розробка реалізації - завдання конкретної фірми. Зазвичай від затвердження специфікації до появи високоякісної реалізації проходить досить багато часу - іноді декілька років. Зараз стандартизовано відображення мови IDL на 6 мов програмування - Ada, C, C++, Cobol, Java і Smalltalk. Існують також відображення на Pascal (точніше, Delphi), Perl, Python і ще декілька мов, але вони не стандартизованы. Об'єкти CORBA можна розглядати як екземпляри (instances) деякого метатипа, причому і метатип, і самі об'єкти існують поза зв'язком з конкретною програмою на конкретній мові. Цей метатип в CORBA називається "інтерфейсом". Інтерфейс На щастя, для новачка у світі CORBA зрозуміти, що ж таке інтерфейс, не складає ніяких труднощів. Інтерфейс в CORBA - це логічно згрупований набір методів і атрибутів. Кожному інтерфейсу привласнюється ім'я, унікальне в межах однієї розподіленої системи. На відміну від СОМ в CORBA немає бінарного стандарту інтерфейсів. Замість цього існує стандартна мова описів IDL. Так вже вийшло, що мови з назвою IDL існують в трьох різних технологіях - OSF/DCE, Microsoft/COM і OMG/CORBA. Ці мови багато в чому схожі, оскільки призначені для одного і того ж, але OMG/IDL дещо відрізняється від своїх "однофамільців". За його основу була узята мова C++ (його описова частина і директиви препроцесора), тому читач, знайомий з C++, при роботі з IDL почуватиме себе цілком комфортно. Ось приклад оголошення інтерфейсів на мові IDL :
Зараз останнім стандартом CORBA є стандарт версії 2.3. У нім поняття "об'єкт" і "інтерфейс" пов'язані, так би мовити, відношенням "один до одного" - один об'єкт не може підтримувати декілька інтерфейсів. У стандарті CORBA 3.0, прийняття якого очікується до кінця 2000 г, повинна з'явитися можливість створення об'єктів, що підтримують декілька інтерфейсів. За допомогою наведеного вище прикладу визначення інтерфейсу (і, природно, певного програмного коду) ви можете, припустимо, створити 5 об'єктів типу MyBaseInterface і 10000 об'єктів MyDerivedInterface. Кожен з цих об'єктів зіставлений зі своїм типом і, окрім цього, має свій унікальний ідентифікатор. Ще раз повторимо - створення вищезгаданих 10005 об'єктів в загальному випадку ніяк не пов'язано з "захопленням" ні ресурсів комп'ютера (в першу чергу пам'яті), ні мережевих ресурсів. Сервант Отже, ви можете створити CORBA -объект і навіть встановити з ним зв'язок. У загальному випадку цього абсолютно недостатньо, щоб використовувати його в конкретній програмі. Функціональність CORBA -объекта недоступна для клієнта до тих пір, поки в програмі (серверному застосуванні) не створений об'єкт, який дозволяє дістати доступ до методів, оголошених в IDL -интерфейсе. Цей об'єкт (реалізований на C++, Java, C, Cobol, Ada, Smalltalk або деяких інших мовах) і називається "сервантом". Звичайно, залежно від використовуваної мови програмування, серванти реалізуються по-різному. Для об'єктно-орієнтованих мов сервант є екземпляром (instance) деякого класу, методи якого реалізують потрібну функціональність. Такий клас часто називають "класом реалізації". За час існування CORBA -объекта з ним може бути зіставлена безліч різних реалізацій сервантів (але не більше за одне за раз). Більше того, вони можуть міститися в адресному просторі різних застосувань. Ці застосування можуть бути навіть запущені на різних комп'ютерах. Часто говорять, що сервант є "інкарнацією" CORBA -объекта. Зв'язок між сервантами і CORBA -объектами є хоча і строго формалізованою, але дуже гнучкою. Сервант може бути створений раніше або пізніше CORBA -объекта; один сервант може "обслуговувати" як один, так і декілька (іноді сотні тисяч і мільйони) CORBA -объектов. Явний розподіл циклів життя CORBA -объектов і їх сервантів (а саме серванти споживають реальні ресурси) - один із стовпів, на яких базується дуже висока масштабованість CORBA -приложений. Об'єктне посилання Єдина складність, пов'язана з розумінням сенсу терміну "об'єктне посилання", полягає в тому, що він використовується в двох різних сенсах. Є об'єктне посилання "світу CORBA", яка є закодованою інформацією про CORBA -объекте. Вона включає ім'я хоста, порту TCP/IP (чи координати Репозитария Реалізацій), звичайно ж, унікальний ідентифікатор цього CORBA -объекта і безліч іншої інформації, що дозволяє клієнтові встановити зв'язок з серверним об'єктом через межі мов програмування, операційних систем і апаратних платформ. Операції з об'єктним посиланням неможливі для клієнта, за винятком того, що клієнт може перетворити її на рядок і записати у файл або базу даних. Згодом хто завгодно може рахувати такий рядок і перетворити його знову в об'єктне посилання. У іншому розумінні "об'єктне посилання" - це змінна тієї або іншої мови програмування, за допомогою якої клієнт здійснює виклик видалених методів. У наступних розділах будуть наведені приклади отримання і використання такого об'єктного посилання. Надалі усі згадки об'єктних посилань відносяться саме до цього, другому, типу об'єктних посилань. Концептуально змінна типу "об'єктне посилання" є покажчиком на так званий "proxy-объект", який існує на стороні клієнта і забезпечує виконання видалених викликів. Сам proxy -объект зроблений недоступним для програміста; пов'язано це з тим, що його створення - завдання не клієнтського застосування, а самого ORB 'а. Логічно з кожним proxy -объектом зіставлена окреме об'єктне посилання, і під копіюванням об'єктного посилання слід розуміти створення як нового proxy -объекта, так і налаштованого на нього нового "покажчика". Зрозуміло, в реальних реалізаціях фізичного копіювання proxy -объекта не відбувається - як завжди в таких випадках, використовується механізм лічильника посилань. Дуже важливо виразно розуміти, що копіювання (чи знищення) об'єктних посилань на стороні клієнта впливає виключно на клієнтське застосування. Неправильне ведення лічильника посилань в самому гіршому випадку приведе до продовження фізичного існування в клієнтському додатку непотрібного proxy -объекта. Ніякого відношення до серверного об'єкту ці дії не можуть мати в принципі. І створення, і знищення сервантів або серверних CORBA -объектов - завдання серверного застосування. Філософія CORBA полягає в тому, щоб клієнт посилав повідомлення "встановити зв'язок з існуючим об'єктом" і "розірвати з ним зв'язок", а не "створити серверний об'єкт" і "знищити його". Зрозуміло, клієнт може ініціювати створення Corba -объектов викликавши у видаленого об'єкту спеціально передбачений для цього програмістом (автором об'єкту) метод. Створення простого об'єкту і його використання Як ні важливе розуміння теоретичних аспектів CORBA, все ж приклад використання у багатьох випадках здатний сказати більше, ніж самі просторові міркування. Як демонстрація етапів створення CORBA -приложения напишемо простий приклад. Сервер створює об'єкт, що реалізовує операцію складання двох цілих чисел. Клієнт встановлює зв'язок з серверним об'єктом, а потім викликає цей його єдиний метод, виводячи результат на екран. У прикладі використовується мова C++. Перший етап створення CORBA -приложения - написання усіх необхідних IDL -деклараций. У нашому випадку IDL -код може виглядати так:
Наступний крок - це генерація файлів на стороні клієнта і сервера за допомогою компілятора idl2cpp. Як вхід компілятор отримує список idl -файлов. У нашому випадку це єдиний файл, що містить наведений вище опис. Для файлу з ім'ям, наприклад, SimpleIDL.idl будуть згенеровані файли SimpleIDL_c.hh, SimpleIDL_c.cpp (для використання на стороні клієнта) і SimpleIDL_s.hh, SimpleIDL_s.cpp (для використання на стороні сервера). Створення серверного застосування Файли _s.* містять код, який дозволяє зв'язати серверне застосування з CORBA. Для нас найбільший інтерес представляє згенерований клас POA_MyInterface. Цей клас містить оголошення чисто віртуальній (абстрактною) функції Summa :
Оскільки клас POA_MyInterface є тільки основою для серверного застосування, його часто називають "скелетом" або навіть "скелетоном" (skeleton). Очевидно, що програмістові необхідно створити похідний від нього клас, в якому функція Summa була б визначена. Це можна зробити, наприклад, так:
Клас реалізацій MyInterfaceImpl часто створюється автоматично, наприклад, за допомогою експертів, що входять до складу Borland C++ Builder або Java Builder. Тепер залишилося написати код функції main() :
Деякі пояснення. Створення серверного об'єкту за допомогою методу _this() застосовується досить рідкісно. Отримуваний таким чином об'єкт має сукупність характеристик, що украй утрудняють його використання. У розділі, присвяченому об'єктним адаптерам, буде розказано, як створювати "нормальні" CORBA -объекты. Результатом виклику методу _this() є об'єктне посилання. Тип MyInterface визначає proxy -объект, MyInterface_ptr (чи MyInterface_var) - покажчик на нього. Це перший вид об'єктного посилання - на рівні додатка. Друге об'єктне посилання - посилання рівня ORB - з'являється в результаті її перетворення до рядка з наступним записом цього рядка у файл. Ви можете ознайомитися з вмістом цього файлу відразу після запуску серверного застосування. Об'єктне посилання записується у файл, звідки її може рахувати додаток-клієнт. Зрозуміло, цей спосіб швидше демонструє принцип організації зв'язку між клієнтом і сервером, чим представляє яку-небудь практичну цінність. Зверніть увагу на те, що одне і теж додаток може бути як клієнтом, так і сервером - CORBA в цьому плані не накладає ніяких обмежень. |