CC BY
62
№2 2006
А.В. Кудинов
Разработка XML-стандартов: мировой опыт и практика работы в банковском секторе
Созданный более 6 лет назад язык XML сегодня превратился в стандарт де-факто, универсальный формат для обмена данными между различными корпоративными системами. Успех XML во многом объясняется плодотворной деятельностью различных международных консорциумов, занимающихся разработкой всевозможных XML-спецификаций. Ни в коем случае не пытаясь умалить достоинства других органов стандартизации, выделим две, на наш взгляд, ключевые фигуры в области разработки стандартов XML-технологий — это международные консорциумы W3C1 и OASIS2.
Как известно, консорциум W3C «ответственен» за создание базовых XML-стандартов (XML 1.0 и 1.1, XML Schema, Namespaces in XML и др.). Международная организация OASIS пользуется заслуженным авторитетом как автор ряда высококачественных отраслевых стандартов — таких как ebXML3. Заметим, что интересы членов этой организации не ограничиваются только отраслевыми спецификациями. Так, стандарт языка схем RELAX NG — своеобразной альтернативы языка XML Schema W3C — был признан Международной организацией по стандартизации (ISO).
Говоря об организациях, занятых подготовкой различных XML-спецификаций, важно понять, какими принципами они руководствуются. Значимость нормативных документов, регламентирующих порядок
1 World Wide Web Consortium — Консорциум всемирной сети (http://www. w3. org)
2 Organization for Structured Information Standards — Организация по стандартизации структурированной информации (http://www. oasis-open. org)
3 e-Business XML — XML для электронного бизнеса.
принятия стандартов, трудно переоценить. Действительно, успешное завершение работы над стандартом во многом зависит от продуманности методики разработки стандартов. Несомненно, знакомство с любым опытом по этому вопросу, тем более мировым, может оказаться весьма полезным. Рассмотрим, как ведется работа в этих организациях, а затем попытаемся установить общие точки и имеющиеся различия.
Консорциум W3C: от рабочего проекта до рекомендации
Консорциум Всемирной сети — это международная организация, призванная раскрыть весь потенциал Всемирной сети путем разработки общих протоколов, способствующих ее развитию и взаимодействию. W3C насчитывает около 400 членов со всего мира. Хотя консорциум издает спецификации, которые технически являются просто предложениями (или — в терминах W3C — рекомендациями) для дальнейшей реализации, они имеют свойство превращаться в стандарты де-факто.
W3C был создан в октябре 1994 г. по ини-циативеТимаБернерза-Ли(^1Г1 Berners-Lee), осователя Всемирной паутины, на базе Лаборатории вычислительной техники Массачусетского технологического института4 при активном участии CERN5, DARPA6 и Европейской комиссии.
4 Massachusetts Institute of Technology, Laboratory for Computer Science.
5 Conseil Europeen pour la Recherche Nucleaire — Европейская организация по ядерным исследованиям.
6 Defense Advanced Research Projects Agency — Управление перспективных исследовательских программ.
№2 2006
Основная работа по созданию спецификаций W3C происходит в рабочих группах. Результатом деятельности групп являются технические отчеты. Отчет представляет собой одну из возможных версий стандарта, разрабатываемого рабочей группой: рабочая версия (Working Draft), кандидат к рекомендации (Candidate Recommendation), предложенная рекомендация (Proposed Recommendation) и рекомендация (Recommendation).
Рабочая версия — это первая ступень в продвижении технического отчета к самому высокому статусу, который может получить спецификация, — рекомендации. Формально для опубликования рабочей версии необходимо согласие директора W3C, хотя факт обнародования документа не является отражением наличия консенсуса или одобрения со стороны консорциума. После выхода рабочей версии группа должна продолжить работу над ней: принимать комментарии и замечания к данному документу как от членов W3C, так и от представителей общественности. В результате группа может публиковать несколько вариантов технического отчета, постепенно приближаясь к следующему статусу документа. Последняя итерация работы над рабочей версией называется последней редакцией, или периодом «крайнего срока» (last call).
Фактически переход спецификации в статус кандидата к рекомендации означает, что рабочая группа ожидает, что предложенный ею документ найдет практическое применение. Два не связанных между собой случая реализации не являются обязательным требованием при получении данного статуса, однако их наличие или указание о потенциально возможных решениях всячески приветствуется.
Для получения статуса предложенной рекомендации рабочая группа должна добиться реализации каждой функциональности, представленной в спецификации, после чего документ передается в консультативный комитет консорциума.
Тем не менее если директор W3C считает, что незамедлительное изучение спецификации членами консультативного комитета является необходимым условием успешного завершения разработки стандарта, он может предоставить спецификации статус предложенной рекомендации, даже если она не получила необходимого апробирования.
Чтобы предложенная рекомендация стала рекомендацией, директор должен быть уверен, что она пользуется значительной поддержкой со стороны консультативного комитета, целевой группы, рабочих групп W3C и общественности. Решение о предании документу статуса рекомендации считается решением всего W3C.
Кроме того, W3C может опубликовать исправленную версию рекомендации, в которой будут исправлены опечатки и внесены редакторские правки. В этом случае раздел о статусе документа должен отражать соответствующую информацию.
От спецификации технических
комитетов до открытого стандарта OASIS
OASIS — международная некоммерческая организация, объединяющая в своих рядах более 600 корпоративных и индивидуальных членов из разных стран мира. Вместе с ООН OASIS финансирует проект ebXML, спецификацию обмена данными электронного бизнеса.
Корни организации уходят в 1993 г., когда был основан консорциум SGML Open, целью которого была разработка принципов согласованности продуктов, поддерживающих язык SGML. Чтобы соответствовать изменившимся реалиям (рост объема технических разработок, включая работу над языком XML и другими связанными стандартами), в 1998 г. консорциум сменил название на нынешнее.
Как и в международном консорциуме W3C, большая часть работы по созданию стандартов ведется в технических комитетах. Согласно Регламенту технических
А.В. Кудинов
Разработка XML-стандартов: мировой опыт и практика работы в банковском секторе
№2 2006
комитетов OASIS консорциум принимает и публикует 3 типа технических материалов: рабочая версия спецификации комитета (Committee Draft), спецификация комитета (Committee Specification) и стандарт OASIS (OASIS Standard).
Первым шагом на пути становления стандарта OASIS является появление рабочей версии спецификации комитета. После признания разрабатываемого документа в качестве внутренней редакции спецификации он может быть передан на рассмотрение общественности. Получив необходимый отклик, комитет может продолжить работу над спецификацией, а затем снова опубликовать ее, чтобы собрать замечания и предложения. Спецификация комитета — это окончательная и утвержденная членами комитета версия документа. Наличие этого статуса является достаточным условием для того, чтобы организации и компании могли начать использовать данную спецификацию, хотя переход спецификации на следующий уровень — стандарт OASIS — придает ей дополнительный вес. Необходимо иметь в виду, что технический комитет вправе не выдвигать свою спецификацию на получение статуса стандарта.
Стандарт OASIS — это спецификация комитета, которая после представления членам консорциума была одобрена в ходе проведенного голосования.
Интересно, что для получения статуса стандарта OASIS достаточно, чтобы «за» проголосовало не менее 15 % голосов, однако при условии, что никто не проголосует «против».
Методики принятия стандартов W3C и OASIS: общность подходов
Исходя из приведенного выше описания технологий разработки стандартов, принятых в W3C и OASIS, можно сделать следующие выводы. Несмотря на кажущуюся на первый взгляд несхожесть методик (многоступенчатый процесс принятия рекомендаций W3C и наличие спецификаций трех типов у OASIS), они представ-
ляют суть одного подхода. Действительно, хотя регламент разработки стандартов в разных организациях может несколько различаться, однако путь к новому стандарту имеет общие для всех этапы: формирование идеи, подготовка документа, описывающего ключевые особенности технологии и определяющего рамки нового стандарта, комментирование, редактирование/пересмотр и окончательное утверждение7. При этом наличие нескольких этапов ревизии в W3C нисколько не выбивается из общей схемы; между спецификацией комитета OASIS и кандидатом к рекомендации W3C можно условно поставить знак равенства: и та, и другая достаточно проработаны, чтобы получить практическое применение.
Место СНГ в процессе стандартизации
Проблемы стандартизации не обошли стороной и постсоветское пространство. В странах Содружества все более острым становится вопрос стандартизации процессов представления информации и обмена данными, все более актуальна задача обеспечения совместимости систем и сервисов.
Для решения существующих проблем в области электронного взаимодействия в январе 2002 г. в России было создано некоммерческое партнерство «Стандарты электронного обмена информацией» (www.stp.ru), в состав которого вошли представители ведущих российских и мировых производителей ПО и финансовых организаций. Как и в большинстве международных органов стандартизации, основным инструментом при выработке стандартов партнерства являются профильные комитеты по различным рынкам, отраслям или сегментам экономики. В настоящий момент в его состав входят два комитета: Комитет по банковской деятельности и Комитет по электронной коммерции.
7 Подробнее см.: Камерон Стардевант. Обретение стандарта/ZPCWeek/RE. №8/2003. С. 45.
№2 2006
В свою очередь, Комитет по банковской деятельности объединяет 3 профильных подкомитета: Подкомитет по финансо-
вой отчетности, Подкомитет по расчетам и Подкомитет по электронным банковским услугам. На сегодняшний день усилиями членов комитетов партнерства разработаны и приняты несколько стандартов, стандарт обмена коммерческой информацией для российских торговых систем.
Рассмотрим процедуру разработки стандартов, принятую в партнерстве, сопоставив ее с подходами, реализованными в методиках, описанных выше. Для большей наглядности изложения воспользуемся опытом создания «Стандарта публикации финансовой отчетности коммерческих банков» Подкомитета по финансовой отчетности партнерства.
Основные этапы разработки «Стандарта публикации финансовой
отчетности коммерческих банков»
«Стандарт публикации финансовой отчетности коммерческих банков» был разработан специалистами компании Intersoft Lab (www.iso.ru), являющейся членом партнерства и одним из инициаторов его создания. Компания имеет богатый практический опыт «общения» с XML. Достаточно сказать, что XML-технологии реализованы в продуктах компании, а для интеграции с другими бизнес-приложениями в Хранилище данных «Контур Корпорация» применяется созданный разработчиками компании XML-формат Dynamic XML. Необходимо подчеркнуть, что в определенной степени этот стандарт имел пилотный характер, поскольку он был первым стандартом партнерства. Поэтому перед его создателями стояла непростая задача продемонстрировать зрелость российских поставщиков ПО, их готовность разрабатывать стандарты мирового уровня, проверить готовность рынка к принятию практики стандартизации.
Основанием для разработки стандарта явилась подготовка его определения.
Фактически это соответствует этапу формирования идеи. Далее осуществлялась разработка проекта стандарта и его представление в соответствии с требованиями нормативных документов, принятых в партнерстве. Поясним, что под этими требованиями понимается оформление двух документов — «Логическая модель электронного обмена информацией», в котором описываются структура и содержание электронных документов, порядок их использования, и «Представление на языке разметки», в котором указывается, как из логической модели получается конечный документ (XML-схема). Оформленный таким образом проект стандарта был вынесен на рассмотрение членов подкомитета. За данными процедурами легко просматриваются этапы «Комментирование» и «Редактирование/пересмотр». По завершении этапа согласования окончательно был рассмотрен проект и вынесено решение о принятии стандарта. После его рассмотрения членами комитета по банковской деятельности стандарт был утвержден советом директоров, осуществляющим общее руководство партнерством.
В настоящий момент описание стандарта опубликовано на сайте партнерства (http://www.stp.ru/stan/0002/), с ним может познакомиться любой желающий.
Особая роль языка XML как основы стандартизации в сфере ИТ
Сегодня вряд ли кто-нибудь станет оспаривать значение XML-технологий. Благодаря XML стало возможным становление электронной коммерции по схеме «бизнес—бизнес» (B2B). Что как не XML, характерной особенностью которого является независимость от платформы, может обеспечить взаимодействие программных и аппаратных средств различных поставщиков?
Столь популярные сейчас, ставшие буквально притчей во языцех, web-сервисы просто немыслимы без XML. Являясь уни-
А. В. Кудинов
Разработка XML-стандартов: мировой опыт и практика работы в банковском секторе
№2 2006
версальным средством обмена, XML создает все предпосылки для создания независимой от платформы модели web-сервисов.
На сегодняшний день создан необходимый набор базовых XML-стандартов, которые, во-первых, успешно используются, а, во-вторых, служат основой для разработки новых перспективных технологий и спецификаций. Таким образом, вряд ли нужно доказывать значение процессов выработки стандартов — авторитет указанных выше организаций лишнее тому свидетельство.
Анализ практики стандартизации, проведенный специалистами компании Intersoft Lab при работе над «Стандартом публикации финансовой отчетности коммерческих банков», показал, что необходимость разработки стандартов во всем мире уже давно осознана. И причин тому немало. Это и сознательность западного общества в целом, и зрелось рынка ПО, проявляющаяся в том, что и разработчики программных продуктов, и их клиенты понимают значимость спецификаций и участвуют в общем для всех деле. Можно сказать, что потенциальные потребители стандартов непосредственно заинтересованы в их развитии. Дело в том, что добросовестный западный пользователь прекрасно понимает, насколько ему выгодно наличие единых стандартов, особенно если при их написании доминирующими являются именно его пожелания (отсюда и его желание быть максимально причастным к этому процессу). Именно поэтому он энергично поддерживает (в том числе и материально) многие проекты по разработке стандартов.
Стремление стран СНГ стать частью мирового сообщества требует переосмысления отношения к практике развития разработки стандартов. Опираясь на свой опыт разработки и использования XML-форматов, мы хотим подчеркнуть, что сейчас настал тот переломный момент, когда общество должно осознать важность стандартизации в сфере IT и принять самое активное участие в этом процессе.
От редакции. Мы благодарны А. В. Кудинову и компании Intersoft Lab за предоставленный актуальный материал, опубликованный в двух номерах журнала.
Литература
1. Стардевант К. Обретение стандар-та/^CWeek/RE. 2003. №8. С. 45.
2. Кудинов А. В. Россия: необходимость обретения стандарта. Из опыта разработки отраслевого стандарта электронного обмена информацие^/PC Week/RE. 2003. № 31. С. 39.
Книжные новинки. Редакция журнала продолжает просмотр книжных новинок по прикладной информатике. В 2006 г. готовится к выпуску 2-е издание книги: Емельянов А. А, Власова Е. А, Дума Р. В. Имитационное моделирование экономических процессов. — М.: Финансы и статистика.
В книге рассмотрены технологии создания имитационных моделей. По сравнению с первым изданием подробно описаны приемы разработки как учебных моделей, так и программ, рассчитанных на последующее применение в рамках систем поддержки принятия решений.
Книга дополнена разделами, связанными с практической эксплуатацией моделей и технологией работы в современной системе имитационного моделирования.
Рассмотрены режимы диалогового управления моделями, а также отображения информации в виде, понятном конечному пользователю.
Как и в первом издании, значительное место уделено работе с графическим конструктором — специальной CASE-системой, позволяющей создавать модели «без программистов». Практикум привязан к среде MS Visual C++.
Отдельная глава книги содержит сведения, необходимые для планирования оптимизационных «экстремальных» экспериментов с обеспечением заданной достоверности результатов.
