XML в АБС

Сергей Ветров, Павел Кингсеп Банковские технологии №12 (2004 г.)

XML — это беспрецедентная по своим возможностям и перспективам технология. XML быстро и безвозвратно завоевывает мир. XML позволяет решать широкий круг задач и в то же время его возможности не безграничны.
XML требует осторожности и ясного понимания того, что вы с ним делаете. Если после всего сказанного вас все еще интересует XML, перейдем к его применению в конкретике АБС.
Расширяемый язык разметки (eXtensible Markup Language, XML) традиционно относится к категории интернет-технологий. Поддерживаемый международным консорциумом W3C — главным «стандартизатором» Интернета, он обрабатывается с помощью общедоступных средств для работы в Интернете — браузеров и серверов. Как чрезвычайно гибкая и богатая возможностями технология для открытых коммуникаций, XML становится все более популярным среди разработчиков и пользователей. Сегодня XML «весомо, грубо, зримо» пришел в мир банковского бизнеса.
Почему XML?
Наиболее известный и обсуждаемый сегодня пример подобного вторжения — это полностью основанные на XML унифицированные форматы электронных банковских сообщений (УФЭБС) Банка России, на которые очень скоро должны будут перейти отечественные кредитные учреждения. Построение системы обмена сообщениями в формате УФЭБС выполняется силами привлеченных Банком России ИТ-компаний и координируется специально созданной для этой цели рабочей группой. В нее вошли представители многих заинтересованных предприятий и организаций, в том числе и из компании R-Style Softlab, отстаивающей интересы более 400 своих клиентов — российских банков, эксплуатирующих АБС RS-Bank и другие RS-продукты для банковского бизнеса. Учитывая жесткость сроков перехода на УФЭБС, мы, не дожидаясь получения окончательной версии формата от Банка России, приступили к реализации УФЭБС в рамках подсистемы «Межбанковские расчеты», входящей в состав АБС RS-Bank V.6. Как мы надеемся, у клиентов своевременно появится возможность выбора качественного решения, построенного на новой перспективной технологии для банковских систем.
Среди главных преимуществ XML — открытость, высокая способность к стандартизации решений. Сравнительно недавно Банк России подготовил Альбом схем УФЭБС, изложенных в общепринятых терминах XML — фактически он является новым отраслевым стандартом. Представленные в нем схемы свободно реализуются на основе набора типовых, хорошо отработанных программных процедур. Мы можем подтвердить это, базируясь на нашем опыте и отзывах из компаний и банков, участвовавших в проводившихся Банком России экспериментах по применению УФЭБС.
И все же в отношении пользы XML для банковских систем не все так очевидно.
Бытует мнение, что стремительное распространение XML в самых разных областях информационных технологий во многом определяется модой, а не только прагматическими соображениями. В самом деле, те же УФЭБС можно было бы построить либо на основе привычного позиционированного или тегового текста, либо в формате какой-нибудь распространенной базы данных, либо в прозрачно специфицированном двоичном формате — в истории информационных технологий и коммуникаций все они применялись, и не раз. И по всей видимости, результат не сильно отличался бы от того, что мы наблюдаем сейчас: заинтересованные независимые разработчики точно так же внедрили бы это решение в своих продуктах.
Но вот, к примеру, Сообщество всемирных межбанковских телекоммуникаций S.W.I.F.T. не спешит безоглядно следовать общим тенденциям. Вот мнение Жана-Мари Элоя (Jean-Mary Eloy), Управляющего по стандартам S.W.I.F.T., опубликованное на официальном сервере S.W.I.F.T. в Интернете (): «XML — это, по сути, не синтаксис, а скорее средство для описания вашего собственного синтаксиса. До тех пор, пока вы исчерпывающим образом не договоритесь о том, как будете использовать XML, вы рискуете привнесением различных особенностей и диалектов. Это то, чего мы хотели бы избежать». Сообразно этой позиции внедрение XML в S.W.I.F.T. идет крайне осторожно. XML отнюдь не рассматривается в качестве самодостаточной технологии, как это иногда кажется энтузиастам. Так, планируемое на IV квартал 2004 г. начало поддержки Сообществом S.W.I.F.T. стандарта UNIFI (ISO 20022), регламентирующего работу с ценными бумагами, обусловлено вовсе не тем, что он базируется на XML. Главное в том, что этот стандарт охватывает весь жизненный цикл финансового инструмента и описывает все его аспекты посредством языка UML (Unified Modeling Language), что позволит оптимизировать сроки создания финансового репозитория и избежать множественности и неоднозначности решений, о которых говорит г-н Элой. Аналогичный подход прослеживается и в отношении всех прочих разработок, выполненных с использованием XML, которые S.W.I.F.T. предлагает потребителям.
Перечисление достоинств XML можно найти во множестве изданий и на бесчисленных сайтах в Интернете. Его стройность, концептуальная ясность, гибкость, широкая поддержка самыми разными инструментами и программными средствами, безграничные возможности привлекают разработчиков, уставших от частных решений и закрытых, плохо документированных архитектур. Следует только иметь в виду, что несмотря на обилие достоинств, основанных на прекрасных идеях, на практике при работе с языком XML придется столкнуться и с его недостатками, а отступать будет уже поздно.
Например, принимая решение о применении технологии XML для организации документооборота, надо хорошо осознавать, что трафик может оказаться в несколько раз больше, чем при обмене сообщениями в виде форматированного текста и, вероятно, в десятки раз больше, чем при обмене сообщениями в двоичном формате. Да-да, не удивляйтесь и не цитируйте авторов, утверждающих, что XML, наоборот, позволяет экономить трафик. Они не лукавят, но имеют в виду совсем другие случаи. В частности, если речь идет о просмотре выборки из серверной базы данных на рабочем месте клиента (что сплошь и рядом случается в интернет/интранет/экстранет), то XML позволит переслать такую выборку только один раз, а уже потом локально, не нагружая сеть и сервер, можно будет делать с ней все, что заблагорассудится: фильтровать, сортировать, показывать в разных разрезах и представлениях и т.д., и т.п. Но когда вы собираетесь обеспечить активный межфилиальный документооборот хотя бы с несколькими тысячами документов в день, знайте, что такие удобные в разработке и разборе теги XML будут очень и очень ощутимо загружать ваши, как всегда, ограниченные коммуникационные ресурсы и отнимать вполне реальные денежные средства.
Если ваша АБС до сих пор не поддерживает работу с XML, то перед вами встает проблема выбора инструментария для разработки и обеспечения функционирования, а также поиска людей, которые смогут с ним управляться. Беда не в том, что в таких средствах ощущается нехватка, — вовсе нет: чуткий ко всяким веяниям моды рынок откликнулся целой лавиной привлекательных предложений. Источники контента, библиотеки, средства разработки, готовые приложения, стандарты предоставляют и «гранды», и маленькие, никому не известные компании, и государственные органы. Сделать правильный выбор в таких условиях непросто, и задача легко может превратиться в классическую проблему буриданова осла, осложненную заботами о многоплатформенности, удобстве, минимизации трудозатрат, развиваемости и пр.
Зачастую выход из положения видится в разработке собственного упрощенного парсера, адаптированного под конкретную задачу. Кстати, многие игроки на ИТ-рынке начинали именно так. Ну что ж, XML позволяет выбрать и такую стратегию, хотя она и противоречит в определенном смысле его концепции — языка разметки, который не зависит от реализации. Потом как-то незаметно парсер вырастает в полнофункциональный анализатор, становится самостоятельным продуктом — и вот, пожалуйста: еще одно новое предложение на рынке! И еще одна дилемма для потребителей: стоит ли на него ориентироваться или нет.
Тем не менее, однажды выбрав базовую технологию работы с XML, вы на длительное время будете неразрывно связаны с этим решением и, соответственно, с его особенностями и ограничениями — они, к сожалению, имеются всегда и во всевозможных вариантах. Переход на альтернативное приложение (обратите внимание: оно тоже построено на базе XML — другого и представить себе нельзя) с течением времени становится все более проблематичным. Непростым будет и использование уже имеющихся наработок в рамках какого-либо нового решения — они, скорее всего, окажутся весьма специфичными. Чувствуете, как ситуация приближается по своему характеру к той, что так надоела нам в стремительно устаревающем безXMLном мире, от чего, казалось бы, и призван спасти XML? Налицо оборотная сторона еще одного достоинства XML — гибкости: выходит, что этот язык способен предоставить все возможности для отклонений и несовместимостей, от которых и хотелось с его помощью избавиться.
Здесь на первый план выступает уже упоминавшееся нами преимущество XML — способность к стандартизации решений. Впрочем, может быть, имеет смысл называть это не преимуществом, а насущной необходимостью. Если вдуматься, это то же самое, о чем говорил Жан-Мари Элой: либо вы изначально, на самых ранних этапах подготовки к внедрению в проект XML ответственно и тщательно выбираете подходящий к решаемой задаче существующий стандарт, либо, если такового не обнаруживается, в результате долгих обсуждений и согласований со всеми заинтересованными сторонами создаете новый — свой собственный стандарт. Иначе ваш проект обречен. Но если уж подходящий стандарт выбран (или создан) и задокументирован (безотносительно «самодокументированности» XML), а также созданы процедуры его коррекции и развития (особенно если все это поддержано средствами автоматизации процесса разработки) — будьте уверены, все разрекламированные достоинства и преимущества XML окажутся в вашем распоряжении.
Задачи, которые предполагается решать с помощью XML, должны соответствовать его предназначению, ведь это все-таки язык, т. е. по определению средство коммуникации. Не следует пытаться возложить на него чужую роль — ничего хорошего в результате не получится. Его задача — обеспечить взаимодействие между разнесенными в пространстве субъектами — клиентами и серверами, информационными системами, терминалами и хостами, пользователями, наконец. Чем меньше «коммуникативности» в задаче, тем менее оправдано будет применение XML и тем б€ольшие потери в функциональности оно повлечет.
Резюмируем. XML — это беспрецедентная по своим возможностям и перспективам технология. XML быстро и безвозвратно завоевывает мир. XML позволяет решать широкий круг задач и в то же время его возможности не безграничны. XML бросает новые, особые вызовы разработчикам и пользователям. XML требует осторожности и ясного понимания того, что вы с ним делаете. Если после всего сказанного вас все еще интересует XML, перейдем к его применению в конкретике АБС.
И все-таки XML!
В АБС, по всей видимости, область применения XML может быть следующей:
• внешний платежный и технологический документооборот в системах межбанковских расчетов, приложениях типа «Клиент—Банк», клиринговых, биржевых и пр.;
• внутрибанковский документооборот любого рода — платежный, информационный, технологический, административный — между головной организацией, филиалами и структурными подразделениями;
• взаимодействие между бизнес-подсистемами АБС, фронт- и бэк-офисами;
• взаимодействие между разнесенными техническими элементами АБС — серверами приложений, терминалами, клиентскими рабочими местами;
• экспорт информации из АБС в хранилища данных (OLAP-системы), информационный обмен между различными АБС, а также с другими банковскими программными продуктами;
• загрузка извне нормативно-справочной информации и передача ее между элементами АБС;
• загрузка поставляемого контента (курсов валют, ценных бумаг, биржевых сводок и пр.);
• предоставление регулярных регламентированных отчетов и сведений в надзорные, контролирующие, налоговые, таможенные и прочие уполномоченные структуры;
• разовое и эпизодическое предоставление сведений в различных практических ситуациях;
• архивирование любого рода данных.
Понятно, что каждое из перечисленных направлений настолько широко, что охватить их все, хотя бы кратко, в рамках одной статьи вряд ли возможно. Ограничимся лишь некоторыми идеями, дабы дать представление о возможных преимуществах и проблемах.
XML изначально предназначался в том числе для организации эффективного с точки зрения загрузки каналов электронного документооборота (ЭДО), в котором содержание передаваемых документов — изменчивая составляющая ЭДО — было бы отделено от сведений об их представлении, существенно реже меняющихся и поэтому не требующих постоянной трансляции вместе с документами. Кроме того, само это описание представлено в стандартизированном виде — существуют независимые средства обработки сообщения по этому описанию, не связанные с конкретным форматом. К сожалению, ко всем перечисленным выше видам документооборота в АБС такая особенность XML имеет весьма отдаленное отношение, а его использование иногда приводит к обратному эффекту (мы уже говорили об этом выше). Дело в том, что форматы сообщений ЭДО в АБС довольно жестки и меняются не так часто и радикально, чтобы вынесение в «абстракции» сведений об их представлении оказалось бы оправданным, и, соответственно снизило бы издержки.
В большинстве случаев традиционный прямой разбор с помощью скрипта содержимого сообщения полностью удовлетворяет потребности в модификации. Но если вести речь о жизненном цикле АБС как программного продукта, и в первую очередь в части разработки, сопровождения и развития, то польза от применения XML очевидна. При этом необходима соответствующая организация процессов жизненного цикла, отражающая широкое применение CASE-технологий, среди возможностей которых — формирование шаблонов XML-документов и кода для их обработки непосредственно на основе моделей данных и бизнес-процессов, что открывает для документооборота внутри и вне АБС новые перспективы.
Те же соображения, но еще с некоторыми дополнениями возникают, если речь идет о взаимодействии между элементами АБС. Понятно, что имеется в виду не столько документооборот, сколько обмен данными на технологическом уровне. XML может оказаться весьма полезным и здесь: он позволит без особых усилий реализовать полноценные рабочие места пользователей на базе существенно более «тонких» клиентов (например HTML-приложений) или даже совсем «тонких» (веб-браузеров). При этом останутся доступными все преимущества клиент—серверной архитектуры, включая развитую обработку информации на стороне клиента. Ключевым здесь является то, что представление и обработка данных разделены. Это разделение и ранее было вполне возможно, но требовало столь серьезных затрат от разработчиков и поддерживающего персонала, что только самые крупные и амбициозные проекты могли себе это позволить.
Реализация взаимодействия между разнородными системами от разных, зачастую конкурирующих разработчиков, в том числе реализованными на различных платформах, — чрезвычайно важная проблема банковской жизнедеятельности. Вспомните, сколько раз вы пробовали заставить работать совместно продукты различных производителей (скажем, фронт-офис одной АБС с бэк-офисом от другой)? При этом обычно проблема состоит не в невозможности трансляции данных из формата одной АБС в другую, а в концептуальных различиях во взглядах разработчиков на то, как, собственно, устроен банковский бизнес-процесс. Тем не менее с внедрением XML решается хотя бы вопрос трансляции форматов. Кроме того, единство форматов обеспечивает определенное сходство использующих их систем, исключая ситуацию, когда в одной из них недостаточно информации. XML прекрасно проявляет себя как универсальный «межъязыковый» инструмент, понятный всем взаимодействующим системам, не говоря уже о том, что существуют базирующиеся на XML мощные специальные средства для организации и поддержки такого взаимодействия (EAI, EAS и др.).
Родственная задача экспорта и импорта разного рода данных в АБС (отчетов, НСИ и пр.) — это, пожалуй, самая благодарная сфера применения XML, где в ближайшее время следует ожидать наиболее существенные подвижки. Здесь большую активность проявляет Банк России — уже сейчас на его сайте доступен XML-контент, вполне отвечающий понятию НСИ. В скором будущем следует ожидать повсеместного введения стандартов XML-предоставления отчетности в государственные органы, а также расширения номенклатуры предоставляемой НСИ (например, включения данных для средств проверки на причастность к терроризму).
Очень важным и многообещающим выглядит применение XML для получения отчетности всех форм и видов. Все мы знаем, как сложно сохранить отчет в электронной форме, не потеряв при этом возможности вывода его на печать. Да, текстовый отчет легко сохраняется в недрах базы данных, но сейчас он производит гнетущее впечатление и напоминает о счетах, арифмометрах и бухгалтерских гроссбухах. Современный же отчет — с широким использованием шрифтов, с форматированием — либо практически нельзя сохранить неизменным, либо нельзя обрабатывать после его сохранения. Здесь XML помогает тем, что формат документа (собственно XML) отделен от его представления, что позволяет сохранять отчеты в компактной и удобной для машинной обработки (например, для поиска) форме без потери разнообразия шрифтов, форматирования, прочих преимуществ современных средств отображения информации.
Значительный объем базы в АБС занимают архивированные данные. XML позволяет хранить информацию в БД независимо от ее структуры и формата, а также ускоряет и стандартизирует ее поиск. Не исключено, что ваша АБС не поддерживает, к примеру, полнотекстовый поиск — внедрение его является довольно сложной задачей. Но, выгрузив данные в формате XML, вы сможете воспользоваться уже существующими решениями, просто указав для них атрибуты, которые необходимо проиндексировать, и способ представления найденных данных — опять-таки в виде стандартного XML-документа.
В заключение хотелось бы сказать несколько слов об одной очень важной для банковских технологий особенности XML — использовании электронной цифровой подписи. Она давно уже стала повседневностью в межбанковском взаимодействии и сейчас активно продвигается во внутрибанковский документооборот. Например, в АБС RS-Bank V.6 реализованы развитые средства для организации полноценного внутреннего ЭДО на основе применения ЭЦП, и уже имеются примеры практического использования этой технологии в банках. В результате не только повышается безопасность (что само собой разумеется), но и упрощаются бизнес-процессы, поскольку в ряде случаев появляется возможность отказаться от дополнительного контроля за прохождением и правильностью документов.
Когда документы имеют «жесткое» представление, использование ЭЦП очевидно. Например, если сообщение выгружается в систему межбанковских расчетов в виде файла, то ЭЦП накладывается на весь файл с помощью штатной функциональности применяемого средства ЭЦП. Сохранность файла с точностью до бита вплоть до проверки ЭЦП на приемном конце гарантирует, что ЭЦП останется подлинной, а документ подлежит исполнению.
С XML все по-другому. Один и тот же XML-документ на разных этапах своего существования может иметь различное представление. Атрибуты элементов могут быть переставлены местами в открывающем теге, где они упомянуты. В любом фрагменте текста могут появиться или, наоборот, быть удалены символы пробелов. Ссылочные сущности, особенно внешние, могут получать самое разное значение. Многие из таких преобразований (упомянута лишь малая их часть) производятся в технологических целях и не приводят к изменению содержания документа, а значит он, по идее, по-прежнему подлежит исполнению. Но на самом деле это не так, поскольку подобные изменения разрушают целостность документа, подписанного ЭЦП, которая, как известно, чувствительна к изменению даже одного-единственного бита.
Для решения этой проблемы применяется процедура так называемой канонизации XML-документа, которая позволяет свести различные представления одного и того же документа к точно соответствующему общему виду — «канонизированному представлению». Такой документ можно подписывать ЭЦП и в дальнейшем, на приемном конце, вновь приведя его к канонизированному представлению, удостовериться в его подлинности, проверив имеющуюся в нем ЭЦП.
Еще одной особенностью применения ЭЦП в XML является включение тела ЭЦП непосредственно в состав подписанного документа в виде отдельного элемента (при этом подписываемая часть документа содержится в других элементах этого же документа). Важно отметить, что поскольку тело ЭЦП обычно имеет двоичную форму, а XML — текстовую, в обязательном порядке необходимо преобразовать тело ЭЦП в текст. Чаще всего это делается с помощью известного алгоритма base64.
К сожалению, самостоятельно реализовать алгоритм канонизации сложно. Также непросто найти и использовать его в готовом виде. Например, компания Microsoft включила его только в технологию .NET, в то время как анализатор XML присутствует в ее продуктах уже много лет.
Нам представляется, что имеет право на существование и другой, альтернативный способ подписания XML-документов (без канонизации). Он не столь универсален и зависит от прикладной задачи, но во много раз проще, поскольку основан на тех же процедурах разбора XML-документа, которые используются в прикладных целях. В RS-Bank V.6 он нашел выражение в виде концепции так называемого блока целевой информации (БЦИ), т. е. в изначальном представлении подписывается не весь документ, а только извлеченная из него содержательная часть, нужным образом отформатированная. В банковских системах такой подход становится все более популярным.
XML уже пришел в банковские технологии, всерьез и надолго. Если ваша АБС еще не поддерживает полноценную XML-обработку, то эту проблему пора решать. И чем шире будет XML-поддержка, тем лучше. Новые задачи для нее будут появляться одна за другой: УФЭБС Банка России надо бы сравнивать, пожалуй, не с первой ласточкой, а со стартовым выстрелом. Это то, что касается внешних по отношению к АБС задач. Но нет сомнений, что и внутрибанковские задачи, особенно для кредитных учреждений с развитой территориальной и организационной структурой, станут по мере освоения XML-технологии благодатным полем для применения ее безграничных возможностей.

Об авторах: Ветров С. Г. — ведущий аналитик департамента банковского ПО R-Style Softlab;
Кингсеп Павел Сергеевич — ведущий аналитик департамента банковского ПО R-Style Softlab.