Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Перспективы применения языка XML в электронной коммерции

Рик Драммонд, Кай Спирман

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

Эффективным решением этой проблемы может стать расширяемый язык описания документов XML (Extensible Markup Language). Он был разработан W3-консорциумом и представляет собой версию стандартного обобщенного языка описания документов SGML (Standard Generalized Markup Language), специально предназначенную для применения в Web-пространстве. SGML -- это международный стандарт, который служит для разметки крупных документов с целью упрощения операций по их хранению, поиску и просмотру. Язык XML является действенным средством, позволяющим разработчикам прикладного ПО создавать разнообразные структуры и дескрипторы элементов данных для определения и описания информации в составе документа, базы данных, объекта, каталога или ключевого бизнес-приложения с тем, чтобы упростить процедуру обмена данными между ними. Так, например, имея текстовый XML-документ произвольного формата, пользователи могут без труда, путем поиска структурного XML-компонента типа <Item Number>ххххх</Item Number>, определить порядковый номер любого товара, который они намерены приобрести.

Язык XML получил одобрение многих поставщиков программного обеспечения. Компания Netscape одной из первых объявила о поддержке этого стандарта, а фирма Microsoft даже успела выпустить для него свою программу синтаксического анализа. Ее браузер Internet Explorer 4.0 имеет встроенную поддержку языка XML для документов в формате Channel Definition Format, а в его версии 5.0 будет реализована поддержка этого языка для большинства документов, написанных в других форматах. Фирма Adobe Systems планирует дополнить свои программные продукты FrameMaker 5.5 и FrameMaker + SGML 5.5 возможностью сохранения (экспорта) документов в формате языка XML. Это обеспечит их разработку и автоматическое распространение в любом из основных форматов, будь то HTML, PDF, PostScript, SGML или XML.

Достоинства XML

К продуктам, составляющим основу электронной коммерции, можно отнести целый ряд никак не связанных друг с другом приложений, в том числе программы автоматизированного проектирования (CAD), программные средства взаимодействия, биллинговые системы и системы инвентаризации, электронные каталоги, программы электронных платежей и учета кредитов и, естественно, электронную почту. Язык XML использует единый механизм пересылки данных между этими приложениями, основанный на словаре данных. В таком словаре каждый элемент данных имеет свое определение, что способствует эффективному отображению информации из одного приложения в другое. Например, в клиентской системе заказ на покупку может быть указан с помощью ссылки типа "Item #", в то время как в торговой системе этот же заказ будет обозначен уже с помощью ссылки "Item_Number". Благодаря использованию собственных, не привязанных к конкретному приложению средств, словарь данных легко устанавливает однозначное соответствие между этими обеими ссылками.

Чтобы уяснить себе, каким образом язык XML решает проблему обмена данными, нелишне рассмотреть существующие в настоящее время механизмы обмена деловой информацией между компьютерными системами. Итак, пришла пора поговорить о стандартном процессе обмена данными -- технологии EDI (Electronic Data Interchange).

XML и EDI в "одной упряжке"

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

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

Если бы для сети Интернет нам удалось составить общий словарь данных из проверенных временем словарей X12 и EDIFACT, то формат языка XML можно было бы использовать в качестве "нейтрального" транспортного формата при обмене деловой информацией между Интернет-приложениями для ЭК. XML не снижает объема требований к размещению информации в таком словаре, зато снимает часть проблем, связанных с применением сложного ПО для отображения данных различными приложениями. К тому же, наличие такого общего словаря позволило бы коммерческим структурам малого и среднего бизнеса воспользоваться всеми преимуществами технологии ЕDI при наименьших затратах всех своих ресурсов, в том числе и финансовых. Кроме того, в качестве элементной базы Интернет-приложения для ЭК могли бы использовать расширенный набор элементов данных языка XML. Это существенно упростило бы процедуру взаимного обмена информацией между традиционными приложениями и Интернет-приложениями для ЭК.

EDI и XML в примерах

Форма Purchase Order (рис. 1) представляет собой типовой бланк заказа на поставку, а набор символов вида "X12 Line Item Record" (рис. 2) -- это ни что иное как одна из записей этого заказа, соответствующая конкретной строке в списке наименований товаров.


Рис.1 Форма Purchase Order.


Рис.2 X12 Line Item Record.

В стандарте Х12 заказ содержит до сотни таких записей, многие из которых встречаются несколько раз. Три первых символа -- РОl -- определяют тип записи, что в данном случае означает "purchase order line -- item". Каждое новое поле начинается с разделителя элементов данных (в приведенном примере это символ "*"). Записи могут иметь различную длину, а последние по счету незаполненные поля могут быть опущены. В стандарте XML эта запись имеет следующий вид:
<pol>

<ass.Id>l</ass.Id>

<Q.Ordered>54</Q.Ordered>

<Unit.M>EA</Unit.M>

<Unit.P>0.99</Unit.P>

<Price.C>CA</Price.C>

<Prod.ID.C>VN</Prod.ID.C>

<Prod.ID>456</Prod.ID>

</pol>

Отметим, что хотя XML-версия записи менее компактна по сравнению с записью в стандарте Х12, она имеет позиционно-независимый формат. Поскольку каждый компонент записи имеет свой уникальный дескриптор, не составляет особого труда установить, к какому элементу данных он относится. А уж коль компонент помечен, ему не угрожает опасность "раствориться" в киберпространстве. Для программиста средней квалификации, который пишет программы для Web-сервера, сей факт означает меньшую степень его зависимости от CGI-интерфейса.

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

Пусть элемент данных, имеющий дескриптор "price", содержит розничную цену товара, а элемент с дескриптором "discount price" (цена со скидкой) -- цену, предлагаемую оптовым покупателям, которые намерены приобрести крупную партию товара на общую сумму n долларов. Покупатели, использующие XML-совместимые каталоги, будут знать, что сумма в долларах, возвращаемая в ответ на запрос "price", соответствует розничной цене в общем словаре данных. Это позволит им легко сравнивать цены различных поставщиков на интересующий их товар.

Что нужно для успешного внедрения стандарта XML

Для успешной реализации стандарта XML/EDI необходимо, как минимум, ответить на следующие вопросы:

  • Как максимально использовать результаты работы по составлению словарей данных, проделанной рабочими группами Х12 и EDIFACT?
  • Как установить происхождение некоего элемента данных?
  • Как определить, к какому из отраслевых стандартов -- Х12, EDIFACT или какому-либо другому -- относится элемент?
  • Как вводить в действие новые словари данных, отсутствующие в спецификации EDI?
  • Как применить эти словари, работая с универсальными приложениями для ЭК?

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

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

Интеграцию XML и EDI -- на службу электронной коммерции

В феврале прошлого года Ассоциация CommerceNet, в которую входят более 500 компаний со всего мира, и организация ASC X12 объединили свои усилия и сконцентрировали их на толковании словаря данных спецификации Х12 в терминах синтаксиса и семантики Интернет-ориентированного языка XML.

· Синтаксис языка XML. Главный вопрос, касающийся синтаксиса, заключается в том, как лучше всего использовать уже существующий синтаксис спецификации X12 в стандарте XML. В основе языка XML лежит латинский алфавит, а многие его определения по своей природе являются англоязычными. Пусть, например, Х12-запись, содержащая информацию о денежной единице, имеет дискриптор "cur". Отнесутся ли продавцы из Франции или Китая и покупатели этих стран с безразличием к использованию английского языка в качестве базового для XML-определений?

Язык XML поддерживает 32- и 64-разрядный набор символов кода Unicode. Поэтому суть вопроса не в том, можно ли средствами языка XML выразить описатели записей или элементов данных, а в том -- нужно ли делать словарь данных, что называется, нейтральным, т. е. без ориентации на тот или иной язык?

Не долго думая, вы скорее всего ответите на этот вопрос положительно, пока не вспомните одну хорошо известную истину о том, что в основе Интернет лежит синтаксис английского языка. Почти все существующие программы написаны на языках высокого уровня, дружественных к английскому, и хотите вы этого или нет, но именно он является языком международной коммерции. Эксперты стоят перед дилеммой: должны ли дескрипторы элементов данных символизировать их содержимое, как, например, "сur" для currency (денежной единицы), или лучше заняться своим собственным языкотворчеством и описывать ту же денежную единицу, скажем, как "sys87", что напрочь лишено всякого смысла.

· Множество синтаксисов. Есть еще один вопрос, который можно сформулировать так: а нужны ли нам в таком случае многочисленные синтаксисы и соглашения об именовании? Допустим, мы хотим выразить удовлетворяющий стандарту Х12 структурный компонент заказа средствами языка XML. Нам известно, что <cur>, т. е. имя записи денежной единицы, находится в сегменте данных РО, а это указывает на то, что данная запись так или иначе относится к заказу на поставку. Но если мы собираемся применить этот дескриптор записи (<cur>) вне структурного компонента данных РО и хотим поставить ему в соответствие некую денежную сумму, то как мы узнаем, что <cur> описывает как раз ту информацию, которую используют при обработке заказов на поставку?

Скажем, вы собираетесь, например, заказать нечто приглянувшееся вам из Web-каталога. Вам задают вопрос, в каких денежных единицах вы намерены произвести оплату. Если это будут рубли (rubles), то они появятся в поле ввода информации структурного элемента <currency>xxxxx</currency> (на место "ххххх"), расположенного в записи с именем <cur>. Но как в процессе обмена данными без вмешательства человека мы установим, куда следует переслать эту запись: в базу данных РО или в базу данных счетов на оплату?

<cur>
<currency>Rubles</currency>
<ExchRate> 1 to 6.23</ExchRate>
...
</cur>

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

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

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





  
8 '1998
СОДЕРЖАНИЕ

колонка редактора

• Рецепт успеха

локальные сети

• Победы на кабельном фронте

• NetMon: сетевой анализатор Microsoft выходит из тени

бизнес

• Как обуздать технологического гиганта

• CISCO - OCS: партнерство превыше всего!

• CA поворачивается лицом к каналам сбыта

корпоративные сети

• Лучшие продукты 1998 года

• Шлюзы видеоконференцсвязи стандарта H.323

• Три условия успеха сетевого специалиста

услуги сетей связи

• "Небесные" высокоскоростные сети (окончание)

• Наступит ли время Интернет-телефонии?

• Тестируем маршрутизаторы ISDN для SOHO

• Контроль качества услуг связи

• Какая связь в Республике Мордовия?

интернет и интрасети

• Интернет-торговля. Часть I.

• Современные средства доступа к данным

защита данных

• Новое поколение ИБП

только на сервере

• Перспективы применения языка XML в электронной коммерции

• Пакеты удаленного управления для контроля за ресурсами корпоративной сети

новые продукты

• NetWare 3.2: только для профессионалов; В семействе Accelar прибыло; MasterSwitch: включение и выключение на расстоянии; Summit48 фирмы Extreme Networks бьет все рекорды; Catalyst 8510 фирмы Cisco Systems;



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх