Часть V

5.2. Эталонная модель POSIX OSE RM

    Методологической основой для таксономии и разработки стандартов POSIX служит эталонная модель OSE RM (Open System Environment Reference Model), определяющая концептуальный базис и систематический подход к классификации интерфейсов и сервисов открытых систем.

    В эталонной модели определяется значительное число понятий концепции открытых систем, как, например: окружение открытой системы (OSE), свойства открытости систем (переносимость, интероперабельность, масштабируемость), прикладная платформа, прикладное программное обеспечение, интерфейс прикладной программы (API), интерфейс коммуникационных сервисов (CSI), человеко-машинный интерфейс (HCI) и др.

    Определения вышеперечисленных понятий нами уже вводились (см. главы 1 и 4) при изучении документа ISO 10000, концептуально согласованного с Руководством POSIX OSE.

    Дополним этот список еще двумя понятиями, а остальные будем вводить по мере необходимости.

    22) Внешнее окружение (external environment - EE) - набор внешних для прикладной платформы сущностей, взаимодействие с которыми осуществляется через некоторые сервисы.

    23) Интерфейс внешнего окружения (external environment interface - EEI) - интерфейс между прикладной платформой и внешним окружением, через который осуществляется взаимодействие с внешними по отношению к прикладной платформе сущностями посредством использования сервисов этого интерфейса.

    В модели OSE RM информационная система рассматривается как черный ящик, взаимодействие с которым стандартизовано и осуществляется только через ее интерфейсы, где под интерфейсами понимаются границы, разделяющие между собой некоторые функциональные сущности.

    Именно через эти интерфейсы система (платформа) может предоставлять сервисы пользователям (приложениям) и использовать сервисы, связанные с сущностями внешнего окружения. Поэтому центральным понятием данной модели является понятие окружения открытых систем (Open System Environment - OSE), под которым, напомним, понимается полный набор интерфейсов, сервисов, форматов, а также пользовательских аспектов, обеспечивающих интероперабельность и/или переносимость программ, данных, людей на основе использования базовых стандартов и профилей ИТ.

    Таким образом, под открытой системой подразумевается система ИТ, реализующая некоторое OSE.

    Данная модель обеспечивает связь между спецификациями требований и разработкой конкретной информационной системы. Эталонная модель вводит набор соглашений и понятий, которые используются как пользователями информационной системы, так и поставщиками ИТ. Подобный набор общих соглашений и понятий является ключом для достижения переносимости прикладного программного обеспечения, взаимосвязанности систем и возможного повторного использования в дальнейшем программного обеспечения. Данная модель позволяет создавать более компактные и корректные спецификации.

    Рассмотрим принципы построения OSE RM. Этот процесс выполняется с помощью следующих шагов.

1. Стандарты интерфейсов открытых систем разбиваются на две основные категории в соответствии с двумя типами интерфейсов:

   • стандарты прикладных программных интерфейсов (Application Program Interface (API) Standards);
   • стандарты внешнего окружения (External Environment Interface (EEI) Standards).

       Первая группа стандартов специфицирует взаимодействие прикладного программного обеспечения с компьютерной системой (прикладной платформой). Эти стандарты в основном предназначены для обеспечения переносимости приложений.

       Вторая группа стандартов определяет взаимодействие информационной системы с ее внешним окружением. Эти стандарты позволяют решать проблемы интероперабельности систем, переиспользуемости программного обеспечения и переносимости данных.

       Следование стандартам обеих групп позволяет решить главную задачу для потребителей информационных технологий, а именно, обеспечить возможность построения информационных систем из компонентов, поставляемых различными изготовителями, и, как следствие, обеспечить независимость от поставщиков ИТ в целом.

2. Указанные выше две группы сервисов и стандартов, разбиваются на четыре основных категории, а именно:

   • системные или программные сервисы (System Services)
   • коммуникационные сервисы (Communication Services)
   • информационные сервисы (Information Services)
   • сервисы человеко-машинного взаимодействия (Human/Computer Services).

3. Для каждой из выше упомянутой категории сервисов определяется их функциональное разбиение на области (подкатегории). Разбиение категорий сервисов на подкатегории приведено в таблице 5.1.

   Service Category	Subcategories
   System Services Language	ServicesCore System Services
   Communication Services	Communication Services
   Information Services	Database ServicesData Interchange ServicesTransaction Processing Services
   Human/Computer Interaction Services	User Command Interface ServicesCharacter-Based User Interface ServicesWindows System ServicesGraphics ServicesApplication Software Development Support Services

4. Для каждой подкатегории сервисов конкретизируется исходная эталонная модель, т.е. разрабатывается некоторая версия эталонной модели, отражающая особенности использования соответствующей подкатегории сервисов.

5. На основе соответствующей эталонной модели для каждой подкатегории сервисов разрабатывается ее функциональность в виде определения групп сервисов, которые в свою очередь структурируются до элементарных сервисов.

6. Для каждой группы сервисов определяются соответствующие ей ссылки на существующие или разрабатываемые стандарты.

7. Для каждой категории сервисов определяются, так называемые, межкатегориальные сервисы (Cross-Category Services), элементы которых могут входить в любую группу сервисов. К ним относятся сервисы интернационализации (Internationalization Services), системной безопасности (System Security Services), административного управления (Systems Management Services).

    Эталонная модель OSE/RM имеет несколько общих форм представления, отражающих различные архитектурные и функциональные аспекты модели. В дальнейшем общие представления модели конкретизируются для каждой категории сервисов с тем, чтобы полнее отразить их специфику. Наиболее общее представление данной эталонной модели иллюстрируется на рис. 5.1.

    Как видно на рис. 5.1, модель определяет три типа сущностей, а именно:

• прикладного программного обеспечения (Application Software Entities),
• прикладной платформы (Application Software Entities),
• внешнего окружения (External Environment Entities),

    а также два типа интерфейсов между ними - API и EEI.

    Прикладная платформа предоставляет сервисы классов API и EEI через соответствующие интерфейсы.

    Данная модель является достаточно общей в том смысле, что она может быть использована для широкого спектра систем, как общего, так и специального назначения. Дальнейшая структуризация интерфейсов и классов сервисов (разбиение их на категории, подкатегории, конкретные элементы) позволяет построить варианты модели, учитывающие различные особенности применения систем и спектр системных архитектур.

    Данная эталонная модель не является иерархической. Каждая часть модели взаимодействует с остальными частями через интерфейсы. Все возможности системы могут быть доступны как локально, так и удаленно, если данная система является частью распределенной системы.

    На рис. 5.2 и рис. 5.3 показаны представления эталонной модели OSE/RM, расширяющие исходную модель, представленную на рис. 5.1.

    Представление на рис. 5.2 развивает исходную модель определением классов сущностей эталонной модели. На ней также демонстрируется различие между понятиями "сущность" и "интерфейс" (граница между сущностями).

    Сущность "прикладное программное обеспечение" состоит из одной или более компонент следующих типов:

• Программ (исходный код, файлы команд или сценариев и т.д.).
• Данных (данные пользователя, параметры приложения, параметры экрана и т.д.).
• Документации (online-документация; твердые копии не рассматриваются).

    Прикладная программа условно может быть разделена на две части:

• неизменяемую часть исходного кода, не требующую изменений при переносе с одной платформы на другую;
• изменяемую часть исходного кода, которая требует изменений при переносе с одной платформы на другую.

    Для повышения степени переносимости прикладного программного обеспечения необходимо использовать при его создании стандарты на API, а также минимизировать изменяемую часть. Это существенно облегчит перенос компонентов прикладного программного обеспечения между различными (но соответствующими стандартам на интерфейсы) прикладными платформами.

    На одной и той же прикладной платформе могут одновременно выполняться несколько приложений, как показано на рис. 5.2. Каждое приложение можно рассматривать как независимую прикладную сущность, которая при необходимости взаимодействует и синхронизируется с другими приложениями с помощью различных коммуникационных механизмов. Прикладная платформа определяется как набор ресурсов, предоставляемых сервисам, с помощью которых приложение выполняет свои функции.

Рис.5.2. Сущности и элементы эталонной модели POSIX OSE

    Представление на рис.5.3 конкретизирует исходную модель в части структуризации интерфейсов.

    Для того чтобы обеспечить целостность и согласованность системы, все ресурсы должны быть доступны исключительно через API. Понятие прикладной платформы не включает в себя конкретную реализацию сервисов. Например, платформа может содержать единственный процессор, разделяемый несколькими приложениями, или являться большой распределенной системой.

    Внешнее окружение содержит внешние сущности, с которыми прикладная платформа обменивается информацией. Эти сущности могут быть разбиты на несколько категорий таких, как, например, конечные пользователи или сущности, обеспечивающие обмен информацией с долговременной памятью, или коммуникационные сущности.

    Как отмечалось выше, между сущностями общей модели существует два типа интерфейсов: API и EEI.

Рис.5.3. Эталонная модель POSIX OSE - интерфейсы

    API определяет следующие типы сервисов:

• системные сервисы (System Services);
• коммуникационные сервисы (Communication Services);
• информационные сервисы (Information Services);
• сервисы взаимодействия человека с компьютером (Human/Computer Interaction Services).

    Примером API-интерфейса может служить процедура создания окна:

    Open_Window (x1, y1, x2, y2).

    EEI определяет следующие типы сервисов и, соответственно, интерфейсов:

• коммуникационные сервисы (Communication Services);
• информационные сервисы (Information Services);
• сервисы взаимодействия человека с компьютером (Human/Computer Interaction Services).

    Примером EEI-интерфейса может служить понятие окна ('window'), как сущности, связанной с некоторой областью на экране монитора.

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

    В общем случае прикладные программные сущности никогда не имеют доступа к EEI непосредственно, хотя выполнение API сервисов может вызывать выполнение EEI сервисов.

    Эталонная модель POSIX OSE разработана таким образом, чтобы с ее с помощью можно было адекватно специфицировать функциональности различных распределенных информационных систем.

    Представление на рис.5.4 расширяет исходную модель на случай распределенных систем.

Рис. 5.4. Эталонная модель POSIX OSE - распределенные системы

    В распределенном окружении различные прикладные платформы могут взаимодействовать с помощью сервисов (коммуникационных механизмов) интерфейса внешнего окружения. Когда для некоторой сущности прикладного программного обеспечения требуется установить связь с некоторой сущностью на другой платформе, делается запрос через API. Конкретная реализация прикладной платформы транслирует API запросы в соответствующие действия на EEI.

    Связь между прикладными платформами устанавливается с помощью внешних сущностей, поэтому передача данных осуществляется коммуникационными сервисами EEI, обеспечивающими взаимодействие с такими внешними сущностями. В модели OSE RM также предусмотрены архитектурные решения и для распределенных прикладных платформ, состоящих из нескольких компонент, взаимодействующих через собственные внутриплатформенные интерфейсы.

    Теперь остановимся на способах спецификации API. В эталонной модели OSE RM рассматриваются следующие три вида спецификаций API:

• Спецификации API, полностью представленные средствами некоторого языка программирования (Programming language API specifications).
• Языково-независимые спецификации сервисов (Language-independent service specifications).
• Спецификации API языкового связывания (Language-binding API specifications), которые представляют собой по существу результат отображения языково-независимых спецификаций в форму доступа к сервису, выраженную средствами конкретного языка программирования.

    Последние два способа спецификации API считаются наиболее предпочтительными для целей стандартизации.

    От общих архитектурных и понятийных моделей в Руководстве POSIX (эталонная модель OSE RM описана в третьем разделе) осуществляется переход к описанию собственно категорий сервисов, чему посвящен самый большой раздел Руководства, четвертый. При этом каждая категория сервисов описывается по следующей единой схеме:

    4.__n.1 Overview and Rationale /Обзор и обоснование/4.__n.2 Scope /Область действия/4.__n.3 Reference Model /Эталонная модель применительно к данной категории

    сервисов/4.__n.4 Services /Сервисы/4.__n.5 Standards, Specifications, and Gaps /Стандарты, спецификации и белые пятна/4.__n.6 POSIX OSE Cross-Category Services /Межкатегориальные сервисы/4.__n.7 Related Standards /Связанные стандарты/4.__n.8 Open Issues /Открытые проблемы/

    В качестве примера рассмотрим описание категории сервисов системного ядра (Core System Services).