Web-додатки на основі CORBA

Архітектура сучасних інтернет-додатків — це модель з використанням клієнт-серверної архітектури і інтерфейсу CGI. Проте використання CGI-інтерфейсу для об'єктно-орієнтованих клієнтів Java неефективно через те, що цей інтерфейс досить повільний і не володіє необхідної гнучкістю.

Тому спроби деяких фірм-розробників програмного забезпечення серверів оживити CGI, впроваджуючи в нього серверні API, швидше за все є тупиковими.

В даний час одним з перспективних напрямків розвитку інтранет-мереж є використання технології CORBA (Common Object Request Broker Architectur — загальна архітектура з брокером при запиті об'єкта) у поєднанні з Java. CORBA являє собою шину (інтерфейс) розподілених об'єктів з відкритими стандартами, використовувану в клієнт-серверних системах. Ця технологія з’явилася результатом роботи консорціуму OMG (Object Management Group — групи управління об'єктами). Єдиною конкурентної технологією, що володіє аналогічними можливостями, є технологія DCOM (Distributed Component Object Model — розподілена модель компонентних об'єктів), розроблена фірмою Microsoft.

Стандарт CORBA абсолютно не залежить від платформ і операційних систем. Оскільки технологія CORBA добре інтегрована з Java, то ми можемо отримати переваги від спільного використання в архітектурі продуктів Delphi і JBuilder (інтегрованого середовища розробки на мові Java фірми Borland).

Технологія Java передбачає більшу гнучкість при розробці розподілених додатків, але повною мірою не підтримує технологію клієнт-сервер. Інтерфейс CORBA дозволяє забезпечити зв’язок переносите додатків Java і об'єктів CORBA. Технологія об'єктів CORBA призначена для використання в web-додатках замість CGI-інтерфейсу.

В результаті об'єднання Java-аплетів і CORBA-інтерфейсу з’явилося нове поняття — об'єктна модель Web, що означає використання об'єктних моделей різних інтерфейсів (моделі CORBA, ADO та ін) при побудові web-додатків. На першому рівні знаходиться клієнтське додаток — браузер. У ньому виконується клієнтський Java-аплет, з якого може здійснюватися звернення до об'єктів CORBA. На другому рівні варто web-сервер, що обробляє HTTP-запити і CORBA-виклики клієнтських додатків. Третій рівень — це рівень сервера додатків. У його ролі можуть виступати сервери ORB (Object Request Broker — посередник запитів об'єктів) або розподілені об'єкти CORBA, що функціонують як сервери додатків посередником і виконують прикладні функції і набір компонентних сервісів (послуг). Сервери ORB є уніфікованими фрагментами програми, використовуваними в розподілених додатках в якості сполучної ланки між клієнтськими додатками і сервером.

Об'єкти CORBA взаємодіють з серверами БД останнього рівня, використовуючи, наприклад, SQL у разі реляційних БД. Крім того, об'єкти CORBA на сервері можуть взаємодіяти і один з одним. В основі механізму взаємодії між об'єктами CORBA лежить протокол ПОР (Internet Inter-ORB Protocol — інтернет-протокол взаємодії ORB). Протокол ПОР ґрунтується на протоколі TCP/IP з доданими компонентами обміну повідомленнями і функціонує як загальний опорний протокол при організації взаємодії серверів ORB та об'єктів CORBA. На додаток до НІР в технології CORBA використовуються ESIOP-протоколи (Environment-Specific Inter-ORB Protocols — залежні від середовища протоколи взаємодії ORB), які застосовуються в спеціалізованих мережевих середовищах.

Java-клієнт може безпосередньо взаємодіяти з об'єктом CORBA, використовуючи Java ORB. При цьому сервери CORBA заміщають рівень HTTP-сервера і виступають в якості програмного забезпечення проміжного рівня, забезпечуючи взаємодію між об'єктами (object-to-object). Інтерфейс CORBA ПОР функціонує в мережі Інтернет так само, як і протокол HTTP.

Протокол HTTP в цьому випадку використовується для завантаження web-документів, аплетів і графіки, a CORBA — для організації за допомогою Java-аплетів клієнт-серверних додатків.

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

На останньому, четвертому, рівні розміщується сервер баз даних або інше джерело даних, тобто практично будь-яке джерело інформації, до якого CORBA може отримати доступ. Сюди входять монітори процедур транзакцій (ТР Monitors), MOM (Message-Oriented Middleware — проміжне програмне забезпечення, орієнтоване на обмін повідомленнями), ODBMS (об'єктні СУБД), електронна пошта і т. д.

На даний момент інтерфейси CORBA/HTTP підтримуються майже усіма серверними платформами, включаючи UNIX, NT, OS/2, NetWare, MacOS, OS/400.

Розглянемо механізм функціонування web-додатки при використанні технології Java-аплетів і об'єктів CORBA.

Для початку роботи з web-додатком у web-браузер завантажується головна HTML-сторінка, яка містить вбудовані аплети Java. При цьому при відкритті HTML-сторінки Java-аплети і використовувані в аплети Java-класи довантажуються з web-сервера. Запит web-серверу на пошук аплету або необхідного класу формує браузер. web-сервер знаходить аплет і завантажує його в браузер у формі байт-коду.

Об'єднання технологій CORBA, Java та Інтернету забезпечує наступні гідності:

• — Масштабованість і стійкість web-додатки, які полягають в тому, що сервери Web і ORB можуть взаємодіяти з використанням CORBA. При цьому об'єкти CORBA можуть виконуватися на декількох серверах, щоб забезпечити баланс навантаження (load-balancing) серверів для вхідних клієнтських запитів. Брокер ORB може відправити запит першого доступному об'єкту, а також при необхідності збільшити число доступних об'єктів. CORBA дозволяє об'єктам сервера діяти послідовно, використовуючи транзакції та пов’язані сервіси CORBA. На відміну від технології CORBA, інтерфейс CGI при великій кількості запитів не має можливості розподілити навантаження між декількома процесами або процесорами;
• — Гнучкість архітектури CORBA дозволяє клієнтам безпосередньо викликати методи на сервері. Клієнти передають параметри безпосередньо або генерують їх під час виконання аплету;
• — CORBA розширює можливості Java із взаємодії з розподіленими об'єктами. Так, для Java-аплетів не існує простого способу викликати метод на віддаленому об'єкті. CORBA дозволяє Java-аплетів взаємодіяти з іншими об'єктами, написаними на різних мовах, і забезпечує для них багатий набір сервісів розподілених об'єктів (метадані, транзакції, безпека, іменування, колекції і т. д.);
• — CORBA розширює об'єктну модель Java для розподіленого середовища і дозволяє Java-аплетів викликати широкий спектр операцій на сервері. На противагу цьому, клієнти HTTP обмежені невеликим набором операцій. Додатки серверної частини — це звичайні об'єкти CORBA і доступні в будь-який момент часу. Тому немає необхідності проходити через витрати обігу до CGI-сценаріями для кожного дзвінка;
• — CORBA надає кошти для створення архітектури клієнт-сервер. Крім того, технологія CORBA розвантажує код Java-аплетів, певні компоненти можуть бути розподілені в середовищі клієнт-сервер. Клієнтська частина аплету може залишатися маленькою, що скорочує час його завантаження.

Крім CORBA, для розширення можливостей застосування Web можуть використовуватися й інші (конкуруючі) технології: сокети, DCOM з ActiveX і RMI (Remote Method Invocation — механізм виклику віддалених методів) і т. п. Тим не менш, поки технологія CORBA залишається лідером серед всіх інтерфейсів розподілених об'єктів завдяки хорошим архітектурним і функціональним можливостям, стійкості в роботі і легкості в налаштуванні.

Зокрема, технологія CORBA у порівнянні з найближчим її конкурентом — технологією DCOM — забезпечує наступні переваги:

• — повна та коректна реалізація підтримки різних ОС;
• — CORBA реалізована цілком на Java, у зв’язку з чим вона добре інтегрується з Java;
• — легкість конфігурації і налаштування серверів і клієнтів CORBA;
• — коректна реалізація викликів розподілених методів;
• — повнота функціональної реалізації динамічного дослідження та підтримки метаданих;
• — більш висока (більш ніж на 20%) продуктивність додатків;
• — коректна реалізація механізму транзакцій;
• — коректна реалізація довготривалих, або зберігаються, об'єктних посилань;
• — підтримка CORBA-інтерфейсом URL-імен;
• — відкритий стандарт CORBA-інтерфейсу.

Таким чином, CORBA забезпечує інфраструктуру розподілених об'єктів, що дозволяє додаткам поширюватися через мережі, мови, межі компонентів і операційні системи.

У свою чергу, Java забезпечує інфраструктуру переносите об'єктів, які працюють на всіх основних операційних системах.

Тобто CORBA дає незалежність від мереж, a Java — незалежність від реалізації.

У середовищі Delphi 6 для підтримки технології CORBA на сторінці DataSnap Палітри компонентів мається компонент corbaconnection. Створюваний з його допомогою об'єкт типу TCorbaConnection встановлює з'єднання CORBA-клієнта з віддаленим сервером додатка. Названий компонент дозволяє:

• — встановлювати початкове з'єднання з віддаленим сервером додатка;
• — отримувати інтерфейс iAppServer для сервера програми;
• — отримувати список провайдерів на сервері додатка;
• — розривати з'єднання з сервером додатка.

Після встановлення з'єднання набори даних програми клієнта використовують інтерфейс IAppServer компонента з'єднання CORBA для зв’язку з провайдерами на сервері програми або для виклику інтерфейсу модуля даних CORBA серверів додатки.

Крім того, для створення модуля даних CORBA, до якого зможуть отримувати віддалений доступ CORBA-клієнти, можна використовувати Майстер CORBA Data Module. Модуль даних CORBA знаходиться на сервері програми між клієнтом і сервером в середовищі розподіленої бази даних. Виклик Майстри модуля даних CORBA виконується через вибір пункту CORBA Data Module на вкладці Multitier діалогового вікна New Items, що викликається командою File/New/Other.

Майстер CORBA Data Module дозволяє створювати два варіанти примірників модулів даних для клієнтських з'єднань: колективні (Shared Instance) та індивідуальні (Instance-per-client). У першому випадку модуль даних використовується всіма клієнтськими сполуками. У другому випадку один модуль даних створюється на одне клієнтське з'єднання.

Для створюваного модуля даних можна вибрати один з двох варіантів обробки: потоковий (Single-threaded) — кожен екземпляр модуля даних в поточний момент може отримати тільки один клієнтський запит, або поточний (Multithreaded) — кожне клієнтське з'єднання має свій власний потік. У першому випадку вдається уникнути конфлікту запитів, але потрібен захист пам’яті. У другому варіанті модуль даних може отримати декілька клієнтських викликів одночасно, по одному на окремий потік. При цьому глобальна пам’ять і примірник даних повинні бути захищені від конфліктів потоків. Для створення сервера CORBA, до якого зможуть отримувати віддалений доступ CORBA-клієнти, можна використовувати Майстер CORBA Object, виклик якого виконується шляхом вибору пункту CORBA Object на вкладці Multitier діалогового вікна New Items, що викликається командою File/New/Other.

При створенні сервера за допомогою Майстра CORBA Object можна вибрати такі ж варіанти створення екземплярів (Shared Instance і Instance-per-client) і проведення обробки (Single-threaded і Multithreaded), як і при створенні модулів даних за допомогою Майстра CORBA Data Module.

Для організації зв’язку програмних розширень web-сервера з БД використовуються сучасні інтерфейси доступу до даних: OLE DB, ADO і ODBC. Ці інтерфейси є проміжним рівнем між джерелом даних і додатком, в якості якого виступають програмні розширення web-сервера. Розглянемо особливості архітектури web-додатків, що використовують інтерфейси доступу до даних OLE DB, ADO і ODBC.