Платформа для интеграции АБС

В статье рассматриваются существующие задачи по интеграции систем в банке и пути их решения с целью выбора наиболее оптимального подхода.

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

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

Задачи интеграции приложений и пути их решения

Для выбора оптимального подхода в интеграции приложений рассмотрим характерные задачи организации взаимодействия модулей и объективные сложности их решения.

Задачи и проблемы

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

В различных банках уже сложились традиционные направления интеграции модулей. Вот некоторые из них:

• "Операционный день" - транспортный модуль платежной системы (РЦИ, SWIFT, внутрибанковская платежная система с филиалами).
• "Операционный день" - система "клиент-банк", "интернет-банк".
• Системы "клиент-банк" - система автоматизации предприятия.
• АБС - Хранилище данных.
• АБС - CRM-система.

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

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

Существуют еще и дополнительные сложности:

• Модули могут функционировать на разных программно-аппаратных платформах (операционная система, СУБД). В связи с этим возникают проблемы межплатформенного взаимодействия.
• Модули зачастую реализованы в различных архитектурах ("файл-сервер", "клиент-сервер"). Это приводит к необходимости применять различные технологии доступа к данным.
• Модули нередко содержат одинаковые информационные объекты, выполненные в различных логических структурах. Например, представление валютного лицевого счета в разных системах значительно отличается друг от друга по структуре базы данных, различна и логика процедур доступа к данным в различных модулях.
• В базах данных модулей для полей, несущих одну и ту же смысловую нагрузку, могут применяться разные имена и типы, что приводит к необходимости ведения таблиц соответствия полей и процедур преобразования данных.

Способы интеграции приложений

Весь комплекс вопросов необходимо решать независимо от того, какая технология интеграции модулей будет использована. Самих технологий существует множество. Рассмотрим некоторые из них.

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

Существуют более технологичные, но и более дорогие способы интеграции приложений:

• Применение серверов репликации, предназначенных для передачи данных между приложениями. Одним из поставщиков серверов репликации является компания Sybase со своим продуктом Replication Server. Однако технология репликации постепенно сдает свои позиции, поскольку не решает должным образом всех проблем межплатформенного взаимодействия.
• Применение серверов транзакций. Представитель - сервер Tuxedo System от компании Jet Infosystems. Сервера транзакций позволяют обеспечить распределенную обработку данных. Их применение наиболее целесообразно в проектах, где требуется высокая оперативность в передаче данных между приложениями, в противном случае применение неоправданно по затрачиваемым усилиям для их внедрения.
• Применение систем класса Middleware, обеспечивающих моделирование бизнес-процессов в разнородных приложениях. Например, PIE (Processware Integration Environment) - комплекс программных продуктов для интеграции разнородных бизнес-приложений от компании CMA Small Systems AB. В отличие от схемы взаимодействия "каждый с каждым", приводящей к росту количества интерфейсов в квадратичной прогрессии, такие средства подразумевают объединение приложений по схеме "звезда".
• Применение систем класса Middleware, обеспечивающих передачу структурированной информации между различными приложениями. Например, платформа WebSphere от IBM, сервер BizTalk от Microsoft, где передача данных между модулями выполняется по схеме "каждый с каждым", однако количество интерфейсов к модулям при этом не растет в квадратичной прогрессии. Это достигается за счет применения единого формата передачи данных между модулями.
• Применение Хранилища данных. Например, система "Контур Корпорация" компании Intersoft Lab. Интеграция модулей в этом случае выполняется по схеме "звезда", обеспечивая сбор информации из разнородных приложений в единую базу данных - Хранилище. Количество интерфейсов в этом случае равно количеству самих приложений.

Независимо от выбранной технологии интеграции модулей необходима разработка специальных программ ? "адаптеров" для каждой функции каждого приложения, обеспечивающих выгрузку или загрузку передаваемых данных. Эти "адаптеры" оперируют внутренним представлением данных конкретного приложения.

"Межмодульный" формат передачи данных - оптимальный способ интеграции приложений

Для обеспечения взаимодействия приложений целесообразно принять "межмодульный" формат представления данных. Его использование позволяет разрабатывать универсальные "адаптеры", способные "стыковаться" не с одним, а с множеством приложений. Применение "межмодульного" формата представления данных приводит к разделению процесса разработки интеграционных процедур на две части:

• Разработка процедур доступа к данным во "внутреннем" формате приложения.
• Разработка процедур преобразования "внутренних" форматов представления данных в "межмодульный" формат.

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

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

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

Язык XML. Базовые понятия

XML (eXtensible Markup Language) - это расширяемый язык разметки документа, позволяющий представлять в текстовом формате сложные, иерархические объекты. Язык XML разработан под патронажем международной организации World Wide Web Consortium (W3C), является международным стандартом (ISO 8879). Формальное описание языка XML содержится в документе: "Extensible Markup Language (XML) 1.0 (Second Edition)" на www.w3.org/TR/2000/REC-xml-20001006, где определен синтаксис и представлены рекомендации и соглашения для разработки текстовых форматов данных.

Синтаксис языка XML обеспечивает однозначное описание любых данных, определяя разметку документов с помощью тегов и атрибутов. Язык XML вводит понятие корректного XML-документа ? то есть документа, подчиняющегося формальным правилам разметки (синтаксису). Однако XML не определяет семантику применяемых тегов и использует их лишь для структурного разграничения данных. Смысловая интерпретация информации целиком возлагается на программное обеспечение, применяющее XML-документы.

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

Правила описания данных в XML-документе определяются соответствующими нотациями, или, иначе говоря, диалектами языка XML. В настоящее время существует множество языков описания разметки XML-документов ? DTD, TREX, RELAX, XML Schema и другие, придерживающихся как регулярной грамматики, так и правил с использованием выражений для определения утверждений. Однако после опубликования W3C XML Schema Recommendation ? рекомендаций по построению XML-схем ? эта нотация языка XML стала наиболее распространенной.

XML Schema определяет типы документов и типы данных в них. На этом уровне описания XML-документа вводится понятие состоятельности (действительности) документа. XML-документ считается состоятельным, если с ним ассоциировано определение типа документа и если документ соответствует ограничениям, описанным в этом определении. Состоятельность XML-документа может проверить программное обеспечение, обладающее данными о типе и других ограничениях документа.

Язык XML. Прикладные форматы

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

Пространство имен подразумевает свое использование широким набором приложений, в том числе таких, которые могут оперировать документами, содержащими данные, описываемые в других словарях.

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

• Способ 1. Разработчики "адаптеров" к прикладным программам могут самостоятельно разработать свое Пространство имен, содержащее теги передаваемых данных. Но в этом случае их применение будет ограничено рамками одной организации.
• Способ 2. Разработчики могут воспользоваться "чужим" опытом в разработке XML-форматов. Как показывает мировая практика, такой подход является оптимальным. В настоящее время в мире функционируют различные партнерства, сообщества, комитеты и организации, целью которых является разработка отраслевых XML-форматов. Но воспользоваться результатами их работы непросто ? сначала необходимо адаптировать эти форматы к российской специфике.
• Способ 3. Разработчики могут использовать результат деятельности российских сообществ и партнерств по разработке XML-форматов. В частности, воспользоваться архивом библиотек форматов от различных компаний-разработчиков, размещенным на веб-сайте Ассоциации российских банков в разделе материалов секции по Интернет-технологиям по адресу: http://www.arb.ru/comitets/workgroup/title.htm. Этот архив собран рабочей группой по разработке и стандартизации форматов обмена электронными документами между банками и их клиентами, действующей в рамках работы Комитета по информатизации и банковским технологиям Ассоциации российских банков.

Пример использования XML в задачах интеграции приложений

Среди библиотек форматов, собранных рабочей группой АРБ, представлен Dynamic XML - язык для интеграции бизнес-приложений с применением Хранилищ данных. Этот язык был разработан компанией Intersoft Lab при создании системы "Контур Корпорация".

Dynamic XML - динамически расширяемый язык XML

Dynamic XML - язык, который предполагает использование динамических, легко расширяемых форматов, ориентированных на описание информационных объектов финансовой и хозяйственной деятельности организаций (бизнес-объектов).

В основу модели интеграции бизнес-приложений с применением Dynamic XML положены следующие принципы:

• Построение форматов Dynamic XML выполняется в соответствии с базовыми требованиями языка XML.
• Применяется объектная модель описания данных.
• Предусматривается возможность расширения форматов обмена данными без остановки эксплуатации процессов передачи данных.

Документы, описанные при помощи языка Dynamic XML, являются корректными, то есть подчиняются правилам разметки, определенным в языке XML v.1.0 (Second Edition).

Состоятельность XML-документов проверяется системой "Контур Корпорация", обладающей данными о типе и других ограничениях документов.

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

В общем случае структура XML-документа, выполненная в нотации Dynamic XML, имеет вид:

<?xml version="1.0" encoding="windows-1251"?>
<?Contour version="1.2"?>
<Сеанс>
    Объект "Контрольный лист сеанса"
    ...
    Объект "Действие"
    ...
    Объект "Данные"
    ...
<ЗавершитьСеанс/>

Первая строка в приведенном фрагменте XML-документа содержит информацию о том, что данный документ является XML-документом, указывает версию спецификации XML, а именно - 1.0, которой данный XML-документ соответствует, а также указывает кодировку, в которой представлен текст XML-документа. Здесь windows-1251 означает, что все буквы в тегах XML-документа будут либо латинскими, либо русскими в кодировке ANSI.

Вторая строка определяет, что документ находится в пространстве имен, идентифицируемом при помощи словаря метаданных системы "Контур Корпорация" версии 1.2.

Далее следует тело сеанса передачи данных, заключенное между тегами <Сеанс> и . Внутри сеанса располагается описание объектов трех типов:

• "Контрольный лист сеанса", который содержит служебную информацию, управляющую процессом передачи данных и обеспечивающую взаимодействие процедур выгрузки и загрузки данных.
• "Действие". Этот объект содержит команды, определяющие различные режимы передачи данных - первоначальная загрузка, удаление, ежедневная загрузка и т.д.
• "Данные". Это основной тип данных, который содержит передаваемые данные в соответствии с объектной конструкцией передаваемой информации. Для каждого вида объекта данных существует XML-формат, который расширяется и видоизменяется в зависимости от требований к составу передаваемых данных.

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

• Субъект- юридические и физические лица, с которыми взаимодействует банк или предприятие: клиенты, поставщики и др.
• Штатная единица - структура банка или предприятия, включающая структуру Главной конторы, филиалов, центров финансового учета, должностей.
• Бизнес-операция - финансовые, административные, хозяйственные операции, выполняемые организацией и отражаемые в документах и счетах.
• Финансовый инструмент - валюты и другие измерения сумм, отражаемые в документах, счетах и показателях организации.
• План - планы счетов или показателей бухгалтерского и управленческого учета.

  - Счет - лицевые\аналитические счета, используемые для аналитического учета бухгалтерских операций.

  - Показатель - регистр учета финансовых показателей, регламентированных правилами бухгалтерского и управленческого учета.

• Документ - различные документы, используемые в деятельности организации: договора, первичные документы, подтверждающие финансовые и хозяйственные операции организации, личные дела сотрудников и др.
• Справочник - бизнес-объекты для хранения возможных значений атрибутов всех базовых объектов.

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

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

Интеграция бизнес-приложений на основе Хранилища данных

В настоящее время язык Dynamic XML применяется в задаче интеграции бизнес-приложений с использованием Хранилища данных. Возможности языка Dynamic XML полностью удовлетворяют требованиям задачи сбора информации в Хранилище данных из различных источников.

Рассмотрим технологию применения языка Dynamic XML для сбора информации из различных бизнес-приложений в Хранилище данных. Например, сбор данных из различных АБС ("RS-Bank" компании R-Style Softlab, "Diasoft 5NT" компании Диасофт, "IBSO" компании ЦФТ и других) в Хранилище данных системы "Контур Корпорация" компании Intersoft Lab.

• В качестве "межмодульного" формата передачи данных используется набор XML-форматов, подготовленных в нотации Dynamic XML с использованием словаря метаданных системы "Контур Корпорация".
• При создании уникального Хранилища данных для конкретного банка в словаре метаданных системы "Контур Корпорация" описываются информационные объекты, подлежащие сбору из АБС филиалов и Главной конторы банка.
• На базе описаний информационных объектов и на основании единых для всех АБС XML-шаблонов автоматически генерируются XML-форматы.
• Процедуры загрузки данных из "межмодульного" формата в Хранилище данных также генерируются системой автоматически. Поэтому усилия по интеграции модулей сосредотачиваются исключительно на разработке "адаптеров", обеспечивающих выгрузку данных из АБС.
• Процедуры по выгрузке данных из АБС в описанном XML-формате разрабатываются на различных языках программирования. Как правило, для этого применяется язык программирования, наиболее удобный для конкретного вида АБС. В частности, для "RS-Bank" (R-Style Softlab) используется язык RSL, для "DiasoftBANK 4x4" (Диасофт) ? язык DiasoftScript, для "Diasoft 5NT" (Диасофт) и "IBSO" (ЦФТ) ? язык SQL.

В помощь разработчикам АБС и службам автоматизации банков для разработки и модернизации "адаптеров" компанией Intersoft Lab предлагается альбом XML-форм, содержащий XML-шаблоны базовых информационных объектов и технология "дистанционного" тестирования процедур выгрузки, когда подготовленные разработчиками XML-документы передаются в компанию Intersoft Lab по электронной почте для проверки их корректности и состоятельности.

Интеграция бизнес-приложений без использования Хранилища данных

Возможности применения языка Dynamic XML не ограничиваются задачей сбора информации из АБС в Хранилище данных. С его помощью можно организовать интеграцию АБС или их отдельных модулей напрямую, минуя Хранилище данных. Для этого дополнительно к процедурам по выгрузке необходимо разработать процедуры загрузки данных для этих модулей.

Важным вопросом в этом случае является определение Пространства имен. Если в ряду интегрируемых модулей присутствует система "Контур Корпорация", то пространство имен обеспечивается ее словарем метаданных. В этом случае система может и не выполнять роль Хранилища информации, а служить только средством для ведения словаря метаданных и формирования XML-шаблонов. В системе предусмотрена возможность свободного обмена словарями метаданных между различными копиями системы. Это свойство позволяет обеспечить регулярное согласование пространств имен, формируемых в различных организациях. Чтобы облегчить авторам приложений и службам автоматизации банков применение языка Dynamic XML без использования системы "Контур Корпорация", разработчики языка Dynamic XML включили в свои планы модернизацию языка в соответствии с W3C XML Schema Recommendation. Результатом этой работы будет изменение приведенного описания структуры XML-документа в соответствии с рекомендациями по разработке XML-схем.

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

Например, таких, как "получить информацию по лицевому счету". Эти процедуры являются методами универсальных информационных объектов финансовой и хозяйственной деятельности организаций. Всю остальную работу ? по преобразованию объектов в XML-представление, проверку состоятельности XML-документов, формирование XML-документов в сеансы для передачи данных система "Контур Агент" возьмет на себя.

Систему "Контур Агент" в минимальной конфигурации планируется бесплатно предоставлять разработчикам АБС и службам автоматизации банков, которые, помимо решения задач по интеграции с системой "Контур Корпорация", смогут применять ее систему для интеграции своих модулей, минуя Хранилище данных.

Автор: В.Чаусов, К.Андреев

Источник: Банки и технологии, 2002, № 1