Метакласи

Успадкування

Спадкування є важливим випадком відносин між двома або більше класами. Докладно вона розглядалася вище.

Отже, будь-який об'єкт має структуру, що складається з полів і методів. Об'єкти, що мають однакову структуру і семантику, описуються одним класом, який і є, по суті, визначенням структури об'єктів, породжених від нього.

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

Щоб уявити собі, що таке метакласи, розглянемо приклад якоїсь бюрократичної організації. Будемо вважати, що всі класи в такій системі мають суворі інструкції, які описують, що потрібно зробити, щоб породити новий об'єкт (наприклад, найняти нового службовця або відкрити новий відділ). Як і годиться класам, вони описують всі властивості нових об'єктів (наприклад, зарплату і професійний рівень для співробітників, площа та майно для відділів) та їх поведінка (обов'язки службовців і функції підрозділів).

У свою чергу, написання нової інструкції можна строго регламентувати. Скажімо, необхідно використовувати спеціальний бланк, дотримуватися правил оформлення і заповнити всі обов'язкові поля (наприклад, номер інструкції та прізвища відповідальних працівників). Така "інструкція інструкцій" і буде представляти собою метаклас в ООП.

Отже, об'єкти породжуються від класів, а класи - від метаклассов. Він, як правило, в системі тільки один. Але існують мови програмування, в яких можна створювати і використовувати власні метакласи, наприклад мова Python. Зокрема, функціональність метаклассов може бути наступна: при формуванні класу він буде переглядати список усіх методів в класі і, якщо ім'я методу має вид set_XXX або get_XXX, автоматично створювати поле з ім'ям XXX, якщо такого не існує.

Оскільки метаклас сам є класом, то немає ніякого сенсу у створенні "мета-мета-класів".

У мові Java також є метакласи. Це клас, який так і називається - Class (описує класи), він розташовується в основний бібліотеці java.lang. Віртуальна машина використовує його за прямим призначенням. Коли завантажується черговий. Class-файл, що містить опис нового класу, JVM породжує об'єкт класу Class, який буде зберігати його структуру. Таким чином, Java використовує концепцію метаклассов в самих практичних цілях. За допомогою Class реалізована підтримка статичних (static) полів і методів. Нарешті, цей клас містить ряд методів, корисних для розробників.

Лекція 13. Шаблони проектування в ООП.

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

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

В таких ситуаціях програмісти-початківці можуть легко розгубитися серед великої кількості можливих варіантів вирішення задачі. Нерідко проходить дуже багато часу, перш ніж їм вдасться створити по справжньому працездатний дизайн підсистеми. Досвідченішим же розробникам швидше вдається створити хорошу логічну структуру системи без необхідності її перепроектування. Очевидно, що досвідченим проектувальникам відомі деякі тонкощі, про які не знають початківці. В чому ж вони полягають?

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

Шаблон проектування — опис взаємодії об’єктів та класів, адаптований для вирішення узагальненої задачі проектування в конкретному контексті. Як правило, це певна формалізована логічна одиниця підсистеми, яка напряму перетворюється в програмний код.

Основні елементи шаблону проектування:

1. Назва. Вказавши ім’я шаблону, можна відразу описати проблему проектування, її рішення та наслідки. Присвоювання імен шаблонам дозволяє проектувати систему на більш високому рівні абстракції. За допомогою такого «словника шаблонів» можна вести дискусії з колегами, згадувати про шаблони в розробницькій документації, в деталях розуміти дизайн системи.

2. Завдання. Опис ситуації, в якій потрібно застосовувати шаблон. Необхідно сформулювати задачу та її контекст. Може описуватися конкретна проблема проектування, також може бути включено перелік умов, за яких є зміст використовувати цей шаблон.

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

4. Результати. Це наслідки застосування шаблону, а також різного роду компроміси. Хоча при описі шаблонів про наслідки зазвичай не згадують, однак знати це необхідно для того, щоб можна було вибирати між різними варіантами шаблонів, і оцінити переваги та недоліки даного шаблону. Також немалу роль тут грає і мова програмування, оскільки часто вибір того чи іншого шаблону залежить від можливостей, які надає конкретна мова реалізації проекту.

Існує три види шаблонів проектування:

1. Породжуючі шаблони. Допомагають абстрагувати процес створення (інстанціювання) об’єктів. Вони дозволяють зробити систему незалежною від способу створення, композиції та представлення об’єктів. Ці шаблони найбільш важливі, коли система більше залежить від композиції об’єктів, ніж від наслідування класів.

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

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

Шаблон «Абстрактна фабрика» (Abstract Factory)

Назва та класифікація

Абстрактна фабрика — шаблон, що породжує об’єкти.

Призначення

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

Інші назви

Інструментарій (Kit).

Підстави для застосування

1. Система не повинна залежати від того, як створюються, компонуються та представляються об’єкти, що в неї входять.

2. Взаємопов’язані об’єкти повинні використовуватися разом і потрібно це обмеження забезпечити.

3. Система повинна конфігуруватися одним із сімейств об’єктів, що входять в неї.

4. Потрібно створити бібліотеку об’єктів, розкриваючи тільки їхні інтерфейси, але не реалізацію.

Структура

Учасники

1. AbstractFactory — абстрактна фабрика:

- описує інтерфейс для операцій, що створюють абстрактні об’єкти-продукти.

2. ConcreteFactory — конкретна фабрика:

- реалізує операції, що створюють абстрактні об’єкти-продукти.

3. AbstractProduct — абстрактний продукт:

- описує інтерфейс для типу об’єкта-продукту.

4. ConcreteProduct —конкретний продукт:

- визначає об’єкт-продукт, створюваний відповідною абстрактною фабрикою;

- реалізує інтерфейс AbstractProduct.

5. Client — клієнт:

- користується виключно інтерфейсами, які описані в класах AbstractFactory та AbstractProduct.

Відношення

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

2. AbstractFactory делегує створення об’єктів-продуктів своєму підкласу ConcreteFactory.

Результати

1. (+) Ізолює конкретні класи.

2. (+) Спрощує заміну сімейств продуктів.

3. (+) Гарантує сумісність продуктів.

4. (–) Складно підтримати новий вид продуктів.

Шаблон «Будівельник» (Builder)

Назва та класифікація

Будівельник — шаблон, що породжує об’єкти.

Призначення

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

Підстави для застосування

1. Алгоритм створення складного об’єкта не повинен залежати від того, із яких частин складається об’єкт, і як ці частини між собою організовані.

2. Процес конструювання повинен забезпечувати різноманітні представлення об’єкта, що конструюється.

Структура

Учасники

1. Builder — абстрактний будівельник:

- задає абстрактний інтерфейс для створення частин об’єкта Product.

2. ConcreteBuilder — конкретний будівельник:

- конструює та збирає разом частини продукту (шляхом реалізації інтерфейсу Builder);

- визначає створюване представлення та слідкує за ним;

- надає інтерфейс для доступу до продукту.

3. Director — розпорядник:

- конструює об’єкт, користуючись інтерфейсом Builder.

4. Product — продукт:

- представляє складний об’єкт. ConcreteBuilder будує внутрішнє представлення продукту та визначає процес його збірки;

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

Відношення

1. Клієнт створює об’єкт-розпорядник Director та конфігурує його потрібним об’єктом-будівельником Builder.

2. Розпорядник повідомляє будівельника про те, що потрібно побудувати наступну частину продукту.

3. Будівельник обробляє запити розпорядника і додає нові частини до продукту.

4. Клієнт забирає продукт в будівельника.

Загальна схема дій виглядає таким чином:

Результати

1. (+) Дозволяє змінювати внутрішнє представлення продукту.

2. (+) Ізолює код, який реалізує конструювання та представлення.

3. (+) Дає більш тонкий контроль над процесом конструювання.

Шаблон «Фабричний метод» (Factory Method)

Назва та класифікація

Фабричний метод — шаблон, що породжує класи.

Призначення

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

Інші назви

Віртуальний конструктор (Virtual Constructor).

Підстави для застосування

1. Класові наперед невідомо, об’єкти яких класів йому потрібно створювати.

2. Клас спроектовано так, щоб об’єкти, які він створює, специфікувались підкласами.

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

Структура

Учасники

1. Product — продукт:

- визначає інтерфейс об’єктів, створюваних фабричним методом.

2. ConcreteProduct — конкретний продукт:

- реалізує інтерфейс Product.

3. Creator — творець.

- оголошує фабричний метод, що повертає об’єкт типу Product;

- може викликати фабричний метод для створення об’єкту Product.

4. ConcreteCreator — конкретний творець:

- заміщує фабричний метод, що повертає об’єкт ConcreteProduct.

Відношення

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

Результати

1. (+) Надає підкласам можливість виконання операцій-зачіпок (hooks).

2. (+) З’єднує паралельні ієрархії класів.

Шаблон «Прототип» (Prototype)

Назва та класифікація

Прототип — шаблон, що породжує об’єкти.

Призначення

Задає види створюваних об’єктів за допомогою екземпляра-прототипу і створює нові об’єкти шляхом копіювання цього прототипу.

Підстави для застосування

1. Інстанційовані класи визначаються під час виконання, наприклад, за допомогою динамічного завантаження.

2. Щоб запобігти побудови ієрархій класів чи фабрик, паралельних до ієрархії класів продуктів.

3. Екземпляри класів можуть знаходитися в одному зі станів, причому множина можливих станів є не дуже великою. Може бути зручніше встановити відповідну кількість прототипів та клонувати їх, а не створювати об’єкт кожного разу в потрібному стані.

Структура

Загальна структура шаблону:

Приклад (візуальний редактор нотного стану):

Учасники

1. Prototype — прототип:

- визначає інтерфейс для клонування самого себе.

2. ConcretePrototype — конкретний прототип:

- реалізує операцію клонування самого себе.

3. Client — клієнт:

- створює новий об’єкт, звертаючись до прототипу з запитом клонувати себе.

Відношення

Клієнт звертається до прототипу, щоб він створив копію самого себе.

Результати

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

1. (+) Додавання та видалення типів продуктів під час виконання.

2. (+) Специфікація нових об’єктів шляхом зміни властивостей, а не опису нових класів.

3. (+) Специфікація нових об’єктів шляхом зміни структури.

4. (+) Зменшення кількості підкласів.

5. (+) Динамічна конфігурація програми за допомогою класів.

6. (–) Інколи дуже складно реалізувати операцію клонування об’єкта.

7. (–) Реалізація ускладнюється, коли прототипи потрібно не тільки клонувати, а й ініціалізувати стан клонів певними особливими значеннями.

Шаблон «Одинак» (Singleton)

Назва та класифікація

Одинак — шаблон, що породжує об’єкти.

Призначення

Гарантує, що існує тільки один екземпляр певного класу, і надає до нього глобальну точку доступу.

Підстави для застосування

1. Повинен бути рівно один екземпляр деякого класу, легко доступний для всіх клієнтів.

2. Єдиний екземпляр може розширюватися шляхом породження підкласів, і клієнтам потрібно мати можливість працювати з розширеним екземпляром без модифікації коду.

Структура

Учасники

1. Singleton — одинак.

- Визначає операцію Instance, яка дозволяє клієнтам отримувати доступ до єдиного екземпляру.

- Може нести відповідальність за створення власного унікального екземпляру.

Відношення

Клієнти отримують доступ до екземпляру класу Singleton тільки через його операцію Instance.

Результати

1. (+) Контрольований доступ до єдиного екземпляру.

2. (+) Зменшення кількості імен змінних.

3. (+) Допускає уточнення операцій та представлення — від класу Singleton можна породжувати підкласи, а програму легко сконфігурувати екземпляром розширеного класу.

4. (+) Допускає адаптацію класу під змінну кількість екземплярів (не обов’язково 1).

5. (+) Більша гнучкість, ніж у звичайних статичних методів класу.

Лекція 14. Технологія клієнт – сервер.

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

· клієнт формує і посилає запит до бази даних серверу, вірніше - до програми, яка обробляє запити;

· ця програма проводить маніпуляції з базами даних, що знаходяться на сервері, у відповідності з запитом, формує результат і передає його клієнту;

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

Стандартне програмне забезпечення, що реалізує технологію клієнт – сервер, має хорошу масштабованість (ефективне використання нарощеного апаратного забезпечення), стійкість в роботі, захист від несанкціонованого доступу і потужність при роботі з великими проектами в галузі баз даних.

Рисунок 2. Основні складові технології клієнт-сервер

Рисунок 3. Принцип роботи технології клієнт-сервер

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

Лекція 15-16. Технологія компонентного програмування.

Технологія програмування CORBA.

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

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

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

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 реалізує концепцію інтерфейсів і модель посилань на об’єкти.

Дата добавления: 2014-01-05