Програмні компоненти розподілених систем

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

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

Ряд компонентів користувацького інтерфейсу надають свій сервіс кінцевому користувачеві.

Стосовно програм з використанням платформи Call Level Interface (CLI) — прикладного програмного інтерфейсу рівня викликів, під процесом у наведеному визначенні компоненти слід розуміти домен прикладної програми (application domain), який можна розглядати як аналог процесу в керованому коді.

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

Рис. 2.13. Компоненти розподіленої системи.

Програмна компонента є мінімальною одиницею розгортання розподіленої системи. У ході модернізації системи одні компоненти можуть бути оновлені незалежно від інших компонент.

У добре спроектованій системі функції кожної компоненти ставляться тільки до одного рівня прикладної програми. Однак, поділ тільки на три рівні є недостатнім для класифікації компонент.

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

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

Опис програмної компоненти

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

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

• — мова повідомлень, яка описує результат «серіалізації об'єктів»;
• — мова опису «специфікацій повідомлень», що визначає коректні повідомлення для сервісів компоненти;
• — мова опису «інтерфейсу компоненти», що визначає набір її сервісів.

Мови опису інтерфейсу й специфікацій повідомлень часто представлені на практиці однією мовою.

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

• — методи об'єкту, що активується сервером;
• — об'єкт, що активується клієнтом разом зі своїми полями, властивостями й методами;
• — черга з повідомленнями — запитами, які зчитуються програмною компонентою.

Адреса сервісу залежить від проміжного середовища і є комбінацією мережевої адреси компоненти та публічного імені сервісу. Мережева адреса програмної компоненти ґрунтується на імені її комп’ютера для систем віддаленого виклику, або на адресі менеджера черги для систем обміну повідомленнями. Така адреса є адресою протоколу, на якому засноване це проміжне середовище. У ролі такого протоколу можуть виступати HTTP, TCP, NetBIOS, або протокол нижнього рівня проміжного середовища.

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

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

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

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

Таким чином, кожний сервіс програмної компоненти характеризується трьома сутностями:

• — повною адресою сервісу;
• — єдиною специфікацією прийнятих сервісом повідомлень (запитів);
• — єдиною специфікацією прийнятих від сервісу повідомлень (відповідей).

Сукупність специфікацій всіх сервісів програмної компоненти утворює її інтерфейс (рис. 2.14).

Рис. 2.14. Інтерфейс компоненти розподіленої системи.

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