Часть I1.3. Примеры профилейПример 1.
В данном примере зададимся целью определить профили основных функциональных компонент корпоративной информационной технологии некоторой организации, которая хотела бы обеспечить переносимость разрабатываемых ей SQL-приложений (как серверной, так и клиентских частей), написанных с использованием языков С++ и SQL. При этом для определенности будем предполагать, что сетевая инфраструктура данной организации основана на использовании локальной сети FDDI (См. рис. 1.1).  Рис. 1.1. Пример корпоративной информационной технологии
Для обеспечения сформулированных выше целей открытости корпоративная технология должна строиться из систем, поведение которых на своих интерфейсах соответствует стандартам. В частности, в данном случае задача состоит в том, чтобы построить два OSE-профиля - один, специфицирующий требования к интерфейсам клиентских систем, другой – к интерфейсам сервера баз данных.
В состав спецификаций API включим стандарты языков С++ и SQL (будем пока обозначать их как Std «С++» и Std «SQL», соответственно), а также интерфейс RDA, реализующий сервис протокола RDA для клиентских систем. Таким образом, описание интерфейса API в профиле Pc включает ссылки на следующие спецификации:
Заметим, что в профиль Pc могут быть включены спецификации и других классов интерфейсов, как, например, графического пользовательского интерфейса. И нам пришлось бы включать в профиль Pc такие ссылки, если бы одним из исходных требований к разрабатываемой системе было бы требование обеспечения легкости перевода пользователей с одной компьютерной платформы на другую. 
Рис. 1.2. Сценании для профилей Pc и Ps. Предположим, что при анализе предложенного нами решения заказчик захотел построить транспортную систему своей организации на основе сети Intranet. В этом случае нам пришлось бы перепроектировать профиль T54, заменив его, например, на профиль Ti, основанный на использовании следующих стандартов:
Таким образом, основная идея построения новой транспортной системы Ti состоит в использовании протокола TS (RFC 1006), эмулирующего интерфейс протокола TP OSI над стеком протоколов TCP/IP, а также протокола (RFC 1390), обеспечивающего передачу IP-пакетов через сеть FDDI. Протокольная структура транспортной системы Ti иллюстрируется на рис. 1.3.
 Рис. 1.3. Стек протоколов конечной системы, реализующей транспортный сервис TP OSI над стеком протоколов TCP/IP и FDDI. Следует заметить, что профиль Ti относится к классу коммуникационных профилей. Однако по определению он не является OSI-профилем, так как содержит ссылки на стандарты, не входящие в состав стандартов модели OSI. Пример 2.
Во втором примере детальнее рассмотрим использовавшийся выше международный стандартизованный профиль TC54, определяющий транспортный сервис в режиме с соединением через локальную сеть FDDI и являющийся примером OSI-профиля. 
Рис. 1.4. Сценарий, иллюстрирующий применение профиля TC54 Функциональность данного профиля (без учета функций сетевого управления), т.е. состав протоколов, входящих в профиль, показаны на рис. 1.5. Данный стек включает:
 Рис. 1.5. Стек протоколов конечной системы, реализующей профиль TC54 Пример 3.Следующий пример проиллюстрирует применение API-профилей. В системе стандартов POSIX, с которой нам предстоит еще детальное знакомство, определяются стандарты на переносимые интерфейсы операционных систем. В ней аппарат профилей используется для построения стандартизованных API-интерфейсов различной проблемной ориентации посредством агрегирования и параметрической настройки модулей функциональности (Units of Functionality) уже определенных стандартных интерфейсов. В частности, к важнейшим профилям, включенным в состав набора спецификаций POSIX [5], относятся:
Для систем реального времени определены четыре профиля, соответствующие системам различной функциональности, начиная от простых встроенных систем с минимальными функциональными возможностями и, кончая многоцелевыми сложными вычислительными системами с расширенными возможностями, которые применяются, например, в контурах управления крупными военными системами, сложными технологическими процессами и т.п. В частности, определены следующие профили реального времени:
Для определенности рассмотрим профиль для встроенных или минимальных систем реального времени.
Данный профиль, имеющий в классификации стандартов наименование PSE51, описывает API-окружение систем с минимальными функциональными возможностями. В частности, таким системам не требуется файловая система, средства мультипроцессности, система управления памятью, средства пользовательского взаимодействия, расширенные средства ввода/вывода и пр. Поэтому основным приемом построения профиля является селекция требуемых для систем данного класса сервисов, описанных в стандартах POSIX.
Из стандарта P1003.1 в профиль выбираются следующие модули функциональности:
Таким образом, в состав функций, которые должны быть реализованы конформной профилю системой, вводятся наборы функций, входящие в указанные модули функциональности. Аналогичным образом выбираются необходимые функции и из других стандартов, входящих в профиль. Пример 4.В данном примере рассмотрим профили, разработанные с целью классификации и описания функциональности оконечных систем для различных технологий обработки сообщений. Такие профили предназначены для разработчиков оконечных систем обработки сообщений, например, для разработчиков информационных приборов (information appliances), предоставляющих пользователям сервис электронной почты. Стандартизации сервисов и принципов функционирования систем обработки сообщений (Message Handling System - MHS) посвящена серия рекомендаций ITU-T X.400 (в эквивалентном этим рекомендациям стандарте ISO 10021 системы данного класса называются системами обмена текстовыми сообщениями (Message-oriented Text Interchange Systems - MOTIS)). Кроме этого, серия F.400 рассматривает вопросы использования для передачи сообщений систем телематики (телекс, телетекст, видеотекст, факс) и систем физической доставки сообщений (почта, курьерская доставка), а также использование систем передачи сообщений для передачи электронных данных. Большое число и функциональная сложность этих стандартов, а также многообразие возможных реализаций почтовых систем делают актуальным систематизацию возможных решений в этой области на основе разработки системы профилей. Прежде, чем перейти к описанию профилей для классов систем , рассмотрим функциональную модель системы обработки сообщений, а также принципы ее работы. Данная модель, заимствованная из документа Rec. ITU-T X.400, иллюстрируется на рис. 1.6. 
Рис. 1.6. Функциональная модель системы обработки сообщений (MHS) На рис. 1.6. используются следующие сокращения:
Система обработки сообщений предоставляет пользователям возможность обмениваться сообщениями на основе метода промежуточного хранения сообщений (Store-and-forward – запомни-передай). Сообщения, отправляемые пользователем-отправителем (originator) через соответствующий ему прикладной процесс UA, передаются системой передачи сообщений MTS (являющейся составной частью системы обработки сообщений MHS) одному или нескольким пользователям-получателям (recipient). Все функции в MHS выполняются активными сущностями (прикладными процессами OSI), какими являются MTA, MS, UA, AU. В частности:
Рекомендации X.400 содержат несколько сот страниц текста с описанием сервисов указанных функциональных компонент системы MHS и протоколов взаимодействия между ними. В связи с широким применением технологий передачи сообщений для различных прикладных контекстов специальной рабочей группой по функциональной стандартизации комитета JTC1 ISO в середине 90-х годов была разработана система профилей, позволяющая создавать интероперабельные системы сообщений различной функциональной сложности с учетом конкретных сфер приложений. Рассматриваемая система профилей охватывает три сферы применения систем MHS, а именно:
Для этих трех случаев определены три набора профилей, получивших наименования AMH1n, AMH2n, AMH3n, соответственно. Рассмотрим для определенности набор профилей AMH3n, который мог бы представлять интерес для развития первого примера, связанного с построением некоторой корпоративной технологии, обеспечивающей, например, возможность обмена между удаленными подразделениями организации EDI-документами, соответствующими стандарту EDIFACT (ISO 9735-88). В профилях AMH3n определяются комбинации возможностей базовых стандартов применительно к передаче электронных данных с учетом зависящих от приложений требований к формату передаваемых данных. Данная группа включает следующие профили, в которых определяются требования к функциональным возможностям сущностей EDI-UA и EDI-MTS, а также к контентозависящему протоколу взаимодействия между конечными пользователями:
На рис. 1.7 показан сценарий для набора профилей 
Рис. 1.7. Сценарий для набора профилей AMH3n (знаком * отмечен протокол доступа к сервису EDI-MS с расширенными возможностями по сравнению с описанным в профиле AMH14)
Пример 5.Аппарат профилирования применяется также и в стандартизации Internet-технологий. В качестве примера укажем на RFC 1890 ‘RTP Profile for Audio and Video Conference with Minimal Control’, в котором описывается применение транспортного протокола реального времени (RTP) и соответствующего ему протокола управления RTCP для поддержки реализации аудио- и видеоконференций с множеством участником при минимальном управлении. При этом учитывается использование ряда стандартов на представление и передачу аудио- и видео данных.
|
