Понятие XML/EDIM
А.Календарев, www.citforum.ru
Введение в EDI
Цель данного обозрения - дать общее понятие о системах обмена электронными документами, перспективы их развития и интеграции с новыми технологиями. Также показать практическую возможность использования систем XML/EDI в такой новой отрасли, как электронная коммерция.
Сегодня, в сфере бизнеса создается и обрабатывается внушительный объем разнообразной бумажной документации. Она включает в себя заказы на приобретение, счета, каталоги, отчеты, платежные поручения и т.д.
Американской фирмой IMC (International Marketing Company) были проведены исследования по изучению бумажных потоков подготовки и оформления документов участников международной торговли. В результате исследования оказалось, что в общей сложности все участники внешнеэкономической деятельности в рамках одной поставки (партии товаров) оформляют 40 документов-оригиналов и 360 копий.
Можно выделить следующие типы взаимодействия информационных систем:
Произвольное взаимодействие между двумя отдельными компьютерами, например по модему. Обязательное участие оператора на принимающей и передающей стороне. Возможен обмен в произвольном, но заранее оговоренном формате;
Интерактивное удаленное взаимодействие компьютера с информационной системой, например по протоколу http. Оператор на передающей стороне. Как правило используется определенная форма HTML документа. Принимаемые документы обрабатываются автоматически;
Контролируемая потоковая обработка, например прием по e-mail, файл содержащий HTML форму, запуск которой инициирует процесс обработки документа или прием оператором по e-mail электронных документов в оговоренном формате и далее запуск запуск программы обработки. Требует обязательный контроль оператора на принимаемой стороне;
Полностью автоматизированный процесс приема и обработки электронных документов в оговоренном формате. Участие операторов не требуется.
В статье подробее будет сакцентированно внимание на создание и основные принцыпы организации последнего типа взаимодействия, называемого Электронным обменом данными (Electronic Data Interchange или EDI).
В чем же состоит преимущество систем EDI? Сегодня, большая часть данных, содержащихся в коммерческих документах, генерируется их существующих компьютерных прикладных программ. Типовая схема оформления торговых сделок предполагает следующие действия:
для осуществления торговых операций сформируется бумажный документ;
данный документ передается по каналам факсимильной связи или дригим каналам передачи данных адресату;
деловой партнер, получивший электронный документ электронным способом воспроизводит его на бумаге и использует в дальнейшем для отчета;
с принятого бумажного носителя вручную осуществляет ввод необходимых данных в информационную систему своего ведомства;
На основе принятой информации генерируются новые бумажные документы и передаются в иные ведомства.
По данным исследования IMC внедрение EDI-систем позволяет снизить расходы, связанные с составлением документов до 7-10% от общей стоимости сделки. Мировая практика электронной коммерции, основанной на системах-EDI осуществляется уже более 30 лет и представляет собой определенный стандарт выполнения торговых операций и представление структурированных деловых документов.
Коренное отличие систем EDI от систем электронного документооборота состоит в том, что EDI системы - это межведомственные системы обмена электронныими документами, использующие строго стандартизированные правила составления электронных документов. А система электронного документооборота - это системы, как правило, разрабатываемые в рамках одной кропорации или предприятия, обмен в которых осуществляется по средствам распределенных СУБД типа ORACLE или INFORMIX.
Существует много разных определений EDI, но мы привидем наиболее подходящее для наших целей: "передача между информационными системами электронным способом структурированных сообщений в согласованном стандарте".
При помощи технологии EDI данные из корпоративных компьютерных систем переводятся на понятный всем стандарт и передаются по надежным телекоммуникационным каналам, как правило, по корпаротивной сети передачи данных.
В настоящее время в системах EDI широко используются около двенадцати стандартов, но наибольшую популярность прибрели два стандарта: UN/EDIFACT и ANSI X-12. Так например, в США оклоло 500 тыс. пользователей EDI обмена в формате UN/EDIFACT, и такое же количество пользователей формата ANSI X-12.
Для упорядочивания разностандартных EDI систем, в 1996 году Экономическим и Социальным советом ООН была выпущена Рекомендация №25 по использованию стандарта EDIFACT, в которой рекомендовано модернизировать существующие EDI-системы в системы, ориентированные на использование UN/EDIFACT, а вновь создоваемые системы изначально строить на основе использования UN/EDIFACT.
Акроним UN/EDIFACT расшифровывается как "Правила ООН эелектронного обмена документами для гос. управления торговли и транспорта" (United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport).
В настоящее время из-за отсутствия законодательного регулирования процессов электронного обмена документами полномасштабное развитие систем EDI в нашей стране затруднено. Но лавинообразное развитие в мире систем электронной коммерции раскачивает официальные органы и жизнь заставлляет использовать параллельно с бумажными документами и их электронный образ.
В качестве примера можно привести использование стандарта UN/EDIFACT в международных банковских системах обмена информацией SWIFT. Следующие примеры использования электронных документов в стандарте UN/EDIFACT: EDI-система контроля сопровождения груза из стран ЕС до терминала назначения в таможенных органах Российской Федерации.
Государственный таможенный комитет (ГТК РФ) реализует проект взаимодействия с информационной системой МПС (Министерства путей сообщения), где для обмена электронными документами используется стандарт UN/EDIFACT. В ГТК разрабатывается проект обмена электронными документами с информационными системами крупных портов мира стран Балтийского моря с таможней в морском порту Санкт Петербург и портов Тихого океана США (Сиетл и Сан-Франциско) с таможней в морском порта Находка и Владивосток.
В МПС реализован проект взаимодействие EDI-систем Октябрьской железной дороги и Финляндских государственных железных дорог (VR cargo).
1. Обзор стандарта UN/EDIFACT
При разработке стандартов электронного документооборота была проведена работа по исследованию использования всех данных "бумажных" документов, используемых во внешнеэкономической деятельности. Как выяснилось, большинство документов содержат повторяющиеся данные, и даже целые группы данных.
Например, название и адрес фирмы отправителя встречается как в счете-фактуре, транспортно-сопроводительных документах - CMR, так и в таможенной декларации.
Было предложено выделить наиболее повторяющиеся группы данных, и в них выделить соответствующие поля данных. В последствии оказалось, что данные так часто повторяются, что для их заполнения было разработано более 200 специальных кодировочных таблиц - называемых справочники данных.
Часть справочников (такие как трехзначные коды стран мира, коды валют) использовались до появления стандартов UN/EDIFACT. Эти справочники были пересмотрены и скорректированы с точки зрения использования их в новых стандартах.
В основу стандарта UN/EDIFACT положены следующие принципиальные идеи:
Обмен осуществляется сообщениями;
Стандартизация по типу используемого документа на уровне сообщений;
Сообщение имеет иерархическую структуру и состоит из сегментов;
Стандартизация данных на уровне сегментов и элементов данных;
Сегменты могут групироваться по некоторому признаку;
Незаполненные (пустые) сегменты могут опускаться;
Типовые поля записываются в виде кода;
Состав и наполнение справочников стандартизуется на трех уровнях - международном, национальном и корпаротивном;
Независимость стандартов от языка, используемого для общения.
Группа сегментов кроме типовых сегментов данных может содержать другие группы сегментов.
Сегменты в группе сообщений могут повторяться некоторое количество раз. Также незаполненные (пустые) сегменты могут опускаться.
Стандартом предусмотрено около 200 различных типов сегментов, из которых составляется сообщение.
На рис. 1 Представлен фрагмент структуры сообщения, на котором видно, как объеденены в группу SG. 8 сегменты TDT-LOC и MEA-EQN которые в свою очередь объединены в группу SG.9 В группе, порядок следования сегментов строго упорядочен, но они могут повторяться, например:
TDT- LOC
MEA-EQN
MEA-EQN
TDT- LOC
MEA-EQN
Первый раз, в группе SG.9 сегменты MEA-EQN повторяются два раза, второй раз - один. В группе SG.8 - сегменты TDT- LOC повторяются - два раза.
Сегменты данных состоят из элементов данных, которые могут быть простыми (аналогом является поле данных) и составными (обычно 2-3 поля данных).
На конец 1999 года разработано более 170 стандартных сообщений. Стандартом предусмотрено, что каждое сообщение имеет уникальный 6-значный код из заглавных букв, а каждый сегмент данных имеет 3-значныный код из заглавных букв.
По правилам UN/EDIFACT не предусмотрено использование символов перевода строки и возврата каретки, но для наглядности на каждой строчке расположен отдельный сегмент. Ниже, для примера, показано разобранное на сегменты сообщение ORDERS в стандарте UN/EDIFACT.
| UNH+000002+ORDERS:D:96A:UN:EAN008' | Заголовок Сообщения |
| BGM+220+B00002+9' | Номер заказа |
| DTM+137:19940202:102' | дата отправки сообщения |
| NAD+BY+++Stadt- und Universitaetsbibliothek | Имя и адрес покупателя |
| :Frankfurt+Bockenheimer Landstr. 134-13 8+Frankfurt++60325' RFF+API:DE1141110388' | Идентификатор покупателя |
| NAD+SU+++DREIER' | Наименование поставщика |
| CUX+2:DEM:9' | Валюта оплаты |
| LIN+1' | Позиция заказа 1 |
| PIA+5+3772815359:IB' | Идентификатор ISBN заказа |
IMD+F+050+:::Die "Jahrbuecher fuer wissensc
haftl:iche Kritik"'
IMD+F+060+:::Hegels Berliner Gegenakademie'
IMD+F+065+:::Hrsg. von Christoph Jamme'
IMD+F+110+:::Stuttgart-Bad Cannstadt'
IMD+F+120+:::Frommann-Holzboog'
IMD+F+170+:::1994'
IMD+F+190+:::Spekulation und Erfahrung'
IMD+F+191+:::Abt. 2'
IMD+F+192+:::Untersuchungen'
IMD+F+194+:::Bd. 27'
IMD+F+220+:::Gewebe' | Подробности описания товара |
| QTY+21:1' | кол-во копий заказа |
| PRI+AAE:295:CA' | Цена заказа в Нем. марках |
| UNS+S' | Разделительный сегмент |
| CNT+2:1' | Общее кол-во позиций - 1 |
| UNT+25+000002' | Общее кол-во сегментов = 25 |
Сегменты, составляющие сообщение, начинаются с трехбуквенного имени, например UNA, UNH, BGM, DTM и т.д. Оканчивается сегмент символом окончания сегмента - в данном примере апострофом.
Ниже приведены названия некоторых сегментов:
| BGM | BEGINNING OF MESSAGE | НАЧАЛО СООБЩЕНИЯ |
| CUX | CURRENCIES | ВАЛЮТА |
| DTM | DATE/TIME/PERIOD | ДАТА/ВРЕМЯ/ПЕРИОД |
| IDM | ITEM DESCRIPTION | ОПИСАНИЕ ПУНКТА |
Каждый сегмент состоит из элементов данных. В отличие от имени сегмента, имя элементов данных не указывается в сообщении. Элементы данных разделены разделителями которым является символ "плюс". Так, например сегмент NAD+BY+++Stadtund Universitaets bibliothek:Frankfurt+Bockenheimer.Landstr.134 -138+Frankfurt++ 60325'
Состоит из следующих элементов данных:
| Первый элемент | BY |
| Четвертый элемент | Stadt-und Universitaetsbibliothek:Frankfurt |
| Пятый элемент | Bockenheimer.Landstr.134-138 |
| Шестой элемент | Frankfurt |
| Восьмой элемент | 60325 |
Каждый из элементов данных занимает свое определенное место в сегменте. Если какой-либо из элементов данных не требуется, то для его пропуска повторяют разделитель элементов данных (см. в примере - между первым и четвертым элементом расположено три разделителя). Назначение того или иного элемента данных определяется справочником сегментов EDSD, который входит в набор стандартов UN/EDIFACT.
Элементы данных могут быть простыми и составными, состоящими из компонентов. Для составных элементов данных предусмотрен еще один разделитель - в данном случае "двоеточие". Четвертый элементы данных в вышеприведенном примере, являются составными, части которого разделены символом ":" Последовательность элементов данных в сегменте регламентируется справочником элементов данных и строго определена.
2. Основы XML и объектная модель представления данных
Бурное развитие Интернет технологий вовлекло в международную паутину миллионы пользователей. Требования к электронному обмену возросли, и уже существующий протокол HTML многие группы пользователей перестал удовлетворять.
В начале февраля 1998 г международная организация W3C утвердила спецификацию "Extensible Markup Language(XML) 1.0". Уже сегодня появляются новые языки, созданные на основе XML. Возникают многочисленные Web-сервера, использующие и технологию XML для организации хранящейся на них информации.
Современные приложения требуют не только более гибкий протокол представления данных, но и механизм, позволяющий определить структуру документа и описывать содержащие в нем элементы.
Язык XML предназначен для создания новых языков разметки. С его помощью можно описать целый класс объектов данных, называемых XML - документами, ориентированными на конкретную предметную область. XML позволяет определить допустимый набор тэгов, их атрибуты и внутреннюю структуру документа. Тэги (подобно тэгам в HTML) представляют специальные инструкции, предназначенные для формирования в документах определенной структуры и четких отношений между различными элементами этой структуры.
Можно выделить следующий круг задач, связанных с созданием и обработкой структурированной информации, для решения которых может использоваться XML:
Разработка сложных информационных систем, с большим количеством приложений, связанных потоками информации самой различной структуры. XML - документы выполняют роль универсального формата для обмена информацией между отдельными компонентами большой программы.
XML является базовым стандартом для нового языка описания ресурсов, RDF, позволяющего упростить многие проблемы в Web, связанные с поиском нужной информации, обеспечением контроля за содержимым сетевых ресурсов, создания электронных библиотек и т.д.
XML может использоваться в обычных приложениях для хранения и обработки структурированных данных в едином формате.
XML позволяет описывать данные произвольного типа и используется для представления специализированной информации.
XML может служить мощным дополнением к HTML для распространения в Web "нестандартной" структуированой информации
XML-документы могут использоваться в качестве промежуточного формата данных в трехзвенных системах при поиске информации в удаленных базах данных. Сегодня на рассмотрение W3C предложена спецификация нового языка запросов к базам данных XQL.
Информация, содержащаяся в XML-документах, может изменяться, передаваться на машину клиента и обновляться по частям. Разрабатываемые спецификации XLink и Xpointer позволятют ссылаться на отдельные элементы документа, c учетом их вложенности и значений атрибутов.
Использование стилевых таблиц (XSL) позволяет обеспечить независимое от конкретного устройства вывода отображение XML- документов и фильтрацию данных.
Тэги языка кодируются и выделяются относительно основного содержимого документа и служат в качестве инструкций для программы, производящей действия над содержимым документа на стороне клиента.
Исторически сложилось таким образом, что в системах для обозначения этих команд использовались символы "<" и ">", внутри которых помещались названия инструкций и их параметры. Сейчас такой способ обозначения тэгов является стандартным.
Например, для создания элемента Ivanov в имене заказчика используется тэг <CustumerName>. В программе это выглядит следующим образом:
<CustumerName> Ivanov </CustumerName>
Определения тэгов может легко расширяться. Так для указания более полных реквизитов заказчика можно определить тег <Custumer>, в который включено не только имя, телефон заказчика, но и адрес компании.
<Custumer>
<CustumerName> Ivanov </CustumerName>
<phone>312-12-13<phone>
<Company>Bussines Trade Consulti</Company>
</Custumer>
Можно создать массив заказчиков, определив тег <Custumers>:
<Custumers>
<Custumer>
<CustumerName> Ivanov </CustumerName>
<phone>312-12-13<phone>
<Company>Bussines Trade Consulti</Company>
</Custumer>
<Custumer>
<CustumerName> Petrov </CustumerName>
<phone>315-15-16<phone>
<Company> Trade Forest Company</Company>
</Custumer>
<Custumer>
......
</Custumer>
</Custumers>
Из приведенного примера видно, что XML - документы подлежат четкой структуризации и имеют четкую иерархическую структуру следования элементов. Элементы имеют своих родителей - корневые элементы и наследников - дочерние элементы.
Документ XML состоит из элементов. Элемент - это структурная единица XML- документа. Заключая данные об имени заказчика в тэги <CustumerName> </CustumerName>, XML-процессор определит как элемент. Содержимым элемента CustumerName является значение. В нашем примере имеется два значения (Ivanov и Petrov) элемента CustumerName.
Контроль за правильностью использования порядка использования элементов осуществляется при помощи специального набора правил, называемых DTD (Document Type Definition)- описаниями, которые используются программой клиента при анализе документа.
Производя в последствии поиск в XML документе, программа клиента будет опираться на информацию, заложенную в его структуру - используя элементы документа, определенные в DTD.
В общем случае XML- документы должны удовлетворять следующим синктатическим правилам:
В заголовке документа помещается объявление XML, в котором указывается язык разметки документа, номер его версии и дополнительная информация;
Каждый открывающий тэг, определяющий некоторую область данных в документе обязательно должен иметь парный закрывающий тэг;
XML учитывает регистр символов;
Все значения атрибутов, используемых в определении тэгов, должны быть заключены в кавычки;
Вложенность тэгов в XML строго контролируется, поэтому необходимо следить за порядком следования открывающих и закрывающих тэгов;
Вся информация, располагающаяся между начальным и конечными тэгами, рассматривается в XML как данные и поэтому учитываются все символы форматирования ( пробелы, переводы строк, табуляции не игнорируются)
В случае, если элемент не содержит данных, т.е. является пустым, то начальный и конечные тэги такого элемента можно объединить в один. При этом не обязательно ставить косую черту перед закрывающей угловой скобкой (например, в вышеприведеном примере отсутствие факса в компании пару тэгов <fax></fax> можно заменить на <fax/>;)
При необходимости, каждому элементу можно задать параметры, уточняющие его характеристики. При этом используются атрибуты эдлемента. Атрибут - это пара "название" = "значение", которую необходимо задавать при определении элемента в начальном тэге. Пример:
<container Type="20f">123456</container > двадцати футофый контейнер
<container Type ="30f ">654321</container> тридцати футофый контейнер
Просмотр XML документов осуществляется специальной программой анализатором. На сегодняшний день разработано около десятка подобных анализаторов. В своем новом броузере Internet Explorer 5 фирма Microsoft уже предусмотрела анализ XML документов.
Анализ документа в Internet Explorer 5 осуществляется тремя вариантами: просмотр аналогично HTML документу, форматирование документа с использованием специальных стилевых таблиц - XSL и анализ с помощью сценариев, написанных на Java Script ил VBScript.
Поиск нужного элемента или поддерева осуществляется при помощи XQL запроса. XQL является частью XML и переволится как язык запросов для XML (XML Query Language). Идет дисскусия об утверждении языка запросов в качестве общепринятого стандарта, который может заменить SQL.
Синтаксис языка запросов очень гибок и позволяет осуществлять поиск элемента как по названию, значению атрибутов, содержанию, так и учитывать вложенность и положение в дереве элементов. При помощи запросов мы можем выделять из общего дерева необходимые нам элементы и применять к ним необходимые инструкции. Запрос возможно применять как к самому XML документу, так и к ссылкам URL.
Язык запросов напоминает обычный способ определения пути к ресурсу- список узлов дерева, разделенных символом "/". Для указания на текущий элемент используется символ "." , на родительский - "..", для выделения всех дочерних элементов - символ "*", для выделения элемента, расположенного просто "ниже" по дереву(не важно на каком уровне вложенности) - "//". Условие на значение в запросе должно заключаться в символы "[" и "]". Для выбора значения атрибута в условии указывается символ @.
Примеры простых XQL шаблонов:
| "/Customer " | корневой элемент |
| "Customers/" | возвращает дочерние элементы для элемента Customers |
| "Customers //" | список всех элементов, вложенных в Customers |
| "container[@Type]" | список элементов container, в котором определен атрибут Type |
| "container[@Type =20f]" | поиск всех двадцатифутовых контейнеров, т.е. элементов container, в котором значение атрибута Type равно "20f" |
| "Customers[address]" | список элементов Customers, которые содержат хотя бы один элемент address, выражение в квадратных скобках может быть составным. |
Как мы видим, XML документ в отличие от EDIFACT сообщения позволяет более наглядно представить объектную модель данных. Использование языка описания XML запросов - XQL позволяет адекватно формализовать любой из существующих "бизнес" запросов (оформленных в виде стандартных документов) для информационных систем.
Разбор XML документов в отличие от EDI-систем возможен стандартными анализаторами, что значительно удешевляет разработку новых информационных систем. Использование встроенных транспортных протоколов делает эти системы полностью совместимыми с существующими программными средствами и WEB технологиями.
Системы XML/EDI
Комбинация XML и EDI предполагает для XML/EDI разработку предложений основных методов описания и кодирования EDI сообщений посредством XML обработки. Формы, обрабатывающие XML документы должны быть согласованы, чтобы осуществлять взаимодействие с существующими XML/EDI системами. Для этого они должны иметь возможность генерировать EDIFACT сообщения, осуществлять их анализ и отображение.
XML/EDI предлагает пользователям, использующих текущие стандарты пути решения возможных проблем и может быть интегрировано в существующие EDI системы путем:
Разработки форм для приложений пользователя, способных генерировать EDI сообщения
Создания форматов EDI сообщения для их передачи между компьютерами по Интернет, или через сети с добавленными услугами (VANs)
Разработки пользовательских шаблонов для интерпретации согласованных правил на компьютере получателя с помощью стандартных программ просмотра (броузеров)
XML/EDI представляет нечто больше, чем прямой перенос XML документов в системы EDI. В рамках построения XML/EDI представляется слияние пяти технологий (XML, EDI, Templates, Agents и Repository), которые существенно расширят существующие возможности информационной системы. Каждый из этих компонент добавляет свои специфические возможности.
Использование технологий XML/EDI реализует следующие цели:
Сделать EDI универсально допустимыми, используя свободно распространяемый код и синтаксис SQL (XQL)
Осуществить разработку "последующих" EDI - сообщений таким образом, чтобы они были полностью совместимы с существующими X12 и UN/EDIFACT стандартами
Осуществление, по возможности, единой трансляции сообщений X12 и UN/EDIFACT
На рис. 2 представлены составные части технологий XML/EDI:
Рис. 2 Составные части XML/EDI технологий
Более подробно про каждую из составных частей:
XML. В основе обмена документами лежат транспортные протоколы, используемые в Интернет. С помощью заранее определенных тэгов определяется объектная модель данных, которая в последствии заполняется данными и передается в качестве электронного документа. Существующее идентификаторы сегментов EDI заменяются тэгами XML, или часть данных из EDI сегмента добавляются в тэги в качестве параметров.
EDI. Разработанные в EDI системах стандарты способны представлять данные в простом формате. Эти данные однозначно интерпретируются на принимающей и передающей стороне. XML/EDI позволит обеспечить 100 % совместимостью с существующими EDI системами, используя при этом обмен EDIFACT сообщениями. Разработка протоколов XML/EDI позволяет использовать уже существующие EDI системы, что не потребует новых капиталовложений для разработки глобальных систем.
Templates (Шаблоны) - это набор определенных правил, которые осуществляют управление процессом, как на клиентской, так и на серверной стороне. С помощью шаблонов можно выразить в XML все особенности процесса, который должен быть выполнен. Шаблон могжет быть загружен как с удаленного источника, откуда пришел XML документ, так и быть его составной частью. Шаблоны используют Document Type Definitions (DTD's), по которым определяется объектная модель данных. Удаленное использование (DTD's) позволит всем клиентским приложениям однозначно определить используемую модель данных.
Agents (Агенты) интерпретируют шаблоны, чтобы интерактивно выполнить необходимые транзакции и взаимодействовать с пользователем. Агенты могут быть реализованы как аплеты Java или внедренные объекты ActiveX. Разбор структуры XML может осуществляться Агентом прямо на компьютере клиента и использовать при этом необходимые для пользователя данные и их представление. Первоначально агенты будут управляться Шаблонами и предоставлять пользователю некоторые дополнительные возможности. Предполагается, что позже будут разработаны соответствующие протоколы для Агентов.
Repository (хранилище) - совместно используемые в Интернете общедоступные словари - которые уже используются в традиционных EDI системах. Данные словари позволяют пользователям найти значение и область определения EDI элементов. Совместно используемые общие словари обеспечивают автоматические поисковые таблицы более гибким механизмом поиска. Данный компонент обеспечит семантическую основу для EDI транзакций.
Можно выделить следующие основные принципы построения XML/EDI:
XML используется как макет " моделирование обмена данными "
XSL используется как уровень "представления"
Возможность интеграции с традиционными методами EDI
Использование маршрутизациии по IP, а текже использование протоколов HTTP, FTP и SMTP
Централизованное представление документа и методология обработки
Протоколирование приема/отправки документов
Использование современных инструментальных средств программирования (Java и ActiveX)
Разделение данных и программ
Использование технологии агента для манипулирования данными, синтаксического анализа, отображения, поиска и т.д.
Определенные XML/EDI компоненты сформированы на основе существующих протоколов передачи и обработки кодированных в XML данных.
Рис 3. Уровни Интерфейсов XML/EDI
На рисунке представлены следующие интерфейсы уровней XML/EDI:
Использование стандартных транспортирных механизмов данных по Интернет и хранения файлов
Форматы представления данных и передачи сообщения
Синтаксис XML данных
Правила грамматического разбора XML документа или создание объектной модели
Правила XSL представления, связь со скриптами и уровнем разбора объекта
Использование правил управления данными для пользовательских приложений и интерфейсов баз данных
Сегодня уже доступны синтаксические XML анализаторы, программы просмотра XML-документов (броузеры), программы разметки страниц и библиотеки программ. Предполагается использование специальных XML/EDI компонент встаивать в существующие программные продукты. Это позволит значительно ускорить создание новых приложений, реализующих XML/EDI.
Первичные компоненты XML/EDI представляют общей язык описания и синтаксические правила и включают:
таблицу определения данных - DTD
Базу (хранилище) данных - Repositories
Сегменты и элементы данных (т.e. EDIFACT, X12, или BSI директории)
Базу бизнес объектов
Страницы торговых партнеров (База данных предприятий).
На рис. 4 представлены возможные варианты подключения отдельных компонентов XML/EDI. На данной схеме выделены в отдельные компоненты: удаленный пользователь, бизнес приложения, существующие EDI-системы, публичные директории и специальные словари и базы данных.
Рис 4. Связи в XML/EDI
Конечный пользователь посредством WEB-броузера может взаимодействовать с любыми компонентами системы, используя XML-представления и XQL запросы.
Хотелось бы отметить о возможности более интересующегося читателя подчерпнуть более подробную информацию на следующих серверах:
| 
