2. Технологія rscom від «r-Style Softlab»

Найбільшого розповсюдження отримали компонентна модель компанії Microsoft, побудована на основі COM, і технологія EJB. Але кожна з них має також свої недоліки. Для прикладу, Microsoft всі свої технології орієнтує виключно на операційну систему Windows, а EJB пропонує в якості мови реалізації тільки Java(теоретично можливе написання коду на мові C, але з практичної точки зору – це дуже тяжко зробити).

Розробники «R-Style Softlab» створили власну компонентно розподілену об’єктну модель RSCOM. За своїми можливостями вона знаходиться на одному рівні з COM/DCOM і EJB, але на відміну від них не прагне стати єдиною і загально поглинаючою технологією. Основна її ціль – ефективне обслуговування задач, що виникають в ході експлуатації прикладних комплексів компанії.

Компонентна модель RSCOM надає в розпорядження прикладних програмістів простий і зручний засіб побудови повторно використовуваних модулів. Такими модулями є RSCOM-сервери – основні функціональні елементи моделі, представлені у вигляді DLL. Написані раніше MAC- і DLM- модулі для мови Object RSL доступні в RSCOM в якості повноцінних компонент. Являючись складовою частиною сервера програм «R-Style Softlab», RSCOM функціонує на різних програмно-апаратних платформах.

Що стосується мови програмування, то для створення компонентів RSCOM використовується одна з найбільш відомих – С++. Причому існуючі прикладні бібліотеки змінювати не потрібно, а також і RSL-модулі також використовуються без яких то не було модифікацій. Компоненти RSCOM можна застосувати напряму із мов RSL і С++ як в програмах, що створені спеціалістами «R-Style Softlab», так і в власних розробках клієнтів. А за рахунок модуля спряження з ActiveX вони доступні будь-де, де функціонують ActiveX-компоненти.

Основне призначення RSCOM – організація прозорого віддаленого доступу до прикладних компонентів. З його допомогою клієнтські програми можуть працювати в сіті з прикладними об’єктами на будь-якому сервері програм «R-Style Softlab».

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

RSCOM не потребує від користувачів прикладних систем, розроблених в «R-Style Softlab», придбання якого-небудь додаткових приладів, так і ресурсів комп’ютера можуть бути досить скромними. Все, що необхідно для роботи RSCOM, - установити сервер програм «R-Style Softlab».

3. Технологія corba

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

CORBA дає можливість створення процедури віддаленого виклику Java об’єктів і не Java об’єктів для взаємодії з системою наслідування незалежним від розміщення способом. CORBA реалізує концепцію інтерфейсів і модель посилань на об’єкти.

Принципи 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 визначає набор сервісів, які доступні через стандартні інтерфейси.