CORBA і IIOP: програмування розподілених систем
Вільям Р. Станек
Підготовка прикладних програм, об'єкти яких складені на різних мовах і взаємодіють між собою на різних ОС і платформах.
Вибухонебезпечне зростання Інтернету і Web став причиною появи технологій, що докорінно змінюють існуючі способи застосування комп'ютерів. Найбільш серйозні зміни відбуваються в об'єктно-орієнтованої технології, якої провидці відводять нову роль в системах розподіленої обробки. Замість традиційних обчислювальних мереж архітектури кліентсервер нова ера розподіленої обробки тягне за собою перехід до систем масштабу підприємства з об'єктами, які розподілені між безліччю комп'ютерів, здатних обмінюватися інформацією незалежно від операційної системи, платформи або мови програмування. Ще більш дивно те, що ці розподілені об'єкти можуть бути компонентами якої однієї програми, або десятків програм, що утворюють систему, призначену для підприємства.
Назвемо технології, що дозволяють здійснювати розподілену обробку в гетерогенних системах: це архітектура брокера загальних об'єктних запитів (Common Object Request Broker Architecture, CORBA) і протокол Internet Inter-ORB Protocol (IIOP). CORBA повністю визначає архітектуру, необхідну для обміну інформацією між розподіленими об'єктами. До числа її специфікацій відносяться IIOP і безліч інших технологій. IIOP найважливіший компонент CORBA, тому що його основна функція організація взаємодії розподілених об'єктів в гетерогенному середовищі. Разом CORBA і IIOP характеризують різноманіття засобів проміжного рівня, які стануть стимулом для перегляду підходів до створення прикладних програм в мережевих середовищах розробниками всього світу.
CORBA і IIOP не тільки варіанти рішення, що забезпечує розподілену обробку. Існує і конкуруюча архітектура, розроблена корпорацією Microsoft, об'єктна модель розподіленої обробки (Distributed Computing Object Model, DCOM), в основному представлена брокером об'єктних запитів (Object Request Broker, ORB), який входить до складу Windows NT 4.0 і буде включений в таку редакцію Windows .
OMG І розподіленої обробки
CORBA дітище консорціуму Object Management Group (OMG), в складі якого понад 700 компаній з найрізноманітніших галузей промисловості. Мета цієї організації полягає в тому, щоб визначати базові структури для розробки додатків з використанням об'єктно-орієнтованих методів. OMG випускає специфікації, що дозволяють стандартизувати обробку розподілених об'єктів, а не прикладні програми, і така орієнтація на розробку ідей, а не програм принесла групі великий успіх.
Із застосуванням CORBA ви створите системи масштабу підприємства (корпоративні системи), в яких об'єкти розподілені по обчислювальної мережі. У корпоративних системах основні об'єкти для обслуговування файлів, необхідні прикладній програмі, можуть зберігатися на сервері Windows NT. Ці об'єкти ви складете, наприклад, на мові Сі ++. На великому комп'ютері можна розмістити первинні функції ядра системи скажімо, використовуючи об'єкти, запрограмовані на мові Кобол. Будь настільний комп'ютер, що працює під управлінням Windows 95, придатний для зберігання зовнішніх інтерфейсів, які використовують об'єкти, створені засобами Visual Basic. І всі ці об'єкти можуть обмінюватися інформацією, а посередником при передачі запитів служить CORBA.
Фірми Netscape Communications Corp. і Sun Microsystems обрали CORBA і IIOP в якості основи для наступного покоління своїх програм. Sun застосовує CORBA і IIOP для реалізації гетерогенних викликів віддалених процедур в мові програмування Java 1.1, причому без цих технологій в копоратівних мережах не було б платформи Java (Java Platform). Більш того, в API Enterprise JavaBeans будуть застосовуватися CORBA і IIOP, щоб забезпечити можливість створення масштабованих прикладних програм для ділової сфери (бізнес-додатки) з повторного використання серверними компонентами.
Для огранізації викликів віддалених процедур в мові Java придатна і технологія DCOM. Необхідні для цього спеціальні програмні процедури є в Visual J ++. Але модель DCOM розрахована тільки на платформи Windows NT 4.0 і Windows 95 (за допомогою розширень Internet Explorer), т. Е. DCOM не годиться для обміну інформацією з іншими операційними системами. Microsoft повідомляє, що в майбутньому технологія DCOM буде перенесена на інші платформи.
ДЕЩО ПРО CORBA
Ядро CORBA брокер (посередник) об'єктних запитів (ORB). Це щось на зразок магістралі для об'єктів. Основне завдання ORB надавати посередницькі послуги при обміні запитами між об'єктами. Хоча ORB "мешкає" в середовищі кліентсервер, об'єкти, з якими він працює, виконують функції або клієнтів, або серверів, в залежності від обставин. Якщо об'єкт приймає і обробляє запит, то він грає роль сервера. Якщо він відправляє запит, то виступає в ролі клієнта.
Основне завдання ORB прийом і відправка запитів, а також передача результатів, в тому числі перехоплення кожного запиту одного об'єкта іншому; визначення місцезнаходження об'єкта, який, імовірно, обробить запит; запуск відповідного методу приймає об'єкта; при необхідності передача параметрів і передача результатів об'єкту, який ініціював запит. Оскільки ORB обробляє запити "прозоро", неважливо, від якого об'єкта локального або віддаленого надійшов запит.
Мова IDL хороший тим, що дозволяє коротко описати API, зберігши при цьому свободу визначити методи на будь-якій мові програмування, який забезпечує зв'язування з CORBA. До таких мов відносяться Ада, Кобол, Сі, Сі ++, Smalltalk і Java. У деяких постачальників є власні кошти узгодження з CORBA для Visual Basic і Фортрана.
Як відомо будь-якій людині, яка мала справу з об'єктно-орієнтованим програмуванням, для складання запиту необхідні відомості про інтерфейс приймає об'єкта, а об'єкти повинні бути розроблені так, щоб вони могли отримувати інформацію про інтерфейси тих об'єктів, з якими вони будуть взаємодіяти. Але, намагаючись застосувати цей підхід для розподіленої між гетерогенними об'єктами обробки, ви зіткнетеся з безліччю проблем.
Для справжньої незалежності IDL в CORBA використовується репозиторій (сховище) інтерфейсів, призначений для зберігання сигнатур методів, що належать об'єктам, з тим щоб ці сигнатури можна було динамічно отримувати і оновлювати під час виконання програми. Завдяки цьому всі об'єкти в корпоративній системі можуть отримати інформацію про інтерфейси інших об'єктів, методах, що належать цим інтерфейсів, і параметрах, необхідних для звернення до них. (В DCOM теж передбачені служби реєстру і пошуку, що дозволяють клієнтам отримати інформацію про інтерфейси компонента, а також про параметри, необхідних для виклику конкретного методу.)
Поєднання ORB, IDL і сховища інтерфейсів це і є базова модель CORBA (малюнок). Хоча в наведеній на малюнку моделі позначені не всі компоненти архітектури, вона дає уявлення про те, як за допомогою CORBA гетерогенні об'єкти взаємодіють між собою.
ОБ'ЄДНАННЯ КОМПОНЕНТІВ
Як технологія, яка забезпечує базові структури для взаємодії різнорідних об'єктів, CORBA досягла чудових успіхів, і це при тому, що вона являє собою лише частина ще більшої архітектури управління об'єктами (Object Management Architecture, OMA), що складається з наступних компонентів:
- CORBA ORB оперує запитами між об'єктами;
- Служби (сервіси) CORBA визначають службові функції системного рівня, призначені для управління об'єктами і забезпечення їх роботи;
- Засоби CORBA визначають функціональні можливості і інтерфейси на рівні прикладної програми;
- Об'єкти прикладних програм власне об'єкти.
Як ми вже згадували, брокер об'єктних запитів управляє обміном запитами між об'єктами. Але як всі інші шматочки цієї мозаїки складаються воєдино? Давайте розглянемо служби, кошти і об'єкти CORBA.
СЛУЖБИ ОБ'ЄКТІВ CORBA
Допомога в організації управління і забезпечення працездатності об'єктів на протязі їх життєвих циклів саме цим зайняті служби CORBA. Інтерфейси цих служб знадобляться вам для створення об'єктів забезпечення їх безпеки, визначення місця розташування об'єктів та управління об'єктами на рівні класів. Оскільки це служби системного, а не прикладного рівня, їх можна реалізувати для всього підприємства, т. Е. Заощадити свій час і полегшити узгодженість в масштабах підприємства.
Є 16 об'єктних служб, в тому числі:
Завдяки тому що служби об'єктів CORBA вирішують широкий спектр завдань, розробники можуть концентрувати увагу на підготовці об'єктів, не піклуючись про службах системного рівня. Розробивши клас для свого об'єкта, ви потім розширите його функціональні можливості за допомогою служб об'єктів. Домогтися цього вам допоможуть механізми ділення на підкласи (subclassing) і множинного спадкоємства. Наприклад, після створення класу Widget ви можете вивести з нього підклас aWidget, який успадкує від служби Persistence стійкість. Крім того, ви забезпечите передачу повідомлень про настання подій, безпеку і виконання запитів, застосовуючи механізм успадкування до цих функцій відповідних служб.
Можливості ділення на підкласи і множинного спадкоємства CORBA розширені за рахунок увійшли в цю специфікацію метаклассом. Метаклассом це клас об'єктів, який формується під час виконання програми. За допомогою метаклассом можна динамічно додавати до функцій об'єктів CORBA сервісні функції, т. Е. При необхідності налаштовувати об'єкти.
ЗАСОБИ ОБ'ЄКТІВ CORBA
Інтерфейси прикладних програм складаються з нестандартизованих засобів, специфічних для конкретних додатків, таких, як система резервування або управління збереженими на складі матеріалами. До інтерфейсів доменів відносяться кошти, призначені для кінцевих користувачів в певних доменах додатків. (В даному випадку домен означає конкретний вертикальний сегмент ринку або галузь промисловості.)
Інтерфейси доменів розраховані на конкретні сегменти ринку, тоді як кошти Інтернету це функції рівня прикладних програм і інтерфейси, орієнтовані на широкий ринок. У число засобів Інтернету входять, наприклад, кошти для вирішення стандартних користувальницьких завдань в рамках прикладних програм, скажімо друк або збереження файлу, а також рядових завдань по роботі з мережею, таких, як використання електронної пошти або втратити зв'язок із мережею.
ОБ'ЄКТИ ПРИКЛАДНИХ ПРОГРАМ
Реальні об'єкти, що утворюють ядро сумісної з CORBA прикладної програми, називаються бізнес-об'єктами. Бізнес-об'єкт це спосіб опису понять, що не залежать від прикладної програми, типу покупець, замовлення або платіж. Для підготовки прикладної програми вам буде необхідний набір бізнес-об'єктів.
На відміну від об'єктів системного рівня, які виконують такі завдання, як для підтримки стійкості, бізнес-об'єкти мають справу з процесами, характерними для реального ділового світу. Хоча типовий бізнес-об'єкт несе відповідальність тільки за одну задачу (наприклад, обробку попередніх замовлень, роботу з покупцями або складом), набори бізнес-об'єктів можна застосовувати для управління всім бізнес-процесом, таким, як продаж квитків і обробка попередніх замовлень на авіарейси. Оскільки бізнес-об'єкти поставляються в готовому до роботи вигляді, розробник може, об'єднавши їх, скласти прикладну програму, що відповідає вимогам замовника.
Для управління складною прикладною програмою з розподіленими бізнес-об'єктами у останніх є інформація тільки про те, які сервісні функції виконують інші об'єкти, але не про те, як ці функції реалізуються насправді. Завдяки бізнес-об'єктів ми позбавлені складнощів реалізації внутрішньої обробки, оскільки можемо сконцентрувати увагу на інтерфейсах.
ПРОГРАМУВАННЯ ДЛЯ розподілених середовищ
Компонент це набір бізнес-об'єктів, які здійснюють обробку, інкапсулюють дані і забезпечують необхідні інтерфейси користувача. Для взаємодії об'єктів в рамках компонента використовується ORB. Крім того, за допомогою ORB об'єкти обмінюються інформацією про себе, в результаті об'єкти "дізнаються" про існування інших об'єктів під час виконання програми. Таким чином, в компоненті є все необхідне для виведення на екран представлення об'єкту і взаємодії з ним. Типовий бізнес-компонент міг би застосовуватися, скажімо, для виведення на екран розподілу місць на 11-годинному рейсі до Лос-Анджелеса, а інший для реєстрації відомостей про бронювання місць на цей рейс.
Можливості компонентів можна розширити за рахунок додавання службових функцій системного рівня. Функція Persistence знадобиться, щоб підтримувати стан об'єктів в рамках компоненту. Крім того, керуючі функції Concurrency і Transactions забезпечать цілісність об'єктів в рамках компоненту. Оскільки ці сервісні функції вбудовані в CORBA, їх можна застосовувати для створення "інтелектуальних" (smart) компонентів, при цьому немає необхідності програмувати їх з нуля. Хоча і в DCOM є реєстр компонентів і довідкова служба, там немає способу підтримувати стан об'єктів DCOM в перерві між сполуками. Через цього недоліку DCOM поступається CORBA.
На рівні прикладної програми, де встановлюються межі інфраструктури компонентів, базові структури програм визначають способи реалізації спільної діяльності незалежних компонентів. Завдяки чітко визначеним кордонів все компоненти разом функціонують як єдиний комплекс, так що створюється враження єдності прикладної програми. Саме така єдність дає змогу прикладним програмам, які використовують розподілені в гетерогенних середовищах об'єкти, "прозоро" сполучатися один з одним. "Прозора" інтеграція означає, що користувачі сприймають прикладну програму як єдине ціле, а не як складний набір роз'єднаних модулів.
Інфраструктуру компонента однієї прикладної програми можна розширити до інфраструктури компонента декількох програм. В цьому випадку CORBA несе відповідальність за обмін інформацією між безліччю різних прикладних програм в рамках корпоративної системи. Для несумісних з CORBA програм, наприклад дісталися в спадок додатків, можна створити оболонки (wrappers), які надають їм подобу об'єктів CORBA. Оболонка виконує роль інтерфейсу, необхідного для доступу до конкретних функцій старої програми.
Якщо ви за допомогою CORBA інтегрували успадковані програми з процесами клієнта і сервера, у вас є всі складові багаторівневої моделі кліентсервер. Один рівень це візуальні об'єкти, наприклад інтерфейси, що розміщуються на клієнтських ПК. Інший рівень об'єкти сервера, що передбачають бізнес-функції. Ще один рівень складають успадковані прикладні програми, наприклад СУБД на великий ЕОМ.
І В ЗАКЛЮЕНІЕ
З огляду на, що в стоїть за цією специфікацією консорціум входять більш як 700 компаній, CORBA щось більше, ніж повальне захоплення, яке охопило ринок. CORBA перевершує традиційну трирівневу модель кліентсервер завдяки тому, що це повністю масштабована і виключно гнучка архітектура. Використовуючи CORBA, ви з легкістю розширите мережу, що складається з трьох комп'ютерів до мережі масштабів Інтернету. CORBA забезпечує базову структуру, що дозволяє з'єднувати об'єкти, запрограмовані на різних мовах, причому не має значення, для якої платформи або операційної системи ці об'єкти були створені, якщо є кошти узгодження з CORBA. Оскільки CORBA призначена для гетерогенних платформ, в даний час у неї є переваги перед DCOM. Однак беручи до уваги міць Microsoft, DCOM, безсумнівно, в найближчому майбутньому стане силою, з якою доведеться рахуватися.