О построении сервисно-ориентированной архитектуры на предприятии

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

Для решения данной задачи нужно обеспечить исполнение следующих условий:

1. Переход от интеграции по принципу точка-точка к интеграции через сервисную шину предприятия (ESB).

2. Обеспечение независимости интеграции от форматов передаваемых сообщений.

3. Документирование в достаточном объеме и качестве.

4. Наличие мониторинга процесса передачи и обработки сообщений.

Переход к интеграции через сервисную шину предприятия - ESB

Интеграция систем по принципу "точка-точка" обладает одним существенным недостатком - низкой масштабируемостью. Количество возможных связей между системами можно вычислить с помощью формулы N(N-1)/2. Если интегрируется три системы, то и количество связей между ними тоже равно трем. В таком случае интеграция по принципу точка-точка оправдана. Если же систем 10, то количество связей равно 45-ти, а это - уже довольно значительная величина.

Проблема здесь не только в том, что связей много и в них можно запутаться, а в том, что их все нужно обеспечивать как на уровне протокола обмена (одна система-приемник может использовать в качестве протокола обмена - HTTP, другая - RMI, третья - JMS, а N-я - Oracle AQ, в то время как система-источник вообще изначально кроме как положить сообщение в табличку БД ничего не умеет), так и на уровне формата данных (одна система-приемник ожидает файл обмена 1С в виде XML, другая - IDOC, третья - некий свой кастомный XML, а N-я - SOAP-сообщение). Обеспечивать поддержку различных протоколов обмена и форматов данных в случае интеграции по принципу точка-точка должны сами бизнес-приложения, что обычно дорого, а иногда в принципе невозможно.

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

Обеспечение независимости интеграции от форматов передаваемых сообщений

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

Часто в литературе, посвященной ESB, можно встретить такой термин, как "канонический формат". Обычно под данным термином понимается максимально обобщенный формат сообщений, позволяющий передавать сообщения из каждой системы в каждую независимо от формата, в котором сообщение пришло в шину и формата сообщения для системы-получателя. Разработка как самого канонического формата, так и трансформаций из/в него является довольно трудоемким занятием, поэтому желание сэкономить на данных работах вполне понятно. Когда это можно сделать?

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

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

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

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

Документирование в достаточном объеме и качестве

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

Чтобы избежать нивелирования использования внедренного решения нужно помимо технических средств (использования различных реестров и репозиториев) обеспечить и ряд организационных мер, таких как обязательное и качественное документирование состояния ландшафта. В документации должна быть отражена полная информация по всем типам сервисов (утилитным, сервисам приложений, бизнес-сервисам и сервисам процессов):
- Наименование сервиса;
- Стиль интеграции (пакетный, реального времени);
- Стиль вызовов - как обеспечивается вызов сервиса/приложения (по триггеру, с использованием Change Data Capture и т.д.);
- Шаблон обмена сообщениями (Request-Reply, One-Way, Pub-Sub);
- Бизнес-домен сообщений;
- Формат сообщений (XML, CSV, SOAP, IDOC и т.д.);
- Протокол обмена (HTTP, MQ, RMI и т.д.);
- Контракт сервиса (WSDL, WADL и т.д.);
- Безопасность (аутентификация, авторизация, шифрование, неотрекаемость);
- Уровень реализации безопасности (на уровне канала связи, на уровне сообщения);
- Реализация безопасности (WS-Security, SSL и т.д.).

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

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

Наличие мониторинга процесса передачи и обработки сообщений

Еще одним из преимуществ внедрения сервисно-ориентированной архитектуры, например, в виде ESB, является обеспечение сквозного мониторинга процесса передачи и обработки сообщений. Сквозной мониторинг позволяет решить следующие задачи:
- обеспечение SLA;
- получение и анализ статистики использования сервисов;
- контроль за прохождением каждого сообщения по шине;
- контроль за обработкой сообщений в бизнес-системах.

Обеспечение SLA

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

Получение и анализ статистики использования сервисов

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

Контроль за прохождением каждого сообщения по шине

Данный контроль необходим прежде всего с целью поиска потерявшихся сообщений, а так же для поиска ответа на вопрос: почему в бизнес-системах А и Б оказались несогласованные данные. Передача сообщений по интеграционной шине происходит в несколько этапов, например: регистрация, маршрутизация, доставка. Если в связи с изменившимися потребностями бизнеса производится адаптация шины, то как правило эта адаптация происходит по принципу "нужно, чтобы было сделано еще вчера!". При работе в такой обстановке вполне возможно что-то забыть или сделать неверно. В частности неправильно настроить маршрутизацию, что приведет к застреванию сообщений в шине. Чтобы идентифицировать данные проблемы и адекватно их исправлять необходимо средство мониторинга за прохождением каждого сообщения по шине. Отчет о прохождении сообщений по шине должен содержать как минимум следующую информацию:
- Идентификатор сообщения в системе-источнике;
- Тип сообщения;
- Система-источник;
- Система-приемник;
- Идентификатор сообщения в системе-приемнике (если есть);
- Состояние сообщения (на какой фазе находится, передано или нет в систему-получатель, обработано ли);
- Информация об ошибке (в случае, если при передаче или обработке сообщения произошла ошибка).

Контроль за обработкой сообщений в бизнес-системах

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

Здесь возможны два варианта в зависимости от типа обмена:
- Синхронный обмен. Т.к. обмен синхронный, т.е. сообщение обрабатывается сразу же после доставки в систему-получатель и формируется результат, то дополнительных уведомлений шины не требуется. Шина, получив результат, должна фиксировать у себя соответствующий статус обработки сообщения.

- Асинхронный обмен. В данном случае возможно, что результат обработки сообщения не формируется вообще (т.н. One-Way обмен). В то же время, как было сказано выше, требуется уведомить шину о результатах обработки сообщения. Для этого необходимо обеспечить еще один канал связи между бизнес-системой и шиной, по которому будут ходить уведомления: сообщение обработано успешно или сообщение обработано неуспешно. В случае возникновения ошибки при обработке сообщения необходимо передать текст и код данной ошибки.

Предлагаю в комментариях высказывать свои взгляды на интеграцию приложений, внедрении SOA/ESB или задавать вопросы. Спасибо за внимание.

З.Ы. Оставлю за собой право вносить изменения в данную статью с целью повышения информативности и логичности изложения.

Понравилось сообщение - подпишитесь на блог