Страница 10: ДСТУ 4249:2003. Інформаційні технології. Настанова щодо POSІX-сумісних середовищ відкритих систем (POSІX-OSE) (61118)

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

Прикладом загального принципу зв’язування взаємодії людина/комп’ютер через АРІ та ЕЕІ служить "вікно". У АРІ гіпотетична нотація

Open_Window (х1, у1, х2, у2)

визначена для виводу прямокутної області з координатами верхнього лівого кута (х1, у1) і правого нижнього кута (х2, у2) на площині екрана. Згідно ЕЕІ, появу І поведінку вікна можна реєструвати незалежно від АРІ. Наприклад, можна прийняти угоду, що всі вікна мають рамки і кнопки по ку­тах, надані користувачеві для зміни розмірів вікна.

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

Інтерфейси типу ЕЕІ —три наступні:

• НСІ (Інтерфейс людина/комп’ютер);

• ISI (інтерфейс інформаційних служб);

• CSI (інтерфейс комунікаційних служб).

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

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

CSI надає доступ до служб, що підтримують взаємодію між внутрішніми об’єктами застосування і зовнішніми об’єктами прикладної платформи типу об’єктів застосування на інших прикладних платфор­мах, зовнішніх засобів і пристроїв передавання даних. Служби передбачають стандартизацію структури, синтаксису і форматів протоколів для забезпечення інтероперабельності застосування.

POSIX-OSE АРІ — комбінація ряду стандартних інтерфейсів. Можна порівняти POSIX-OSE із книж­ковою полицею, де стоїть кілька стандартних АРІ, причому кожен АРІ — окрема книга на книжковій по­лиці. POSIX-OSE АРІ описує повний набір служб і їхніх послуг, наданих інтерфейсом між застосуванням і основною прикладною платформою. Служби, пропоновані АРІ, можна підрозділяти на категорії:

• системні служби, що охоплюють системне ядро і мовну підтримку;

• служби комунікацій;

• інформаційні служби, що забезпечують ведення БД, обмін даними й оброблення транзакцій;

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

Перша група АРІ надає доступ до служб, пов’язаних із ресурсами, внутрішніми щодо прикладної платформи. Останні три групи АРІ надають застосуванню доступ до служб, пов’язаних з об’єктами зовнішнього середовища.

Перелічені категорії API-служб описують необхідний діапазон API-функцій. Специфікації (тобто безпосередньо документація) можуть приймати форму специфікацій мови програмування, мовно не­залежних специфікацій служб і мовних прив’язок для специфікацій служб. Ці специфікації можна описати у такий спосіб:

— специфікації, традиційно пов’язані з мовами, типу керування програмами (if... then ... else), математичні функції, маніпулювання рядками, паралелізм, механізми програмування низького рівня тощо, визначені як API-специфікації мов програмування',

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

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

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

Дихотомія (розподіл класу на два протилежні підкласи) «мова програмувавня/прив’язка до мови» може бути результатом шляху, яким зараз розвивають стандарти інформаційних технологій. Спе­цифікації мов програмування розроблені з метою стати "системно-незалежними" (наприклад, Сі, Кобол, Фортран). Специфікації прив’язки до мови (наприклад, ISO/IEC 9945-1, MOSI, GKS, SQL) транслюють у "незалежні від мов" специфікації з однієї чи значною кількістю прив’язок до спеціальних мов. Керуючись згаданою аналогією з книжковою полицею, можна відповісти на таке запитання: "Які книги (стандарти) необхідні програмісту для створення початкового тексту цілком мобільної приклад­ної програми?" Як тільки програміст вирішить, яку мову використовувати, йому знадобиться наста­нова з мови програмування (наприклад, Сі чи Ада) і специфікації мовних прив’язок, що забезпечують усі необхідні служби (наприклад, використання СІ для виводу графіки, мережного оброблення й індек­сації файлів). У такому контексті чітко видно, що головний компонент АРІ — основна специфікація мови. Фактично більшість корисних програм можна створити, використовуючи тільки основні специфікації мови.

Відношення між службами, пропонованими АРІ, Й аналогічно іменованими службами в ЕЕІ — не просто взаємно однозначне. Наприклад, інтерфейс обслуговування сховища даних може забезпечу­вати прикладну програму прозорим доступом до вилученого файлу через мережну підтримку. Тоді обслуговування сховища даних, проведеного в АРІ, залежить від І переноситься на служби комуні­кацій, наданих у ЕЕІ.

Загалом об’єкти застосування ніколи не звертаються безпосередньо до ЕЕІ, хоча сервісні за­пити в АРІ часто закінчуються викликом служб ЕЕІ. Це зазвичай відбувається під час використання механізмів, про які розробник прикладної програми ніколи не піклується і не простежує, поки за­довольняється службовий запит. Аналогічно Інформаційні запити (обслуговування), доступні в АРІ, іноді виконують відокремлено (локально), без виклику функцій ЕЕІ.

На щастя, для задоволення вимог POS1X-OSE немає потреби докладно визначати подібні зв’язки. Фактично занадто деталізований опис суттєво стримує реалізацію. Пропонована реалізація прикладної платформи по-різному визначає зв’язок між АРІ і ЕЕІ.

Рисунок 4 — Еталонна модель розподіленої POSiX-OSE-системи

У розподіленому середовищі множинні прикладні платформи взаємодіють за допомогою ме­ханізмів зв'язку, зовнішніх щодо платформи. На рисунку 4 показана взаємодія прикладної платформи зі службами комунікацій ЕЕІ. Об’єкт прикладної програми встановлює комунікації з об’єктом на Іншій платформі за допомогою АРІ. Реалізація прикладної платформи транслює запити АРІ у відповідні операції для ЕЕІ.

Рисунок 5 — Реалізація розподіленої прикладної платформи

Зв'язок між прикладними платформами відбувається через зовнішні об’єкти, що виконують у службах зв'язку ЕЕІ функції транспортування даних. Вони можуть використовувати розмаїття ме­тодів реалізації і протоколів, забезпечуючи через мережу доступ до розподілених даних і служб.

Такий спосіб звертання до служб зв'язку ЕЕІ використовують також для прозорості реалізації прикладної платформи. На рисунку 5 показана спрощена схема реалізації прикладної платформи, коли платформа — фактично розподілена система, складена з множини платформ. Тут прикладна платформа позначена як така, що приймає (perceived), це важливо, наприклад, під час постачання. Умови постачання визначають вимоги до perceived-платформ, а покупці відповідають заявками, що описують альтернативні реалізації платформ. У одній пропозиції необхідно реалізувати плат­форму, що використовує одиничний монолітний процесор типу класичного mainframe (універсальної ЕОМ), в іншому — забезпечити ряд спеціалізованих процесорів, об’єднаних у мережу. Можливе широке розмаїття варіантів, кожний з який має свої переваги і недоліки. Визначаючи вимоги постачання як perceived-платформу, покупець може розглядати широкий діапазон альтернативних реалізацій і легше визначити задовільне для нього рішення.

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

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

У Настанові описані служби, надані користувачам прикладних платформ, та служби, що підтри­мують вимоги POSIX у частині мобільності застосувань та інтероперабельності системи. Ці служби доступні користувачам за допомогою визначених Інтерфейсів, ключових щодо Еталонної моделі POSIX-OSE (3.2).

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

Наступний розвиток стандартів і технологій приведе до розвитку Настанови.

Як результат багатьох вільних дискусій визначений повний і несуперечливий набір стандартів для POSIX-OSE. Одним із вирішальних критеріїв «третейського» завершення стала підтримка у повному обсязі служб, обов’язкових для прикладної платформи. Фактори, використовувані для добору стан­дартів, які вимагають опису, враховують за пріоритетами.

Хоча служби визначені з чітким гіпотетичним поділом, стандарти відбивають їхній реальний поділ. Стандарти створені різними організаціями і проектантами та в багатьох випадках виконані ізо­льовано. Як наслідок, відображення служб у стандартах часто не є взаємозалежним.

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

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