"XML E-Business Standards: Promises and Pitfalls" by Robert Worden
Перевод с авторского сайта A.Talera
Индикатор перемен сегодняшнего бизнеса - ворвавшаяся в Internet электронная коммерция. Ожидается, что эта революция окажет в ближайшее время наибольшее влияние на транзакции типа business-to-business. Анонсы Ford и General Motors о том, что они намерены подключить e-business для всех своих продаж (а для Ford это $80 млрд. в год) отмечались комментаторами как знамение, что эпоха электронного бизнеса пришла.
Для обмена транзакциями электронной коммерции необходим общий язык, с помощью которого компании могли бы обмениваться структурированными данными между своими разнотипными компьютерами. Язык Internet первого поколения, HTML, не годится для этой цели - он описывает форматирование информации, но не ее смысл. И вот появился XML - Extensible Markup Language. Как и HTML, он содержит текст, размеченный тегами и легко "переносится" по Internet. Но теги в XML описывают уже и смысл и структуру информации, позволяя напрямую обрабатывать ее программными средствами.
И законодатели IT, и пользователи, встретили XML с распростертыми объятиями - появления стандарта и быстрое его признание последние два года были главной темой информационных технологий. Все промышленные конкуренты, IBM, Microsoft, Sun и Oracle, взяв за основу стандарт XML 1.0, разрабатывают сейчас на его основе свои продукты и сотрудничают в создании сопутствующих стандартов. XML сегодня - мировая стандартная платформа для электронной коммерции. Однако для конкретного бизнес-приложения сам по себе XML еще не ответ - он лишь основа, на которой этот ответ можно построить. В отсутствии каких-либо предписаний кроются и сильные, и слабые стороны XML для электронной коммерции.
Сегодняшнее состояние XML напоминает реляционные БД лет 20 назад. Реляционная модель не предписывает, как вам хранить данные. Она дает лишь стандартную основу, оставляя на ваше усмотрение, как вы будете ей пользоваться. От вас требуется определить таблицы и столбцы. То же самое, что РБД предлагает для хранения, XML предлагает для перемещения данных по Сети. Сам XML не предписывает ни структуры, ни смыслового значения вашей информации. Вы сами описываете теги и их семантику, создаете структуру и указываете значения данных. XML, как и РБД, просто позволяет работать с данными проще, гибче и более мощными методами, чем до этого.
Чтобы осознавать влияние XML на будущее, необходимо понимать влияние реляционных баз данных в прошлом и в настоящем. РБД оказались много лучше, чем то, что было до них - проще, мощнее и доступнее - и когда они появились в 1980-х, закрутилось массированное строительство новых баз данных. Новые приложения новых БД роились, росли и были необходимы своим создателям. А потом мы увидели, что создали информационный хаос.
Строя новые базы десятками и сотнями, компании помещали одни те же данные в кучу разных БД, что приводило к избыточности, дублированию и противоречивости. Сегодняшняя участь многих крупных компаний - "корпоративные макароны" из взаимных межсистемных ссылок между данными. Стоимость интеграции приложений уже составляет не менее 40% общего бюджета IT и что хуже всего, серьезно замедляет разработку новых жизненно-важных проектов.
Проблему межсистемных обменов данными РБД можно выразить так: если у вас N баз, то сочетания по обмену данными растут как N-квадрат. То есть, уже при 30 БД (а у многих компаний намного больше) это уже почти 1000 сочетаний. И даже если вы строите, сопровождаете и вникаете лишь в часть интерфейсов, суммарная сложность становится неуправляемой. Многие компании уже проиграли эту борьбу со сложностью и сейчас тяжко расплачиваются. Вот уже двадцать лет мы в "реляционной" эре, но все никак не справимся с проблемой информационной сложности, в которую она нас погрузила.
Подводный камень XML: В силу широчайшего распространения XML, мы имеем великое поле битвы за сложность данных, на этот раз между целыми отраслями, а не отдельными компаниями. И в этот раз, когда мы ее проиграем, последствия будут куда более тяжелыми.
Впервые входящим в e-business компаниям это не кажется серьезной проблемой. Разве, считают они, так сложно выбрать один из новых XML-стандартов, к примеру, FIN-XML для банковских транзакций или C-XML для e-бизнеса, и написать интерфейс с ним для нашей главной системы? Однако любой из этих стандартов электронной торговли не менее сложен, чем РБД-схема уровня выше среднего. Разработка интерфейса между одним из стандартов и крупной ИС вашей компании - вполне выполнимая, однако, серьезнейшая работа.
К сожалению, XML-стандарт уже не один, а множество - для разных отраслей и даже внутриотраслевых. Мы видим войны за XML-стандарты между промышленными группировками. Куча причин, почему может не получиться просто так взять и привязаться к одному из стандартов: ваша компания наверняка работает не на одном секторе рынка; один стандарт не отвечает всем нуждам вашего бизнеса; у ваших партнеров другие стандарты; войны стандартов продолжаются, и будут продолжаться, и придется адаптироваться к победителям. Появляются новые стандарты, которые растут и развиваются. И чтобы остаться в бизнесе, вам придется строить и поддерживать интерфейсы между множеством систем и конкретными XML-стандартами.
Стандарты сетевых XML-сообщений растут как грибы, как в 1980-х росли и множились РБД отдельных компаний. В итоге нас ждет аналогичный бардак с данными, но на этот раз мы проиграем сражение в планетарном масштабе. У каждой компании будет мозаика прикладных БД (как и раньше) плюс интерфейсы с кучей разно-форматных XML-сообщений. Стоимость интерфейсного ПО, бизнес-процедур и старых систем, помноженная на прорву XML-стандартов, очень скоро может стать основным тормозом для вашей компании, активно ищущей новые схемы бизнеса.
Эта капкан сложности не менее реален и опасен, чем капкан кучи РБД. За истекшие 20 лет мы так и не смогли справиться с проблемой сложности РБД. Как избежать намного большего капкана сложности, сопутствующего XML ?
Есть два возможных пути - под зонтик некоего "над-стандартного" репозитария типа Microsoft BizTalk, либо правильное управление XML интерфейсами на уровне компании. Эти пути не исключают друг друга, поэтому рассмотрим их по отдельности.
Инициатива BizTalk Framework, продвигаемая Microsoft с партнерами, имеет целью, чтобы отдельные компании, избрав комплект, наиболее подходящий по их задачам и приложениям, смогли без труда "смешивать и фильтровать" XML-сообщения от разных производителей в форматах разных линеек XML-стандартов.
Для этого в BizTalk есть три вещи. Во-первых, можно работать с любой частной группой форматов в "каноническом виде". Во-вторых, по адресу www.BizTalk.org организован общий репозитарий, где линейки совместимых с BizTalk форматов можно проверить на правильность, поместить на хранение, получить и свободно пользоваться. В-третьих, создателей совместимых с BizTalk стандартов поощряют сдавать туда и XSLT-конверторы между своими форматами и форматами других.
Идея здесь в следующем: пусть ваша компания подписана на стандарт, совместимый с BizTalk (A). Вы создаете интерфейсы между своими системами и A. Ваш бизнес-партнер подписан на другой стандарт (B), так же совместимый с Biztalk. Пользуясь XSL-конвертором a2b (доступным в репозитарии Biztalk), вы отправляете XML-сообщения в стандарте A, который ваш партнер конвертирует для "понимания" в B. И если "под зонтиком" BizTalk окажется достаточное число стандартов, вы сможете свободно обмениваться сообщениями с произвольными партнерами.
Путеводная ли это звезда для вашей компании? Можно ли ставить на то, что мощь Microsoft сотоварищи тот гарант, что вы получите полное комплексное решение, необходимое вам и вашим партнерам для работы под зонтиком BizTalk? Можно ли надеяться, что стоит преобразовать сообщения в любой из форматов BizTalk, как BizTalk-конверторы сделают все остальное?
История реляционных БД дает очевидный ответ - "нет", ибо BizTalk-трансляции не решают проблемы "n-квадрата". Аналогично БД, для N форматов "стандартных" сообщений в идеале требуется N(N-1) конверторов. Число стандартов XML-сообщений (N), предложенных для бизнеса, уже более 100 и продолжает расти. Будь вы создателем одного из таких стандартов, стали бы вы тратить время на другие стандарты (конкурентов) с достаточной степенью вникания, чтобы разбираться во всех нужных преобразованиях? Да вы и так завалены работой по сопровождению и адаптации собственных XML-форматов к изменяющимся требованиям бизнеса. А поддерживать еще 30-50 XSLT конверторов - огромная дополнительная нагрузка при минимальной отдаче.
По этой простой причине, не стоит "разевать рот" на plug-and-play совместимость приложений через BizTalk-XML. И строить корпоративную IT- стратегию в расчете на BizTalk не стоит. Решение, позволяющее избежать ловушки N-трансляций несовместимых форматов и устарелых систем - это решение - внутри вашей собственной компании.
Каждой отдельной компании придется решать проблему самостоятельно, но вполне жизнеспособное решение для этого существует. Ключом служит очевидный факт:
Никто другой абсолютно аналогичным бизнесом не занимается.
Следовательно, нужно просто построить единую, независимую от технологий, общую логическую информационную модель, движущую ваш бизнес - собственный Золотой Стандарт бизнес-данных - и отобразить на эту логическую модель все технические компоненты - собственные системы и внешние форматы. Определить для модели все необходимые преобразования. Любые конвертирования из системы A в формат B - делать не прямо, а в два этапа - через вашу логическую бизнес-модель.
Конвертируя в два этапа, вы устраните проблему N-квадрата. Для каждой новой системы или нового формата XML-сообщений останется построить одно преобразование (из общей логической модели), но не N!
Необходимые шаги:
Сделав это, через ваши форматы-посредники вы сможете без проблем выполнять преобразования между любыми моделями данных и в любой формат XML-сообщений. Самые сложные этапы - это (1) и (2), как только они сделаны, остальное становится делом техники.
Для помощи в реализации этих этапов известны инструменты и методики, доказавшие свою применимость на примере крупных и сложных систем. Если эта ваша попытка окажется успешной, она окупится сторицей - у вас будет четкая информационная архитектура, закрывающая вас прослойкой от растущего в индустриальном масштабе информационного спагетти, и позволяющая вашей компании быстро адаптироваться к новым моделям бизнеса и информационным потребностям. В век электронной коммерции в победителях будут те шустрые компании, которые способны быстро адаптироваться к новым, прогрессивным бизнес-моделям. Ключ к проворству - в четкой и ясной архитектуре корпоративной информации.
Инициатива BizTalk - не единственная в попытках навести порядок среди множащихся XML-приложений промышленного сектора. Другие проекты, типа ebXML или XML/EDI, тоже предлагают общие репозитарии с описаниями XML-форматов - с желанием свести все в общий бизнес-словарь, дабы нивелировать N-квадратную сложность проблемы конвертирований.
Каждая из этих "над-стандартных" инициатив имеет целью справиться со сложностью множества XML-диалектов. Однако, аналогично шансам самих диалектов, сейчас трудно прогнозировать шансы конкретных инициатив вырваться вперед или одержать победу на финише. Ни один репозитарий не сможет решить проблему N-квадратных конвертирований для всех сфер деятельности, пока в нем не будет общей модели всех бизнес-данных (согласованной с участниками), играющей роль общего эсперанто. Однако шансы на создание такой мощной информационной модели, непротиворечивой и полной, согласованной по странам и промышленным секторам, и чтобы она затем эффективно поддерживалась, крайне малы.
Потому можно не возлагать особых надежд на успех всех этих кросс-промышленных инициатив. Вместо этого, любой компании по силам разработать свою собственную информационную бизнес-модель на основе специфики своего бизнеса, чтобы проводить через нее все XML-трансляции. Это вполне по плечу, а отдача придет уже через месяц-другой. Такая модель резко упростит ваш интерфейс с изменчивым и непредсказуемым внешним миром. В то же время, этот "course of action" ни в коей мере не препятствует использованию BizTalk или любого другого XML-репозитария, когда (и если вдруг) он окажется победителем.
Об авторе: Robert Worden - консультант по архитектуре информационных систем и е-бизнесу в Charteris Ltd, London