Принципи CORBA

Специфікація взаємодії об’єктів, розроблена OMG, часто називається, як Object Management Architecture (OMA). OMA визначає два компонента: Модель Ядра Об’єкта(Core Object Model) і Архітектура Посилань OMA (OMA Reference Architecture). Модель Ядра Об’єкта встановлює основну концепцію об’єкта, інтерфейса, операції і т.д.(CORBA є вдосконаленням Core Object Model). Архітектура Посилань OMA визначає інфраструктуру лежачих в основі сервісів і механізма, який дозволяє об’єктам взаємодіяти. Архітектура Посилань OMA включає в себе Object Request Broker (ORB), Object Services (також відомий як CORBA сервіс), і загальні засоби обслуговування.

ORB – це шина взаємодії, за допомогою якої об’єкти можуть виконувати запити на обслуговування до інших об’єктів, не залежно від їх фізичного розміщення. Це значить, що те, що має вигляд виклику методу в клієнтському коді насправді є складною операцією. По-перше, повинно існувати зв’язування з об’єктом сервера, а для цього ORB повинен знати де знаходиться код реалізації сервера. Після встановлення з’єднання повинні передатися по порядку аргументи методу, тобто конвертуватися в бінарний потік і відправитися по сіті. Інша інформація, яка повинна бути відправлена серверу – це ім’я машини, процес сервера і ідентифікатора серверного об’єкту всередині процесу. І нарешті, ця інформація відправляється з використанням протоколу нижнього рівня, інформація декодується на стороні сервера і виконується виклик процедури. ORB ховає всю цю складність від програміста і робить роботу майже такою ж простою, як і виклик методу локального об’єкту.

Немає специфікації про те, як повинно реалізовуватися ядро ORB, але для забезпечення сумісності з різними виробниками ORB, OMG визначає набор сервісів, які доступні через стандартні інтерфейси.

4. Технологія JavaBeen.

Java Bean-компонент є програмним компонентом, що розроблений таким чином, щоб багаторазово використовуватися в різних середовищах. Немає ніяких обмежень на можливості Bean-компонента. Він може виконувати просту функцію(наприклад, перевірку орфографії документу) або складну(наприклад, прогнозування ефективності біржового портфелю). Bean-компонент може бути видимий кінцевому користувачеві(наприклад, як кнопка в графічному інтерфейсі користувача), але може бути також і невидимим для нього. Прикладом будівельного блоку подібного типу є програмне забезпечення для декодування потоку мультимедійної інформації в реальному часі. І на кінець, Bean-компонент може бути розроблений для автономної роботи на робочій станції користувача або для роботи в кооперації з набором інших розподілених компонентів. Прикладом Bean-компонента, який може виконуватись локально, є програмне забезпечення для генерації кругової діаграми з набору елементів даних. Але Bean-компонент, що забезпечує цінову інформацію в реальному часі з фондовою або торговою біржею, повинен працювати в взаємодії з іншими розподіленим програмним забезпеченням(з ціллю отримувати його дані).

Переваги технології Java Beans.

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

· Bean-компонент отримує всі переваги від Java-піраміди «писати – один раз, виконувати – де завгодно».

· Властивості(свойства), події(события) і методи Bean-компонента, які надаються інструменту побудови програми, можуть бути керованими.

· Bean-компонент може бути спроектований для правильної роботи в різних мовних регіонах, що робить його корисним для глобальних ринків.

· Для допомоги в конфігурації Bean-компонента можливе використання допоміжного програмного забезпечення. Це програмне забезпечення необхідне тільки тоді, коли для того компонента установлюються параметри часу розробки. Його не потрібно включати в середовище часу виконання.

· Bean-компонент можна реєструвати, щоб приймати події(события) від інших об’єктів, і він може генерувати події, які відправляються до інших об’єктів.

5. Технологія EJB

Припустимо, що вам потрібно розробити багаторівневу програму для перегляду і оновлення в базі даних через Web інтерфейс. Ви можете написати програму для баз даних, використовуючи JDBC, а Web інтерфейс використовує JSP/сервлети, а розподілена система використовує CORBA/RMI. Але які додаткові міркування ви повинні прийняти до уваги при розробці системи розподілених об’єктів крім вже відомого API? Ось головні міркування:

· Швидкодія: Розподілені об’єкти, які ви створюєте, повинні добре працювати, так як вони потенційно повинні обслуговувати багато клієнтів одночасно. Вам потрібно використовувати оптимізаційні технології, такі як кешування і поєднання таких ресурсів, як поєднання з базою даних. Вам також знадобиться управляти тривалістю життя ваших розподілених об’єктів.

· Маштабувальність: розподілені об’єкти повинні мати здатність маштабування. Маштабувальність в розподілених програмах означає, що число екземплярів ваших розподілених об’єктів може збільшуватись і вони можуть переміщатися на додаткові машини без зміни будь-якого коду.

· Безпека:розподілені об’єкти часто повинні управляти авторизацією доступу клієнта. В ідеалі ви додаєте нових користувачів і політики без перекомпіляції.

· Розподілення транзакції: Розподілені об’єкти повинні бути здатні прозоро посилатися на розподілені транзакції. Наприклад, якщо ви працюєте з двома різними базами даних, ви повинні бути спроможні оновити їх одночасно в одній трансакції і відмінити зміни, якщо не був виконаний певний критерій.

· Доступність: Якщо одна із машин вашої системи вимикається, клієнт повинен автоматично перейти до резервної копії об’єктів, працюючих на іншій машині.

Ці міркування, поряд з проблемами бізнесу, які ви збираєтесь вирішувати, можуть призупинити весь процес розробки. Але всі ці проблеми, за винятком проблем вашого бізнесу, надлишкові – розв’язки повинні бути придумані для кожної розподіленої бізнес-програми.

Sun, поряд з іншими лідируючими виробниками розподілених об’єктів, визначила, що рано або пізно кожна команда розробників знайде звичайні рішення, тому вона створила специфікацію Enterprise JavaBeans (EJB). EJB описує модель компонент сторони сервера, приймаючи до уваги всі згадані вище міркування і стандартні підходи, які дозволяють розробникам створювати бізнес-компоненти, що називаються EJB, які будуть ізольовані від низькорівневого «службового коду», а будуть повністю сфокусовані на забезпеченні бізнес-логіки. Оскільки EJB визначаються стандартним виглядом, то вони можуть бути незалежними від виробника.