Компоненти не залежать від мов програмування
Компоненти зберігаються і поширюються у бінарному вигляді і не залежать від мов програмування програмної системи.
Користувач і постачальник компонента можуть використовувати різні мови і бути територіально розподіленими.
1.3. Модель посилань (узагальнена модель компонентної системи)
Компонентна програмна система складається з незалежних компонентів. Узагальнена модель такої системи зображена на рис.1.1.
Рис. 1.1. Узагальнена модель компонентної системи
Компонент (1) – це програмна реалізація (виконуваний код) функцій об'єкту, призначена для виконання. Разом з функціональністю компонент реалізує один або декілька інтерфейсів (2) відповідно до певних зобов'язань, описаних у контракті (3). Контрактні зобов'язання гарантують, що незалежно розроблені компоненти можуть взаємодіяти один з одним і розгортатися в стандартних середовищах (4) (на етапі побудови системи або на етапі її виконання).
Компонентна програмна система ґрунтується на невеликій кількості компонентів різних типів (5), кожний з яких має спеціалізовану роль в системі і описується інтерфейсом (2). Компонентна модель (6) утворена множиною типів компонентів, їх інтерфейсів, а також специфікацією допустимих шаблонів (паттернів) взаємодії типів компонентів. Компонентний каркас (7) забезпечує множину сервісів (8) для підтримки функціонування компонентної моделі. У багатьох відношеннях компонентні каркаси подібні спеціалізованим операційним системам, хоча вони оперують на більш високих рівнях абстракції і мають більш обмежений діапазон механізмів координації взаємодії компонентів.
Найбільш важливий аспект компонентної ідеології побудови – передбачуваність композиції взаємодіючих компонентів і каркасів. Можливі три основні види композицій в програмній системі:
– «компонент-компонент» (взаємодія по контрактах прикладного рівня, яка визначається під час розробки (раннє зв’язування) або під час виконання (пізнє зв’язування);
– «каркас-компонент» (взаємодія між компонентом і іншими компонентами каркаса по контрактах системного рівня із забезпеченням управління ресурсами);
– «каркас-каркас» (взаємодія між компонентами, які розгортаються в гетерогенних середовищах (каркасах) по контрактах інтероперабельного (interoperation) рівня).
Компонент виступає в двох ролях – як реалізація (що розробляється, розгортається і інтегрується в систему) і як архітектурна абстракція (що визначає правила проектування, встановлені стандартною моделлю для всіх компонентів).
Компоненти розробляються у вигляді деякої програмної абстракції, що включає:
інформаційну частину - опис призначення, дати виготовлення, умов застосування (ОС, платформа тощо) та можливостей повторного використання;
зовнішню частину – інтерфейси, які визначають взаємодію компоненту із зовнішнім середовищем і з платформами, на яких він буде працювати, і забезпечують такі загальні характеристики компоненту:
– інтероперабільність – здатність взаємодіяти з компонентами інших середовищ;
– переносність (мобільність) – здатність працювати на різних платформах;
– інтегрованість – здатність до об'єднання з іншими компонентами в складі програмної системи;
– не функціональні характеристики - безпека, надійність і захист компоненту і даних;
внутрішню частину – фрагмент програмного коду або абстрактну структуру - проект компоненту, його специфікацію і початковий код – які реалізують інтерфейси компоненту, його функціональність і схеми розгортання.
Специфікація інтерфейсу може виконуватися засобами API (Application Programming Interface) мови програмування або на мові специфікації інтерфейсу (не залежному від мови програмування) - Interface Definition Language (IDL).
Сучасні мови програмування, наприклад, Java, мають розширення, спеціально призначені для специфікації поведінки: iContract, JML (Java Modeling Language), Jass (Java with assertions), Biscotti, and JINSLA (Java INterface Specification LAnguage).
Таким чином, компонентні системи ґрунтуються на чітко визначених стандартах і угодах для розробників компонентів (встановлених у компонентній моделі) та інфраструктурі компонентів (компонентному каркасі), яка реалізує сервіси для моделі, спрощуючи розгортання окремих компонентів і застосунків.
Компонентна модель пропонує:
- стандарти по типах компонентів (наприклад, проекти, форми, COBRA-компоненти, RMI-компоненти, стандартні класи-оболонки, бази даних, JSP-компоненти, сервлети, XML-документи, DTD-документи і т.п., які визначені у відповідних мовах програмування);
- стандарти схем взаємодії (методи локалізації, протоколи комунікації, необхідні атрибути якості взаємодії – безпека, управління транзакціями тощо);
- угоди про зв’язування компонентів з ресурсами (сервісами, що надаються каркасом або іншим компонентом, розгорненим у цьому каркасі). Модель описує, які ресурси доступні компонентам, як і коли компоненти зв'язуються з цими ресурсами. Каркас, у свою чергу, розглядає компоненти як ресурси, що підлягають управлінню.
Найбільш відомі компонентні моделі - COM (Component Object Model) (DCOM – розподілена компонентна модель, COM+), CORBA, .Net Framework.
1. Component Object Model (COM) – початковий стандарт Microsoft для компонентів. Визначає протокол для конкретизації і використання компонент усередині процесу, між процесами або між комп'ютерами. Основа для ActiveX, OLE і багатьох інших технологій. Може використосуватися в Visual Basic, C++ і ін.
2. Java Beans – стандарт Sun Microsystems для компонентів (тільки для Java).
3. CORBA (стандарт OMG, має громіздкий IDL-інтерфейс, складність відображення однієї мови реалізації в іншу).
4. Dot Net Framework – сучасна компонента модель Microsoft для розробки складних розподілених програмних систем.
Компонентний каркас (подібно операційній системі, об'єкти дії якої - компоненти) керує ресурсами, розподіленими компонентами, і надає механізми для організації взаємодії компонентів. Каркас необов'язково існує окремо від компонентів під час роботи системи, його реалізація може бути об'єднана з реалізацією компоненту, хоча переважно перше, як, наприклад, каркас для підтримки компонентної моделі EJB (Enterprise JavaBeans).
Основна ідея компонентної ідеології - розповсюдження класів в бінарномувигляді (тобто не у вигляді початкового коду) і надання доступу до методів класу через чітко визначені інтерфейси, що дозволяє зняти проблему несумісності компіляторів і забезпечує зміну версій класів без перекомпіляції компонентів.