Таким образом, описание коммуникационного интерфейса в клиентском профиле будет включать ссылки на следующие спецификации:

стандарт протокола RDA

стандарты протоколов верхних уровней модели RM OSI (OSI Stack (7-5))

профиль TC54.

В состав спецификаций API необходимо включить стандарты языков С++ и SQL (обозначим их как Std «С++» и Std «SQL», соответственно), а также интерфейс RDA, реализующий сервис протокола RDA для клиентских систем. Таким образом, описание интерфейса API в профиле клиента включит ссылки на следующие спецификации:

Std «С++»

Std «SQL»

интерфейс RDA-клиента.

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

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

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

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

Для профилей рассмотренного варианта таким сценарием может служить схема, показанная на рис. 1.6.

Отметим еще раз что, в соответствии с введенными выше определениями, построенные нами в данном примере профили относятся к OSE-профилям.

Предположим, что при анализе этого решения заказчик захотел построить транспортную систему своей организации на основе сети Intranet.

В этом случае нам пришлось бы перепроектировать профиль T54, заменив его, например, на профиль Ti, основанный на использовании следующих стандартов:

Рис. 1.6. Сценании для профилей клиент-серверной ИС (вариант)

RFC 1006 (IETF STD 35). ISO Transport Service on top the TCP.

RFC 793 (IETF STD 7). Transmission Control Protocol (TCP).

RFC 791 (IETF STD 5). Internet Protocol (IP).

RFC 1390 (IETF STD 36). Transmission of IP and ARP over FDDI Networks.

ISO 9314 FDDI LAN.

Таким образом, основная идея построения новой транспортной системы Ti состоит в использовании протокола TS (RFC 1006), эмулирующего интерфейс протокола TP OSI над стеком протоколов TCP/IP, а также протокола (RFC 1390), обеспечивающего передачу IP-пакетов через сеть FDDI. Протокольная структура транспортной системы Ti иллюстрируется на рис. 1.7.

Рис. 1.7. Стек протоколов конечной системы, реализующей транспортный сервис TP OSI над стеком протоколов TCP/IP и FDDI.

Следует заметить, что профиль Ti относится к классу коммуникационных профилей. Однако по определению он не является OSI-профилем, так как содержит ссылки на стандарты, не входящие в состав стандартов модели OSI.

Если же детальнее рассмотреть используемый выше международный стандартизованный профиль TC54, определяющий транспортный сервис в режиме с соединением через локальную сеть FDDI и являющийся примером OSI-профиля, то сценарий для профиля TC54, взятый из справочника международных стандартизованных профилей, может выглядеть так, как показано на рис. 1.8.

Рис. 1.8. Сценарий, иллюстрирующий применение профиля TC54

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

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

Рис. 1.9. Стек протоколов конечной системы, реализующей профиль TC54

многочастевой стандарт ISO 9314 FDDI LAN, определяющий базовые протоколы сетевой технологии FDDI;

стандарт для подуровня управления логическим каналом - LLC типа 2 (ISO/IEC 8802-2), т.е. с сервисом, ориентированным на соединение;

протокол и сервис сетевого уровня OSI (X.25) - ISO/IEC 8208 и ISO/IEC 8878, соответственно;

протокол транспортного уровня OSI - ISO/IEC 8073.

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

Экономическая целесообразность внедрения в практику концепции открытых систем привела к необходимости разработки профилей, играющих роль нормативно-методических документов на государственном уровне или на уровне отдельных отраслей и организаций. Такие профили мы назвали стратегическими. В системе стандартов POSIX такие профили называются профилями организаций (“Organization specific profiles”).

Примерами стратегических профилей, как уже отмечалось, являются: GOSIP - Government's Open Systems Interconnection Profile), IGOSS (Industry/Government Open Systems Specifications), APP (Application Portability Profile).

Спецификации GOSIP (правительственные профили взаимосвязи открытых систем) определяют техническую политику в области сетевых технологий на уровне государств и ориентированы на применение в госбюджетных организациях. Наибольшая активность в разработке правительственных профилей приходилась на конец 80-х - начало 90-х годов. В СЩА за разработку и сопровождение спецификаций GOSIP несет ответственность национальный институт стандартизации и технологий NIST, который периодически обновляет версии GOSIP. Свои правительственные профили имеют многие развитые страны, в том числе: США, Великобритания, Франция, Япония, Австралия, Швеция и др.

Разработка IGOSS представляет собой попытку взаимного согласования стратегических профилей правительства США, Канады, разработчиков проекта электротехнической промышленности UCA (Utility Communication Architecture), а также пользователей стандартов MAP и TOP (разработанных корпорациями General Motors и Boing в соответствии с моделью RM OSI). Версии IGOSS переиздавались примерно каждые два года.

Для более полной методологической поддержки целей открытости американским институтом стандартов NIST разработан и периодически обновляется профиль переносимости приложений APP, основным предметом рассмотрения которого является функциональная среда открытых систем. В APP такая среда формируется на основе спецификаций POSIX, GOSIP, TCP/IP, а также других спецификаций, обеспечивающих функциональные возможности, необходимые для удовлетворения разнообразных потребностей в области открытых систем. Спецификации APP ориентированы на менеджеров и руководителей проектов, которые несут ответственность за приобретение, развитие и эксплуатацию информационных систем, поддерживаемых неоднородными аппаратными, программными и коммуникационными платформами. 100 100