• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Моделі взаємозв'язку за інформацією

Для опису взаємозв'язку об'єктів пропонується використання двох моделей – моделі інформаційного об'єднання і моделі управління об'єктами в динаміці виконання у середовищі.

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

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

Спочатку в множиніі даних D виділимо дві підмножини

_s

D = ( И Di ) И Dc,

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

Для кожного об'єкту Ki з множини K визначимо предумова Ri Î R і постумова Qi Î Q, які задаються на безлічі керівників змінних Dc_. Предумова Ri перевіряється перед викликом компоненту Ki і визначає умову його виклику. Після цього притягуються механізми аналізу і перетворення типів даних і їх підготовка для запуску викликаного компоненту. Постумова Qi перевіряється після виконання Ki як умова завершення основної програми і перетворення результату до необхідного виду викликала компоненти, а також перевіряється готовність до вибору нового компоненту.

Таким чином, множини R ={Ri} і Q ={Qi}_і=1,s визначають модель управління для вибору одного з об'єктів множини Р і аналізу множини R в цілях знаходження першої правильної умови виконання елемента з множини K. Якщо відповідна умова з R істинно, то відбувається виклик цього компоненту, інакше, шукається нова умова з R і процес повторюється, поки не відбудеться вибір необхідної умови перетворення передаваних параметрів, виконання вибраного з K компоненту і відправка результату після аналізу відповідної умови Qi.

Органызацыя взаємозв'язку в мережних середовищах

В інтегрованому мережному середовищі клієнт–сервер обмін даними між об'єктами/компонентами проводиться за допомогою операторів видаленого виклику, в яких пересилаються параметри одному одному. При цьому в рамках розподілених систем сформувалося декілька видів інтерфейсних посередників (сервер файлів, портмейкер RPC, брокер ORB, VM–машина), що підтримують відповідні моделі інтеграції програмних об'єктів до інтегрованої програмної структури Р [3–7, 29–34]. Розглянемо їх.

Посередник – сервер файлів.Інтерфейс між взаємодіючими програмними об'єктами в середовищі клієнт–сервер виконує сервер файлів. Модель взаємозв'язку об'єктів М2 = {P { P1_, P2_, P3}_{, D}} через сервер файлів визначається на vyмножині об'єктів Р і даних D, на якій визначаються передані серверу дані.

Зв'язок об'єктів через stub. Середовищем підтримки взаємодії компонентів через stub-клієнта і stub-серверу є ОNС SUN, OSF DSE [1, 2] і CORBA.

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

Модель зв'язку М3 = {P, І, RPC, D} задає гнучку структуру, компоненти якої задані на множині мов І і відповідних інтерфейсах в мові RPC.

Опис інтерфейсу забезпечує виклик видалених процедур з бібліотеки системи і передачу параметрів в запиті транспортним протоколом (UDP, TCP/IP) мережного середовища ОNС SUN [1, 2].

Зв'язуючою ланкою між об'єктами, що викликаються і викличним, є stub-клієнта, який і посилає повідомлення до stub-серверу для виконання заданої видаленої процедури. Відповідно stub-серверу ініціює виконання цієї процедури і повертає результат назад через сіть клієнту.

Рис.3.3. Модель взаємозв'язку об'єктів в мережному середовищі

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

Зв'язок об'єктів в середовищі DCOM.Модель об'єктних компонентів DCOM задає зв'язок розподілених об'єктів і документів у версії IDL, а система CORBA забезпечує взаємодію об'єктів через брокера ORB.

Система DСОМ включає формалізмы:

– механізм RPC – виклику видаленої процедури і передачі їй даних;

– мережний обмін даними;

– системи передачі даних, перетворення даних, кодування і декодування даних для різної архітектури машин.

Зв'язок об’єктів брокером ORB. Модель інтеграції компонентів створюваної системи в розподіленому середовищі CORBA має наступний вигляд: М = { P, І, ORB, D, W }, де Р-програма, І- інтерфейс, ORB –зв'язник об'єктів в розподіленому середовищі W.

У середовищі система CORBA головну зв’язуючу роль між програмними об'єктами виконує брокер ORB через описаний інтерфейс stub/skeleton в мові IDL (рис. 3.3).

Інтеграція об’єктів в системі CORBAвключає:

– механізми передачі запитів видаленим об'єктам через інтерфейсні об'єкти stub і skeleton;

– мережний обмін даними і їх перетворення (кодування і декодування при розбіжності архітектури програмних компонентів);

– системи перетворення типів даних об'єктів, якими обмінюються між собою компоненти кожної пари в ЯП: З Û Смолток, Смолток Û Ада, Ада Û Кобол, Кобол Û Java і ін.

Для завдання інтерфейсу в системі CORBA розроблена я мова IDL, яка незалежна від мов опису об'єктів (С, С++, Паскаль і ін.). Інтерфейси об'єктів в цій мові запам'ятовуються в репозиторії інтерфейсів (Interface Repository), а реалізації об'єктів – в репозитарії реалізацій (Implementation Repository). Незалежність інтерфейсів від реалізацій об'єктів дозволяє їх використовувати в статиці і в динаміці.

Інтерфейс клієнта (Сlient Interface) складається з трьох інтерфейсів:

– stub-інтерфейсу, що містить опис зовнішньо видимих параметрів і операцій об'єкту в мові IDL, генерується в статичну частину програми клієнта і зберігається в репозитарії інтерфейсів;

– інтерфейсу динамічного виклику DII (Dynamic Invocation Interface) об'єкту, визначуваного під час виконання програми клієнта за допомогою пошуку опису інтерфейсу в репозитарії інтерфейсів;

– інтерфейсу сервісів ORB (ORB Services Interface), що містить набір сервісних функцій, які клієнт запрошує в серверу.

Сервіс надається наступними видами адаптерів:

– об'єктний адаптер (Object Adapter), який забезпечує екземплярам об'єктів звертатися до сервісних функцій;

– базовий адаптер (Basic Object Adapter), який може забезпечувати виконання об'єктів незалежно від брокера;

– бібліотечний адаптер (Library Adapter), що забезпечує виконання об'єктів, що зберігаються в бібліотеці об'єктів і що викликаються з прикладної програми клієнта;

– адаптер БД (Database Adapter), що забезпечує доступ до об'єктно-орієнтованих БД.

Запити реалізуються за допомогою шаблонів інтеграції компонентів:

– Client class для виклику методу, який буде виконаний сервером.

– Stub class для конвертації методу на стороні клієнта;

– ORB class управляє методами передачі даних і викликами методів між процесами;

– Implementation class містить ділову логіку серверу, екземпляр цього класу – сервент – реєструється в ORB і може використовуватися клієнтом для запуску іншого процесу;

– Server class створює сервлет і посилання, яке він записує в стандартний файл виходу;

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

– адаптер POA (Portable Object Adapter) забезпечує доступ до різних ORB.

При виконанні сервісних функцій брокер ORB використовує наступні загальносистемні засоби CORBA:

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

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

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

Взаємозв'язки в JAVA.Мова JAVA орієнтована на проектування розподілених додатків, які взаємодіють між собою за допомогою методу виклику RMI [6, 7]. Інструментом інтеграції є virtual machine, яка працює з byte–кодами компонентів в ЯП. Взаємодія компонентів на мовах JAVA і С++ здійснюється за допомогою брокера ORB, розглянутого вище. При цьому перетворення типів даних цих двох мов відноситься до bite-код програм, що відтранслюють, які інтерпретуються на віртуальній машині.

Формалізми в системі JAVA включають:

– механізм виклику видалених методів RMI;

– мережний обмін даними між видаленими компонентами;

– віртуальну машину для інтерпретації кодів компонентів компілятора С++ в середовищі JAVA.

Альтернативою інтерфейсу компонентів є CGI (Common Gateway Interface), через який взаємодіє клієнт з WEB-сервером. Для доступу до інформації і формування відповіді клієнту використовується сервлет, який описується на мові JAVA, не залежить від платформи і використовує бібліотеку класів JAVA. Реалізація сервлетов в JAVA здійснюється за допомогою інструменту Servlet Development Kit.

Переглядів: 654