Что такое структура файла обмена

Обновлено: 04.07.2024

Презентацию к данной лекции Вы можете скачать здесь.

Введение

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

Понятие файла
Методы доступа
Структура директорий
Монтирование файловых систем
Общий доступ к файлам
Защита файлов
Принципы реализации файловых систем
Блок управления файлом.

Понятие файла

Файл (file) – это смежная область логического адресного пространства. Как правило, файлы хранятся во внешней памяти.

Немного о терминологии. Слово файл уже несколько десятков лет используется как русское – один из многочисленных примеров программистских неологизмов. Первоначально, когда около 50 лет назад появился данный английский термин, в русскоязычной литературе специалисты пытались ввести другую терминологию – слово file переводили как фонд и даже тека (в смысле хранилище ). Однако исторически сложилось иное решение – слово файл стало русским. В английском языке слово file имеет много других значений: например, подшитый в папку бумажный документ и даже стадо (например, слонов) – в последнем случае, как можно предположить, размер "файла" может быть очень велик. У всех в памяти название легендарного сериала " X files" (в вольном русском переводе – "Секретные материалы").

Фирма IBM в документации по своей системе IBM 360 в 1960-х гг. использовала иной термин – набор данных (data set) – для обозначения этого же понятия, однако он не пережил операционную систему, в которой использовался.

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

Структура файла

В различных системах приняты различные точки зрения на структуру файлов. В ряде систем структура файла привязывалась к типу устройства, на котором он находится. В некоторых других системах структура файла была искусственно усложнена. Однако наиболее простую и унифицированную точку зрения из них предложили авторы системы UNIX : файл – это последовательность слов или байтов. Казалось бы, это очевидно, но преимущество данного подхода к файлам в том, что базовое представление файла и базовые операции над ним ( read , write ) не зависят от типа устройства. В свое время для программистов нашего поколения такой подход к файлам был откровением, после сложностей системы файлов IBM 360, а затем – "Эльбруса". Можно сказать, что файлы в своем развитии прошли путь , аналогичный развитию архитектур компьютеров – сначала в сторону значительных усложнений, затем – упрощения и унификации .

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

Файлы простой структуры состоят из последовательности записей (records) – элементарных единиц, в терминах которых выполняются операции обмена с файлом. Записи могут быть:

строками, если это текстовый файл ;
двоичными данными фиксированной длины ;
двоичными данными переменной длины.

Файлы сложной структуры могут быть самого разного вида, например:

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

Файлы интерпретируются операционной системой или программами их обработки.

Атрибуты файла

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

Различаются следующие основные атрибуты файла :

Имя (Name) – название файла в символьной форме, воспринимаемое пользователем.

Тип (Type) – тип хранимой в файле информации. Отдельный атрибут тип необходим для систем, которые поддерживают различные типы файлов. Например, в системе "Эльбрус" значением атрибута тип файла является число, кодирующее тип: 0 – данные, 2 – код, 3 – текст и т.д. Однако более общепринятым подходом является подход, принятый в системах MS DOS , Windows , UNIX : тип файла кодируется расширением имени, например, book.txt – текстовый файл (.txt), содержащий текст книги.

Размещение (Location) – указатель на размещение файла на устройстве.

Размер (Size) – текущий размер файла .

Защита (Protection) – управляющая информация , задающая полномочия чтения, изменения и исполнения файла.

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

В ОС UNIX дату модификации файла можно изменить командой touch f , где f – имя файла . Touch дословно означает потрогать. Кроме изменения времени модификации, больше никаких действий над файлом не производится.

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

Информация о файлах хранится в структуре директорий ( или справочников - directories),иногда, например, в системе Windows , называемых также папками (folders) – структурами во внешней памяти, содержащими символьные имена файлов и ссылки на них. Важнейшая концепция директории подробно рассматривается далее в данной лекции.

Операции над файлами

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

Создание файла ( Create ). Создается заголовок файла; первоначально его содержимое (память) пусто.
Запись в файл ( Write ). Как правило, происходит записями (records) или блоками – более крупными логическими единицами информации, объединяющими несколько записей, с целью оптимизации операций ввода-вывода .
Чтение из файла ( Read ). Обычно также выполняется записями или блоками.
Поиск позиции внутри файла (позиционирование) ( Seek ). Позиция задается номером записи или блока, либо специальными именами, обозначающими начало файла (позиция перед первой записью) или конец файла (позиция после последней записи).
Удаление файла ( Delete ). В зависимости от реализации системы файлов, ошибочное удаление файла может быть фатальным (UNIX) или исправимым (MS DOS).
Сокращение файла ( Truncate ).
Открытие файла ( Open ) – поиск файла в структуре директорий по его символьному имени (пути) и считывание его заголовка и одного или нескольких смежных блоков в буфера в основной памяти.
Закрытие файла ( Close ) – запись содержимого буферов в блоки файла; обновление файла во внешней памяти в соответствии с его текущим состоянием; освобождение всех структур в основной памяти, связанных с файлом.

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

В далеком 2001 году, консорциум W3C выработал рекомендации языка определения схем XML (XSD), объединив наиболее популярные языки описания схем в один стандарт. Основная цель, которая при этом преследовалась – получение платформо-независимого стандарта, который могут использовать все участники информационного обмена. Обуздав хаос, XML стал самым привлекательным форматом информационного обмена. В наши дни XML формат в информационных технологиях используется очень широко, выйдя далеко за рамки простого обмена данных.

2. Проблематика

Если же Вы связаны с разработкой приложений со слабосвязанными или распределенными компонентами в сервис-ориентированной архитектуре, Вам знакомы понятия SOA (service-oriented architecture) и SOAP (Simple Object Access Protocol), то очень скоро наступит момент, когда Вы сами будете нуждаться в актуальной документации больше, чем Ваш заказчик.

Поэтому вопрос «Нужна ли документация?» имеет однозначный ответ «Да», рано или поздно с этим столкнется каждый, кто связан с разработкой ПО, использующего XML.

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

Решают эту задачу по-разному. Кто-то (например, разработчики oXygen) пошел по пути полного описания XSD схемы. В результате чего описание становится еще более сложным для понимания, чем сама схема. Другие стоят на том, что все должны уметь читать XSD схемы и никакой документации не нужно – иногда только потому, что понимают, что они не в состоянии поддерживать актуальность этой документации. Как всегда, истина лежит где-то посередине…

3. Суть проблемы

И вот тут у него возникает дилема: внести только те изменения, о которых сообщил ему архитектор или крыжить все схемы, у которых изменился размер файла. Любой, даже самый добросовестный работник выберет первый вариант – и будет неправ. Этот вариант не работает! – в схемах очень часто присутствуют незаявленные изменения, о которых архитектор или разработчик забывает сообщить и при таком подходе описание форматов неизбежно разойдется со схемами. Чем это грозит? – когда начнется разработка, расхождение обнаружится, что внесет толику хаоса и в разной степени усложнит разработку всем командам, участвующим в интеграции.

Каково же решение? Увы – остается единственный вариант – крыжить каждый раз, все изменившиеся схемы. Это принять очень непросто. Документ с альбомом форматов может занимать не одну сотню листов и прокрыжить его, это очень тяжелый и кропотливый труд. Очень часто, на того, кто разрабатывает этот документ оказывает сильное давление срочность выполнения. Не все понимают, почему изменить описание нескольких элементов в нескольких схемах может «стоить» целый рабочий день или еще больше.

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

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

Документирование структуры элементов одной или нескольких XSD схем с заполненным «documentation» – это самый простой вариант, когда мы формируем документ из одного источника информации (XSD схемы). Обычно это схемы, которые разработаны внутри команды в рамках текущей работы. Идеально, если разработка ведется с учетом соглашения о разработке схем, в котором указано, не только то, что элементы схемы должны документироваться, но и каким именно содержанием и формулировками.
Документирование структуры элементов одной или нескольких XSD схем с незаполненным «documentation», либо заполненным частично – этот вариант посложнее. Это схемы, которые разработаны другими командами. Часто такие схемы регулярно приходят со стороны «As is» и мы не можем предъявлять к ним какие-либо требования. В этом случае из самой схемы может быть взята только структура, а описание элементов нужно добавлять ручками.
Сравнение структуры элементов XSD схем разных версий – у нас есть схемы и их описание, и вот схемы поменялись и нужно актуализировать описание либо получить информацию об изменениях. Схемы могут меняться как значимо, когда добавляются или удаляются элементы, так и чисто косметически, когда в каком-то комментарии убрали лишний пробел и изменилась контрольная сумма файла. Отдельно нужно отметить случай, когда схема переписывается с использованием другого шаблона – в этом случае с точки зрения данных ничего не меняется, но узнать в новой схеме старую можно только потратив на это много времени или используя специальное ПО. С учетом того, что схемы могут приходить пачками из сотен штук, становится понятно, что сравнивать схемы глазками очень сложная и ресурсоемкая работа.

"№ п/п" — здесь показано позиционирование элемента на схеме в виде многоуровневого списка.
«Наименование элемента и его тип» — здесь показаны данные, идентифицирующие элемент – наименование элемента и его тип.
«Описание элемента» — здесь показаны бизнес данные по элементу – его описание с точки зрения бизнеса.
«Правила заполнения» — здесь показаны технические данные: правила заполнения элемента, формат данных, примеры значений и т.д.
«Мн.» — здесь показана мощность элемента – обязательность, множественность и возможность выбора элемента.

5. Поиск решения

Исходя из сценариев использования и требуемого результата сформировались основные требования к функциям инструмента, который должен автоматизировать эту активность:

Генерация описания форматов элементов для выбранной XSD схемы.
Генерация описания форматов элементов для всех XSD схем в выбранной папке и ее дочерних папках.
Сравнение описания форматов элементов для выбранной схемы (либо схем в папках) и ее предыдущей версии.
Обогащение описания форматов элементов в выходном документе с использованием описаний элементов, заданных в отдельном файле.
Приведение описания форматов элементов к единому виду в структуре шаблона «Матрешка», независимо от использованного шаблона при проектировании XSD схем.

Однако, проблема была как никогда актуальна и такой инструмент был создан…

6. Решение

6.1. Пример обработки документированной схемы

Здесь показан результат описания форматов элементов, полученного из XSD схемы с заполненным «documentation».

6.1.1. Исходная схема

6.1.2. Полученный результат

6.2. Пример использования внешнего описания

Здесь показан результат описания форматов элементов, полученного из XSD схемы с незаполненным «documentation».

6.2.1. Исходная схема

6.2.2. Данные файла внешнего описания

6.2.3. Полученный результат

Обратите внимание, что полученный результат полностью идентичен результату обработки документированной схемы!

6.3. Пример сравнения двух схем

Здесь показано описание форматов элементов, полученного при сравнении разных версий XSD схемы.

6.3.1. Исходная схема

6.3.2. Предыдущая версия схемы

6.3.3. Полученный результат

У новых элементов «FirstName», «LastName» и «Zip» выделены жирным шрифтом все колонки. У элемента «Address» изменилась позиция – жирным шрифтом выделена только первая колонка. Удаленные элементы «FullName» и «Country» выделены серым шрифтом. Также «читать» изменения помогает фон строк.

Данное представление делает отличия легко читаемыми как на экране, так и в печатном виде.

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

Основные способы интеграции приложений:

• Обмен файлами
• Обмен через общую базу данных
• Удаленный вызов функций
• Сервисная шина предприятия (MQ, ESB)

Обмен файлами

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

К плюсам интеграции через обмен файлами следует отнести:

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

Однако у этой схемы есть и несколько важных ограничений, которые надо учитывать при разработке интеграционной модели:

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

• Для ухода от первой проблемы довольно часто применяется подход, когда для каждого потребителя формируется отдельный файл. Но в этом случае мы получаем сразу несколько новых проблем: увеличение объема данных, формируемых системой-источником, увеличение исходящего трафика и увеличение временных задержек на размещение файлов в общих папках. Есть и еще одна проблема при таком подходе: чтобы правильно сформировать файлы, система-источник должна четко себе представлять, кто будет потребителем этих данных по каждому типу данных.

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

• Обмен выполняется по принципу «точка-точка». Достаточно сложно централизованно проследить маршруты и историю прохождения данных. Затруднено централизованное управление интеграционной моделью.

Обмен через общую базу данных

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

К основным плюсам можно отнести:

• Встроенные механизмы СУБД для разграничения доступа к конкурентным данным. Данные не могут быть прочитаны или изменены до завершения процедуры записи.

• Единые механизмы записи и считывания данных. Все приложения оперируют стандартными механизмами СУБД по работе с данными. Это позволяет организовать единые подходы к разработке и внесению изменений.

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

• Более высокая скорость доставки данных относительно файлового обмена. В этой схеме не требуется выделять регламентные периоды доступа к данным – они могут быть прочитаны сразу после их фиксации в БД.

• Встроенные механизмы СУБД для протоколирования доступа к данным позволяют проводить расследования о причинах того или иного отклонения при доставке.

К недостаткам схемы относим:

• Единая БД является точкой отказа для всего интеграционного контура. Выход из строя единой БД приводит к невозможности функционирования интеграционной схемы в целом. Приложения должны обеспечивать собственные механизмы накопления неотправленной информации и механизмы контроля состояния доступа к интеграционной БД.

• При высокой интенсивности обмена сама интеграционная БД может стать узким местом. Появляется конкурентность доступа к данным, возможны возникновения блокировок на изменения данных.

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

• Работа с единым форматом приводит к более высоким требованиям при проектировании схемы интеграционной БД, так как хранимые данные должны удовлетворять всех участников интеграционного процесса. Данные должны храниться в форматах и структурах, которые могут быть однозначно прочитаны всеми участниками интеграционных процессов.

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

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

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

Удаленный вызов функций

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

Для реализации такого подхода могут использоваться следующие технологии, предоставляющие механизмы удаленного вызова процедур:

• COM
• CORBA
• SOAP
• Java RMI и т.д.

В этом случае приложение должно самостоятельно реализовывать механизмы предоставления удаленного доступа к данным.

К основным плюсам подхода следует отнести:

• Отсутствие необходимости организовывать промежуточное хранилище данных. Системы-потребители самостоятельно запрашивают данные по мере возникновения такой потребности.

• Согласованность данных. Система-источник выполняет предварительную подготовку данных, включая всю функциональность по обеспечению целостности данных.

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

• Возможность организовывать схемы «вытягивания» и «выталкивания» данных. В первом случае система-источник предоставляет необходимую функциональность по получению данных, а системы-подписчики осуществляют ее вызов по мере возникновения необходимости в получении данных. Во втором случае системы-источники предоставляют функционал для загрузки данных; передачу осуществляет система-источник при возникновении соответствующего события.

К недостаткам подхода следует отнести:

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

• При масштабировании интеграционного ландшафта требуется доработка систем-источников и систем-потребителей.

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

• Из-за разности технологий системы могут оперировать различными структурами и типами данных. Появляются дополнительные расходы на преобразование данных.

• При высокой интенсивности обмена приложение начинает тратить все больше ресурсов не на обслуживание своих бизнес-процессов, а на обслуживание интеграционного слоя.

Сервисная шина предприятия

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

Основными плюсами системы являются:

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

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

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

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

Основными недостатками модели принято считать:

• Дополнительные затраты на приобретение и поддержку специализированных программных продуктов (MQ, ESB). Зачастую необходимо выделение дополнительных серверных ресурсов.

• Необходимость проведения обучения персонала по этим программным продуктам.

Критерии выбора способа интеграции

Каковы же критерии выбора того или иного способа интеграции? Можно выделить несколько основных критериев, однако стоит учитывать, что вес того или иного критерия определяется текущими условиями и решаемыми задачами:

• Возможность всех приложений интеграционного контура использовать выбранный способ интеграции

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

• Возможность внесения изменений в приложения

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

• Требования к обеспечению надежности

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

• Уровень связанности приложений

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

• Временные задержки доставки данных

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

• Требования к защите данных

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

Выводы

Если применить критерии выбора к ранее рассмотренным шаблонам интеграции, то можно сформулировать следующие выводы:

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

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

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

ГОСТ 28270-89
(ИСО 8211-85)

Системы обработки информации

СПЕЦИФИКАЦИЯ ФАЙЛА ОПИСАНИЯ ДАННЫХ ДЛЯ ОБМЕНА ИНФОРМАЦИЕЙ

Information processing systems. Specification for a data descriptive file
for information interchange

Дата введения 1990-07-01

М.М.Ефимова; А.А.Мкртумян; О.А.Антошкова; Ю.А.Васильев; Н.А.Чельцова; В.И.Федосимов

2. Постановлением Государственного комитета СССР по стандартам от 27.09.89 N 2942 стандарт Совета Экономической Взаимопомощи СТ СЭВ 6366-88 "Системы обработки информации. Спецификация файла описания данных для обмена информацией", в качестве которого непосредственно применен международный стандарт ИСО 8211-85, введен в действие непосредственно в качестве государственного стандарта СССР с 01.07.90

3. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

Раздел, подраздел, пункт,
в котором приведена ссылка

Обозначение международного стандарта

Обозначение соответствующего отечественного нормативно-
технического документа

0; 3; 4.1; 4.19; 4.35; 5.2.1.9; 6.2.1; 7.1; приложения А; В

3; 4.18; 5.2.1.4; 7.1; приложения А; В

4. ПЕРЕИЗДАНИЕ. Январь 2006 г.

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

Стандарт определяет средства формального описания данных различной структуры и типа независимо от их содержания.

В целях обеспечения международного обмена информацией в качестве государственного стандарта "Системы обработки информации. Спецификация файла описания данных для обмена информацией" принят стандарт ИСО 8211 методом прямого применения с учетом опечаток и неточностей, приведенных в приложении 1 (в аутентичном тексте стандарта помечены знаком "*").

СПЕЦИФИКАЦИЯ ФАЙЛА ОПИСАНИЯ ДАННЫХ ДЛЯ ОБМЕНА ИНФОРМАЦИЕЙ

В качестве описания спецификации файла описания данных для обмена информацией следует использовать международный стандарт ИСО 8211.

АУТЕНТИЧНЫЙ ТЕКСТ МЕЖДУНАРОДНОГО СТАНДАРТА

0. ВВЕДЕНИЕ

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

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

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

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

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

В управляющих полях файла обмена необходимо использовать набор кодированных символов по стандарту ИСО 646 (международная справочная версия по ГОСТ 27463), в полях данных пользователя допускается применять расширенные наборы символов.

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

Первый уровень поддерживает множество полей, содержащих простые, неструктурированные строки символов.

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

Третий уровень поддерживает второй уровень и иерархические структуры данных.

Примечание. Дополнительная информация по применению настоящего стандарта приведена в приложении А.

1. НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ

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

1) независимые от носителя данных файл и описания записей данных для обмена информацией. Он также предполагает использование других международных стандартов по структуре и разметке файлов, таких, как ИСО 1001 (ГОСТ 25752), ИСО 4341 (ГОСТ 28104), ИСО 7665 (ГОСТ 28081);

2) описание элементов данных: векторов, массивов и иерархий, содержащих строки символов, строки битов и числовые формы.

Числовые формы определены в ИСО 6093;

3) файл описания данных, включающий в себя запись описания данных и сопутствующие ей записи данных, которые позволяют обмениваться информацией с минимальным специфичным внешним описанием;

4) запись описания данных, которая характеризует поле данных в пределах сопутствующих записей данных;

5) три уровня обмена в зависимости от сложности допустимой структуры данных (по п.5.2.1.2).

2. СООТВЕТСТВИЕ

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

Настоящий стандарт не устанавливает требования к обработке и реализации, поэтому сама эта обработка не может ему соответствовать.

3. ССЫЛКИ

ИСО 646 Обработка информации. 7-битный кодированный набор символов ИСО для обмена информацией.

ИСО 1001 Обработка информации. Структура и разметка файла на магнитной ленте для обмена информацией.

ИСО 4341 Обработка информации. Структура и разметка файла на кассетах и катушках с магнитной лентой для обмена информацией.

ИСО 6093 Обработка информации. Представление числовых значений в строках символов для обмена информацией.

ИСО 7665 Обработка информации. Структура и разметка файла на гибком магнитном диске для обмена информацией.

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

4. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

В настоящем стандарте применяются следующие термины и определения*

* Алфавитный указатель терминов на русском языке и их эквиваленты на английском языке приведены в приложении 2.

4.1. Буквенно-цифровой символ: символ, встречающийся в колонках 2-7 включительно (кроме позиции 7/15) международной ссылочной версии ИСО 646 (ГОСТ 27463).

Примечание. Символы, определенные в настоящем стандарте, представлены их позицией (колонка/ряд) в таблице кодированного набора символов по ИСО 646 (ГОСТ 27463) или их акронимами (обозначениями по ГОСТ 27465), например, АР2, РЗ, РЭ.

4.2. Описатель массива: последовательность чисел, определяющая размерность и величину массива.

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

4.4. Поле битов: поле данных, содержащее только двоичные цифры и, при необходимости, выравниваемое влево двоичными нулями до границы байта (см. также термин "строка битов в символьном режиме").

4.5. Байт: набор n битов.

Примечание. Положения настоящего стандарта не зависят от носителя (среды), а число битов зависит от носителя.

4.6. Декартова метка: массив идентификаторов, образованный декартовым произведением элементов двух (или более) векторных меток. Элементы массива имеют тот же порядок, что и элементы прямого произведения, так что, если и - векторные метки = [а(1). а (n)] и = [b(l), . . . , b (m)], то декартова метка · = [а(1) b(1), а(1) b(2). а(1) b(m). a(n) b(m)], где a(i) b(j) - соединение a(i) и b(j), которое образует идентификатор элемента i, j соответствующего массива данных.

4.7. Строка битов в символьном режиме: последовательность символов (0 или 1), представляющая строку двоичных цифр (см. также термин "поле битов").

4.8. Составное поле данных: поле, содержащее один или несколько неделимых элементов данных.

4.9. Файл описания данных (ФОД): файл, содержащий запись описания данных и относящиеся к ней записи данных.

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

4.11. Запись данных (ЗД): логическая запись, содержащая данные, являющиеся объектом обмена (данные пользователя).

4.12. Структура с разделителями: структура, образованная набором элементов данных, ограниченных разделителями.

4.13. Разделитель: единичный символ, разделяющий элементы данных и поля данных (использование разделителей по табл.1).

4.14. Справочник: таблица меток полей и ссылок на соответствующие поля данных.

4.15. Статья справочника: поле фиксированной длины в справочнике, содержащее информацию о конкретном поле в записи: метке поля, длине и местоположения поля.

4.16. Элементарный: неделимый без потери смыслового значения.

4.17. План статьи: поле в ведущей метке, используемое для указания структуры статей справочника.

4.18. Управляющий символ АР 2: символ, обеспечивающий возможность использования дополнительных символов. Меняет значение ограниченного набора следующих непосредственно за ним комбинаций битов. Использование этого символа определено в ИСО 2022 (ГОСТ 27466).

Читайте также: