CC BY
84
УДК 004 (336)
сервис-ориентированная архитектура в банковской сфере
Аннотация. Статья посвящена описанию и анализу сервисов с точки зрения сервис-ориентированной архитектуры в банковской сфере.
Ключевые слова: банк; банковское дело; финансы; сервис; сервис-ориентированная архитектура; интеграция. Abstract. Article is devoted to the description and analysis services in terms of service-oriented architecture in banking. Keywords: bank; banking; finance; service; service-oriented architecture; integration.
Веселовская В.В.,
студентка магистратуры Финансового университета Н Vlada148@rambler.ru
Банки являются неотъемлемой частью экономики современного государства. В условиях повышенной конкуренции и борьбы за клиентов вкупе с ужесточением требований регулятора финансового рынка (ЦБ РФ) перед банками стоят непростые задачи оптимизации бизнес-процессов с максимально эффективным использованием имеющихся в их распоряжении ресурсов. Для достижения этих целей банки широко используют разнообразные ^-компоненты, которые, являясь во многом узкоспециализированными системами, требуют интеграции в единообразный ^-ландшафт. Банковские ^-системы становятся все сложнее, количество их увеличивается, порой до нескольких сотен в одном финансовом учреждении. При этом нужно обеспечивать не только их стабильное взаимодействие, но и постоянное расширение функциональных возможностей для обеспечения эффективности сквозных бизнес-процессов.
В этих сложных условиях растут требования и стандарты качества обслуживания клиентов, внедряются новые услуги, затрагивающие различные области деятельности финансового учреждения. При этом идет сокращение бюджетов на новые системы, а штат персонала расширяется. Банки вырабатывают стратегии оптимизации, эффективной эксплуатации имеющихся ^-систем, расширения общего функционала за счет нтеграции, исполь-
зования и агрегирования данных уже имеющихся систем.
Так, во многих банках используется подход сервис-ориентированной архитектуры, который считается наиболее подходящим и удобным для интеграции банковских систем и не только. Именно поэтому целью данной статьи является определение сервиса в терминах сервисно-ориентированной архитектуры (SOA). Также рассмотрены определение сервиса (в рамках проекта), его жизненный цикл, свойства и возможные уровни сервисов в банковской отрасли.
Сервис в терминах SOA означает одно из фундаментальных понятий, которым оперирует сервисноориентированная архитектура [1].
В общем случае сервис для банка (в терминах SOA) можно определить как повторяющуюся бизнес-операцию, такую как «открыть счет», «проверить баланс» и т. д., реализованную как программная компонента. Он должен иметь интерфейс, описанный при помощи языка WSDL. Приложения вызывают сервисы, используя для взаимодействия XML-сообщения.
Жизненный цикл сервисов в методологии IBM состоит из четырех этапов (рисунок) [2].
• Моделирование (Model). Включает идентификацию и спецификацию сервисов, а также принятие архитектурных решений для их реализации.
• сборка (Assemble). Проводится разработка и сборка сервисов, которые были смоделированы на предыдущем этапе, выполняется тестирование.
в общем случае сервис для банка (в терминах SOA) можно определить как повторяющуюся бизнес-операцию
Научный руководитель: Рыжко А.Л., кандидат экономических наук, доцент.
• развертывание (Deploy). Включает финальное тестирование и размещение разработанных сервисов на сервисной шине.
• Управление (Manage). Осуществляются управление приложениями и сервисами, настройка окружения, управление правами и информационными ресурсами, сбор статистики и бизнес-показателей.
Особенностью жизненного цикла является замыкание фаз управления и моделирования. Это означает, что информация, собранная в фазе управления, используется в качестве входной для продолжения совершенствования решения. Для удобства можно выделить отдельно этап тестирования, так как он сам по себе представляет целый процесс.
На практике может быть удобнее использовать несколько измененный вариант жизненного цикла сервиса, более приближенный к типовым стадиям разработки и внедрения программных продуктов. Он состоит из следующих этапов.
• Моделирование. Проводятся первоначальное выделение сервисов, специфицирование и определение способов их реализации.
• разработка. Проходит реализация сервиса на основании решений, принятых на этапе проектирования.
• тестирование. Проводится всестороннее тестирование разрабатываемого сервиса.
• Приемка. Проверяются сценарий размещения сервиса в среде, идентичной рабочей, и регрессионное тестирование с использованием подготовленных сценариев или специальных инструментов.
• опытная эксплуатация. Проверяется работа сервиса в реальных условиях, т.е. в рабочей среде с реальными данными.
• Промышленная эксплуатация. Штатная эксплуатация.
• вывод из эксплуатации. Удаление сервиса, т.е. исключение его из реестра сервисов рабочей среды исполнения.
Ниже будут более подробно рассмотрены этапы жизненного цикла сервисов.
1. Моделирование
Данный этап является, наверное, самым важным с точки зрения сервисно-ориентированного подхода, так как именно на нем проводятся начальная идентификация и дальнейшее проектирование сервисов.
При идентификации сервисов главная задача -первоначальное выделение сервисов, т.е. получение списка так называемых кандидатов в сервисы. На данном этапе важно выделить сервисы с точки
особенностью жизненного цикла является замыкание фаз управления и моделирования
зрения бизнес-функциональности, т.е. выделенный сервис должен представлять собой осмысленную бизнес-операцию.
В рамках этапа идентификации используют три метода начального выделения сервисов: Domain decomposition, Existing asset analysis и Goal service modeling.
• Domain decomposition. Представляет собой метод идентификации сервисов «сверху вниз» (top down), при котором проводится декомпозиция бизнес-доменов на более мелкие составные части до тех пор, пока не будет достигнут уровень базовых сервисов - сервисов, предоставляющих базовую бизнес-функциональность, поставляемую одной системой. Данный метод состоит из двух шагов:
• анализ функциональных областей (Functional Area Analysis, FAA). «Разбиение» бизнеса на функциональные части. Позволяет в дальнейшем категоризировать сервисы,распределив их по этим функциональным частям бизнеса;
• декомпозиция бизнес-процессов (Process Decomposition). Разбиение бизнес-процессов на подпроцессы, вплоть до атомарных активностей. Полученная в результате такого разбиения модель отражает последовательность событий бизнес-процессов и определяет кандидатов в сервисы. Каждая активность в дереве модели процессов - потенциальный кандидат в сервисы.
• Existing asset analysis. Представляет собой метод «снизу вверх» (bottom-up), при котором базовые сервисы выделяются исходя из возможностей системы, предоставляемых ее API. Данный метод позволяет скорректировать список сервисов, выделенных на этапе доменной декомпозиции, исходя из возможностей API конечных систем. Использование совместно подходов доменной декомпозиции и анализа активов позволяет, с одной стороны, получить кандидатов в сервисы, реализующие осмысленную бизнес-функциональность, а с другой стороны, реализуемые со стороны API конечных систем.
• Goal service modeling (GSM). Представляет собой метод проверки полноценности набора сервисов, выделенных на прошлых этапах, путем сопоставления их с бизнес-целями банка. В большинстве своем бизнес-цели банка формулируются представителями бизнеса нечетко или слишком абстрактно. Поэтому необходимо проводить их декомпозицию на подцели до тех пор, пока не определится функциональность, с помощью которой будет реализована данная подцель. В результате использования метода могут появиться новые кандидаты в сервисы.
При инициализации сервисов в банке необходимо совместно использовать оба метода пер-
воначального выделения сервисов - Domain decomposition и Existing asset analysis. Использовать их надо последовательно - при таком подходе первый из примененных методов позволит получить список сервисов, а второй - скорректировать список.
Выделение сервисов методом Existing asset analysis должно проводиться в том случае, если система, которая должна реализовывать функциональность сервиса, имеет хорошо специфицированное API. В таком случае корректировка полученного списка сервисов проводится методом Domain decomposition. В результате сервисы, выделенные таким образом,заведомо реализуются API конечной системы, но при этом соответствуют бизнес-задачам и их количество неизбыточно.
Если система не имеет хорошо специфицированного API, то первым следует использовать метод Domain decomposition, по результатам применения которого проводится анализ на возможность реализации данных сервисов текущим API конечной системы и выдвигаются требования на его доработку.
Метод Goal service modeling используется для проверки полноты набора ранее сформированного списка кандидатов в сервисы только в том случае, если у банка есть сформированный список целей. Если списка нет, то использование метода невозможно.
Результатом применения перечисленных методов должно стать получение списка кандидатов в сервисы в виде списка всех идентифицированных сервисов. Из полученного после идентификации списка необходимо выделить сервисы, подлежащие реализации в первую очередь. Для их выбора задается список критериев, по которым оценивается каждый из потенциальных кандидатов. В качестве основных критериев можно использовать следующие.
• Соответствие бизнесу (Business Alignment) -те сервисы, которые смогли (в результате GSM-анализа) «привязаться» к бизнес-целям банка, имеют приоритет перед остальными.
• Повторное использование (Composability & Reusability) - те сервисы, которые уже на этапе
При инициализации сервисов в банке необходимо совместно использовать оба метода первоначального выделения сервисов - Domain decomposition и Existing asset analysis
проектирования определены для использования в нескольких бизнес-процессах (повторно используются другими процессами), имеют приоритет перед остальными.
• Сложность реализации (FeasibiLity of ^р1е-mentation) - оценивается смысл реализации сервиса с точки зрения ограниченности временных и финансовых ресурсов.
После того как каждый сервис получает приоритет реализации, т.е. становится известно, в какой последовательности будут реализованы кандидаты в сервисы, начинается разработка спецификаций сервисов (часто называется паспортом сервиса). В спецификацию включаются сведения о сервисе, в том числе о политике его использования и пр.
При разработке спецификации сервиса наиболее внимательно следует подходить к сбору нефункциональных требований, так как именно они должны содержать требования к производительности сервиса, возможностям масштабирования и пр. Ошибки в выявлении данных требований и неправильное планирование будущих нагрузок на сервис могут привести к тому, что он станет «узким местом» интеграционного решения. Например, производительность композитного сервиса будет напрямую зависеть от производительности самого «медленного» базового сервиса, входящего в его состав.
Если проектируется композитный сервис, то необходимо, чтобы все сервисы, входящие в его состав, были надлежащим образом специфицированы, а потом уже начиналось построение из них композита. Проектирование композитного сервиса - это задача представления декомпозированных на этапе идентификации сервисов бизнес-процессов в виде «оркестровки» специфицированных базовых сервисов.
После разработки спецификации необходимо определить особенности реализации сервисов.
В рамках данной задачи необходимо определить, как имеющуюся функциональность систем банка можно использовать при реализации сервисов и как при этом будут выполняться нефункциональные требования в части обеспечения производительности, доступности и т.д. Для этого проводят технический анализ возможностей по реализации (Technical Feasibility Analysis, TFA). Он включает в себя детальный анализ существующих систем банка с целью определить, какую часть их функциональности можно использовать для реализации сервисов и, главное, как ее использовать, а также надо ли что-либо модифицировать и почему.
Следует отметить, что разработка спецификации и проведение технического анализа возможностей реализации - итеративные процессы, и результаты технического анализа могут вызвать изменение спецификации. На основе технического анализа принимаются решения о том, как необходимо реализовывать специфицированные сервисы. Для каждого сервиса существуют следующие альтернативы реализации.
В зависимости от критерия «Какой сервис использовать»:
• интеграция (Integration). Использование в качестве сервиса функциональности существующих приложений. В таком случае сервис реализуется как фасад над существующей функциональностью конечных систем;
• трансформация (Transformation). Трансформация/доработка части существующих приложений и выставление их «наружу» как сервисы.
• В зависимости от критерия «Как получить сервис»:
• покупка (Buying). Покупка продукта от поставщика, который предоставляет свою функциональность в виде требуемых сервисов;
• разработка (Building). Разработка необходимого для сервиса функционала своими силами либо силами внешнего исполнителя;
• подписка (Subscribe). Использование функционала внешнего провайдера, который предоставляет его как необходимый банку сервис с нужными функциональными и нефункциональными характеристиками и соответствующим SLA. Для банков, например, это может быть процессинг кредитных карт, предоставляемый аккредитованной компанией.
После того как сервис идентифицирован, специфицирован и приняты решения по особенностям его реализации, можно приступать непосредственно к этапу «Разработка».
Если проектируется композитный сервис, то необходимо, чтобы все сервисы, входящие в его состав, были надлежащим образом специфицированы, а потом уже начиналось построение из них композита
На основе технического анализа принимаются решения о том, как необходимо реализовывать специфицированные сервисы
2. разработка
На данном этапе проходит реализация сервиса на основании спецификации, разработанной на этапе проектирования. Работы, проводимые на данном этапе, зависят от принятых на прошлом этапе архитектурных решений. Помимо этого, одной из задач является подготовка и проведение модульного тестирования (unit test). При реализации композитных сервисов (основанных на результате работы других сервисов предприятия) должна быть подготовлена тестовая среда, предоставляющая доступ к реальным сервисам или их заместителям. В случае если в процессе реализации сервиса выявляются архитектурные ошибки, процесс разработки останавливается и задание возвращается на доработку.
Результатом данного этапа являются программные модули, готовые к размещению в тестовой среде, и инструкции по их развертыванию и запуску.
3. Тестирование
На данном этапе проводится всестороннее тестирование разрабатываемого сервиса. Оно должно включать функциональное и нагрузочное тестирование в тестовой среде.
Сервисы являются компонентами распределенного решения. В связи с этим ключевое значение имеет этап интеграционного тестирования в среде, наиболее близкой к рабочей. Необходимо подготовить такую среду, создать план тестирования и подготовить тестовые данные для определения соответствия реализации сервиса функциональным и нефункциональным требованиям. Тестирование нефункциональных требований крайне важно, так как именно оно может выявить слабые места интеграционного решения.
4. Приемка
На этапе приемки проводится проверка сценария размещения сервиса в среде, идентичной рабочей, и регрессионное тестирование с использованием подготовленных сценариев или специальных инструментов. Результатом данного этапа является акт приемки. В случае обнаружения критических ошибок сервис возвращается на доработку.
5. Опытная эксплуатация
На этапе опытной эксплуатации проводится проверка работы сервиса в реальных условиях, т. е. в рабочей среде с реальными данными. Так как сервис находится в стадии опытной эксплуатации, это подразумевает наличие ограничений на его использование. Одним из таких ограничений мо-
жет являться запрет на повторное использование в других проектах на этапах опытной и промышленной эксплуатации.
Результатом данного этапа является акт приемки в промышленную эксплуатацию. В случае обнаружения критических ошибок сервис возвращается на доработку. Начиная с этого момента, необходимо обеспечивать его работу в соответствии с прилагаемыми условиями контракта сервиса.
6. Промышленная эксплуатация
Данный этап жизненного цикла сервиса подразумевает штатную эксплуатацию. Начинаются повторное использование сервиса и его технический мониторинг, проводится анализ оптимальности функционирования.
Этап длится до вывода сервиса из эксплуатации. Важным здесь является то обстоятельство, что даже с появлением новой версии старая версия продолжает использоваться, пока имеются ее потребители.
7. Вывод из эксплуатации
Последней стадией жизненного цикла сервиса является его удаление. Удаление невозможно до тех пор, пока у сервиса есть потребители. Этот или другие сервисы (в случае вхождения сервиса в состав композитного), или приложения, использующие сервисы. Когда потребитель приступает к использованию сервиса, возникает зависимость, которой в дальнейшем необходимо управлять. При появлении такая зависимость должна регистрироваться в репозитории сервисов (пусть даже репозиторий ведется в Ехсе1).
Пока все потребители сервиса не прекратили его эксплуатацию, сервис не может быть удален.
В банке должен быть разработан регламент на количество одновременно поддерживаемых версий сервисов. Он утверждается на этапе планирования сервиса. При его утверждении должны приниматься во внимание технические возможности среды исполнения, возможности поддерживающих компонентов (базы данных, приложения и пр.) и затраты на сопровождение.
Все сервисы можно разбить на три большие группы.
• Базовые сервисы. Предоставляют базовую бизнес-функциональность, по сути, являясь функциями, реализованными в системе. Свойства базовых сервисов:
• интерфейсы объединяют операции,отражающие функции, предоставляемые одной системой;
• сервисы могут вызываться синхронно и не имеют состояния;
Таблица
Изменения свойств сервиса
Свойства сервиса Базовые Композитные Бизнес-процессы
Самодостаточность Важно Важно Важно
Отсутствие состояния Важно Важно Неприменимо
Готовность для повторного использования Важно Не очень Не важно
Укрупненность Не очень Важно Важно
Видимость Важно Важно Не важно
Идемпотентность Важно Важно Не важно
Интероперабельность Важно Важно Не важно
• поддержка транзакционности важна для дальнейшего их объединения в композитные сервисы;
• при идентификации таких сервисов можно использовать как метод «сверху вниз», так и метод «снизу вверх», если система, предоставляющая необходимый функционал, имеет хорошо специфицированный API;
• сервисы должны планироваться для повторного использования;
• реализация таких сервисов основана на взаимодействии с адаптерами к системам и трансформации данных в каноническую модель данных.
• Композитные сервисы. Объединяют несколько базовых сервисов для решения прикладной задачи. Такой способ организации взаимодействия называется «оркестровкой» сервисов и реализуется, как правило, в виде бизнес-процесса без состояния. Свойства композитных сервисов:
• как правило, вызываются синхронно и не имеют состояния;
• при идентификации используется, как правило, метод «сверху вниз»;
• имеется возможность повторного использования.
• Бизнес-процессы. Самый высший уровень композиции бизнес-сервисов. Обычно являются реализацией конкретной бизнес-цели и объединяют для совместной работы базовые сервисы, предоставляемые различными системами, композитные сервисы, а также людей. Свойства бизнес-процессов:
• как правило, вызываются асинхронно и имеют определенное состояние;
• представляют собой реализацию конкретной бизнес-цели, например принятия решения по кредитной заявке.
Стоит рассмотреть свойства сервисов. Основные
требования к базовому сервису при его разработке можно сформулировать следующим образом.
• Самодостаточность (Self-Contained). Необходимо стремиться к уменьшению зависимости от других сервисов, сложных типов данных, внешних систем. Это необходимо в распределенных средах со множеством владельцев для упрощения сопровождения сервиса.
• Отсутствие состояния (Stateless). Использование должно быть максимально простым и удобным. Правила вызова не должны зависеть от какой-либо инициализации или вызова других сервисов.
• Готовность для повторного использования (Reusable). Возможность повторного использования части функциональности при решении различных задач является ключевой особенностью SOA. Размещение в репозитории сервисов и использование канонической модели данных повышает готовность сервиса к повторному использованию.
• Укрупненность (Coarse-Grained). Сервис должен выполнять осмысленную бизнес-операцию, поэтому не следует проводить декомпозицию до слишком низкого уровня. Низкоуровневые сервисы сложны в использовании, т. е. сервис должен работать не с элементарным набором данных,а с данными, представляющими единое целое с точки зрения бизнеса. Например, сервис создания клиента получает в качестве входных данных и персональную информацию о клиенте: фамилию, имя и т.д., и информацию о его удостоверениях личности и адресах. Но надо учитывать, что при создании очень крупных сервисов будет существенно возрастать сложность модификации их функционала, а также их количество.
• Видимость (Discoverable). Для того чтобы использовать сервис, необходимо знать, где он размещается. Сервис должен быть размещен в реестре, чтобы другие программные компоненты могли на-
ходить его и использовать. Альтернативный вариант - использование сервисов, минуя централизованный реестр, серьезно усложняет сопровождение SOA-ландшафта в целом, теряется информация о взаимосвязях потребителей с поставщиками сервисов.
• идемпотентность (Idempotent). Свойство сервиса, заключающееся в том, что многократное повторение вызова не приводит к изменениям, отличным от вызова однократного. Например, если при обращении к сервису заведения нового клиента произошел сбой и ответ об удачном/неудачном завершении операции не был получен, то неизвестно - выполнена ли операция успешно? Идемпотентность сервиса заключается в том, что если клиент все-таки был «заведен» успешно, повторный вызов сервиса с теми же параметрами не создаст дублирующую запись. При проектировании сервисов, работающих через HTTP (WebServices, SOAP over HTTP), надо учитывать, что этот протокол не обеспечивает гарантированной доставки, и поэтому идемпотентности сервисов надо уделять особое внимание.
• интероперабельность (Interoperable). Сервисы, предоставляемые различными системами, должны уметь взаимодействовать. Для этого они должны использовать единую модель данных, стандартизированные протоколы реализации.
Важным здесь является то обстоятельство, что свойства сервиса меняются в зависимости от принадлежности к базовым, композитным либо бизнес-процессам. Например, свойство отсутствия состояния (Stateless) является важным при проектировании базового сервиса, но оно неприменимо по отношению к бизнес-процессам, по определению представляющим собой последовательность взаимосвязанных задач (вызовов сервисов).
Изменения свойств при переходе от базовых сервисов к композитным и бизнес-процессам представлены в таблице.
Нефункциональные требования к сервисам относятся по большей части к вопросу содержания их контракта. Контракт специфицирует взаимодействие потребителя сервиса с его поставщиком и содержит дополнительные атрибуты сервиса, такие как OoS (Quality of Service), SLA и пр. С точки зрения потребителя сервиса, контракт - это все, что следует знать, когда используешь сервис. Контракт сервиса должен быть указан в спецификации сервисов банка.
Исходя из описанных выше свойств сервисов и их жизненных циклов, следует сделать вывод, что использование их в банковской сфере оправдано
и выгодно, а преимущества данного подхода очевидны.
Стоит отметить, что использование сервисов в ИТ-архитектуре банка во многом упрощает интеграцию систем, так как их взаимодействие не зависит от языка или платформы, на которых реализован конкретный сервис, так как основной важной стороной сервиса является протокол взаимодействия.
Немаловажным преимуществом является возможность физически развернуть сервис как на стороне конкретной системы, так и на стороне универсальной банковской шины, что снова дает возможность реализации распределенной неоднородной структуры.
Одним из самых важных преимуществ использования сервисов является возможность их пере-использования. При интеграции в случае потребности использования сервисов различных систем нет необходимости заново создавать функционал, поскольку есть возможность получать данные путем вызова уже существующих сервисов. Также возможна агрегация данных, полученных из различных сервисов, для дальнейшего использования уже агрегированных данных, а не разрозненных частей одного целого, что имеет огромное значение в постоянно развивающемся банковском секторе. Так, например, при выдаче кредита необходимо решить целый ряд задач, таких как проверка клиента на принадлежность к «черным спискам», заведение заявки на кредит, запрос кредитной истории клиента, передача данной истории в виде сводного отчета и т.д. На данный момент не существует ни одной банковской системы, осуществляющей все эти функции. Поэтому для автоматизации данного процесса необходима интеграция систем, что удобно сделать, используя сервисы.
Около года назад сотрудники Gartner уверенно заявили о том, что к 2018 г. преобладающей практикой проектирования и разработки компьютерных программ станет сервис-ориентированная архитектура [3]. Это значит, что уже в обозримом будущем SOA положит конец господствовавшей последние 40 лет архитектуре монолитного программного обеспечения.
Литература
1. Обзор терминологии SOA. http://www.ibm.com/deveLoperworks/ ru/library/ws-soa-term1/ (дата обращения: 19.03.2014)
2. Жизненный цикл сервиса http://www.ibm.com/developerworks/ ru/library/ar-arprac2/ (дата обращения: 18.03.2014)
3. Gartner: рынок облачных сервисов безопасности будет расти. http://www.osp.ru/nets/2013/06/13038566/ (дата обращения: 18.03.2013);
