Розподілені POSIX-OSE-сумісні системи

Рис. 1.6 – Розподілена прикладна платформа

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

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

Застосування можуть користуватися службами, розподіленими на ряді комп'ютерів. Це доцільно у розподіленому середовищі для підтримки ряду застосувань, що користуються базою даних, розподіленою на кількох комп'ютерах.

Служби POSIX-OSE розділені на категорії, описані у табл. 1.1. Для кожної категорії чітко описані сервіси і пов'язані стандарти, а також вплив перехресної категорії служб на кожну службу.

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

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

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

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