Технології компонентного програмування

Київський національний університет ім. Т.Шевченка

факультет кібернетики

 

 

 

 

 

 

Реферат

з курсу інформаційних  технологій

на тему:

«Технології компонентного програмування»

 

 

 

 

Виконала

Студентка 5 курсу

Групи ОМ

Сенчевська Людмила 

Володимирівна

 

 

 

 

 

 

Київ - 2006 
План

 

     Вступ

1. Технологія COM
2. Технологія RSCOM  від «R-Style Softlab»
3. Технологія CORBA
1. Загальні положення
2. Принципи CORBA
4. Технологія JavaBeen
1. Загальні положення
2. Переваги технології Java Beans
5. Технологія EJB
1. Загальні положення
2. JavaBeans проти EJB
3. Специфікація EJB

Список використаної літератури.

 

 

  
Вступ

 

Компонентне програмування  – наступний еволюційний крок на шляху розвитку передових технологій. Воно являє собою логічне продовження  структурного і об’єктно-орієнтованого  програмування. Компонентне програмування зі своєю появою принесло дуже важливі технологічні елементи: єдину оболонку для функціонування об’єктів, уніфікацію способів взаємодії і доступу до можливостей об’єктів. Воно дозволяє будувати програмне забезпечення по принципу конструктора – із незалежних готових компонентів, що набагато ефективніше, ніж створювати з нуля. Для розробки кожного такого «будівельного блоку» програміст може використовувати будь-яку мову програмування. Але найголовніше, що забезпечується прозорий доступ до віддалених об’єктів.

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

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

 

 

 

 

 

1. Технологія COM(Component Object Model)

 

Модель  компонентних об’єктів ( COM ) Microsoft спирається на використання інтерфейсів. Перевагою використання побудованого на інтерфейсах програмного коду є можливість розробки різних компонент-орієнтованих систем, включаючи розподілені компонент-орієнтовані системи.

Щоб краще зрозуміти  суть моделі COM, необхідно розглянути причини, які призвели до її розробки. Модель COM досить довго перебувала на задньому плані тільки через те, що корпорація Microsoft не потурбувалась над тим, щоб пояснити спільноті розробників, що це таке і для чого створено. Більшість розробників помилково прийняли її за обновлену версію OLE, старої технології, основаної на динамічному обміні даними, і створеної для зв’язку і впровадження об’єктів при інтеграції продуктів MS Office. Фактично, модель COM була представлена як OLE2, що мало на увазі лише нову версію старих проблем OLE. Таким чином, пройшло немало часу, перш ніж всі зрозуміли, що модель COM володіє значно більшими можливостями, ніж це розуміється в парадигмі «інтерфейс-орієнтовна розробка компонентних систем». Модель COM дозволяє успішно розв’язувати наступні проблеми:

• Багаторазове використання програмного коду. Порівнюючи із звичайною об’єктно-орієнтованою моделлю, модель COM володіє додатковими перевагами, оскільки дозволяє використовувати не тільки файли вихідного коду, але і бінарні файли відкомпільованого коду.
• Незалежність від мови програмування. Об’єкт сервера COM можна написати на одній мові, а об’єкт клієнта, що використовує його, на іншій. Якщо компілятор мови вихідного коду(або відповідна бібліотека часу виконання) має можливість забезпечити створення об’єктного коду, що відповідає стандарту бінарних файлів COM, то ця мова цілком придатна для розробки компонентів COM.
• Незалежність від компілятора і постачальника. Мається на увазі проблема використання бібліотек DLL, що випускаються різними постачальниками програмного забезпечення, які використовують різні компілятори і різний формат імен. Модель COM абсолютно не чутлива до цієї проблеми. Незалежність від мови, в свою чергу, забезпечує також повну незалежність від компілятора, що використовується кожним конкретним постачальником програмного забезпечення.
• Незалежність від розміщення. Клієнт не зобов’язаний знати, де саме розміщений компонент, що являє собою сервер. Його може містити внутрішній процес бібліотеки DLL, локальний сервер EXE, віддалена бібліотека DLL або віддалений сервер EXE.
• Можливість маштабування. Модель COM допускає установку (розгортку) різноманітних компонентів, що дозволяє сконструювати розподілену систему з конфігурацією, що є найбільш ефективною для кожного конкретного випадку, і нарощувати її можливості, додаючи компонент за компонентом(при необхідності навіть динамічно).
• Контроль версій. Що трапиться при спробі встановити стару версію бібліотеки DLL зверху більш нової? В моделі COM – це не проблема, як і багато іншого.

В класичній багаторівневій архітектурі існує логічне, а часто і фізичне, розділення компонентів клієнтів і компонентів серверів. Як можна помітити, це розподілення дає можливість багаторазового використання відкомпільованого програмного коду, а також високу можливість маштабуваня.

Для вдалої реалізації моделі об’єкта COM необхідно дотримуватися декількох нескладних правил:

• Об’єкти COM повинні підключатися динамічно. Оскільки вимоги користувача можуть змінюватися, або може з’явитися нова версія того ж самого об’єкту COM, користувач повинен мати можливість підключитися до іншого об’єкту COM динамічно, тобто під час виконання програми. Зверніть увагу, що це зовсім не означає, що об’єкти COM повинні розміщуватися саме на серверах DLL.
• Об’єкти COM повинні приховувати, або інкапсулювати подробиці своєї реалізації. Якщо об’єкт COM доводиться замінити іншим, то новий об’єкт COM повинен підключатися точно таким же чином, як і попередній об’єкт COM, а це накладає деякі суттєві обмеження:

• кожний клієнт повинен мати можливість скористатися будь-яким об’єктом COM незалежно від мови програмування, на якій написаний клієнт або об’єкт COM;
• об’єкт COM повинен поставлятися в бінарному(відкомпільованому) вигляді;
• оновлення об’єктів COM не повинно приводити до втрати дієздатності вже існуючих клієнтів. Тобто нові версії об’єктів COM повинні працювати як з новою версією клієнта, так і зі старою.

• Об’єкт COM повинен допускати змінення свого місця знаходження в сітці. Клієнт повинен мати можливість взаємодіяти з віддаленим об’єктом COM тим самим способом, що й з локальним.

 

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

 

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

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

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

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

• Bean-компонент отримує всі переваги від Java-піраміди «писати – один раз, виконувати – де завгодно».
• Властивості(свойства), події(события) і методи Bean-компонента, які надаються інструменту побудови програми, можуть бути керованими.
• Bean-компонент може бути спроектований для правильної роботи в різних мовних регіонах, що робить його корисним для глобальних ринків.
• Для допомоги в конфігурації Bean-компонента можливе використання допоміжного програмного забезпечення. Це програмне забезпечення необхідне тільки тоді, коли для того компонента установлюються параметри часу розробки. Його не потрібно включати в середовище часу виконання.
• Bean-компонент можна реєструвати, щоб приймати події(события) від інших об’єктів, і він може генерувати події, які відправляються до інших об’єктів.