Інтерфейси Еталонної моделі

Рис. 1.4 розширює рис. 1.2 у частині ідентифікації категорій служб, доступних в інтерфейсах API і EEI Еталонної моделі.

Інтерфейс EEI між прикладною платформою і зовнішнім середовищем сприяє обміну даними, тобто він стосується інтеропера­бель­ності системи і прикладного ПЗ. Мобільність користувача і даних безпосередньо забезпечу­ють­ся EEI, але аналогічно мобільність прикладного ПЗ побічно підтримується посилан­нями на спільну концепцію, що зв'язує специфікації в обох різновидах інтерфейсу. Приклад спільного принципу інтеграції взаємодії людина-комп'ютер через API і EEI – вікно. У API нотація Open_Window (x1, y1, x2, y2) визначена для виводу прямокутної зони з координатами верхнього лівого кута (x1, y1) і правого нижнього кута (x2, y2) на площині екрана. Згідно EEI, поява і поведінка вікна може реєструватися незалежно від API. Наприклад, можна прийняти, що всі вікна мають рамки і кнопки у кутах, надані користувачеві для зміни розмірів вікна.

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

Інтерфейси типу EEI:

- HCI (інтерфейс людина/комп'ютер);

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

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

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

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

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

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

Таблиця 1.1 – Перелік категорій і служб POSIX-OSE

Категорія служб	Підкатегорії
Системні	Мовна підтримка
Системне ядро
Комунікації	Комунікаційні сервіси
Інформаційні	Підтримка баз даних
Обмін даними
Обробка транзакцій
Взаємодія людина-комп'ютер	Командний інтерфейс
Символьно-орієнтований інтерфейс
Система керування поліекранним відображенням
Підтримка графіки
Підтримка розробки застосувань
Перехресні	Інтернаціоналізація
Безпека
Адміністрування систем

Специфікації можна описувати як:

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

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

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

Хоча мовно-незалежні специфікації не загальні, вини полегшують керування і розробку несуперечливих (сумісних) стандартів мовних прив'язок. Дихотомія (розподіл класу на два протилежних підкласи) «мова програмування/мовна прив'язка» – результат розвитку стандартів ІТ. Специфікації мов програмування розроблені з метою стати "системно-незалежними" (Сі/С++, Кобол, Фортран). Специфікації мовної прив'язки (наприклад, ISO/IEC 9945-1, MOSI, GKS, SQL) транслюються у " мовно-незалежні" специфікації з однієї чи більшою кількістю прив'язок до мов. Як тільки програміст вирішить, якою мовою користуватися, йому знадобиться настанова з мови програмування і специфікації мовних прив'язок, що забезпечують потрібні сервіси (наприклад, використання Cі/С++ для графіки, мережної обробки). Звідси видно, що головний компонент API – специфікація мови, тому більшість корисних програм створені з використанням тільки основних специфікацій мови.

Відношення служб EEI-API – не просто взаємно однозначне. Наприклад, інтерфейс обслуговування сховища даних може забезпечувати прикладну програму прозорим доступом до віддаленого файлу через мережу. Тоді підтримка обслуговування сховища даних, проведеного в API, залежить від і переноситься на служби комунікацій, наданих у EEI.

Загалом об'єкти застосування ніколи не звертаються безпосередньо до EEI, хоча сервісні запити в API часто закінчуються викликом послуг EEI. Це зазвичай відбувається у механізмах, про які розробник прикладної програми ніколи не піклується, поки задовольняється службовий запит. Аналогічно інформаційні запити (на послуги), доступні в API, іноді виконуються відокремлено (локально), без виклику функцій EEI. Щодо вимог POSIX-OSE немає потреби докладно визначати подібні зв'язки. Фактично занадто деталізований опис суттєво обмежує реалізацію, а кожна прикладна платформа по різному визначає зв'язок між API і EEI.

Дата добавления: 2015-11-26