Подписаться
Читать в телеграм
К сожалению, в отдельных случаях весь пар поддержки уходит в свисток – большие усилия тратятся на сведение вместе разных концепций и технологий. Например, одно приложение предполагает синхронную обработку запросов, другое — асинхронную. Тогда при интеграции приходится строить промежуточное звено для адаптации протоколов, что увеличивает риск отказа ИТ-системы. Отсутствие единого подхода к транзакционности, безопасности и версионированию удорожает поддержку и развитие ИТ-систем.
С другой стороны, полный цикл обработки данных зачастую оказывается реализован в разных компонентах и полностью не виден.
Большую часть перечисленных проблем можно решить путём перехода на сервис-ориентированную архитектуру (Service-Oriented Architecture, SOA). Вместо монолитных приложений SOA предполагает использование независимых компонентов – сервисов. Чтобы компонент можно было назвать сервисом, к нему предъявляется ряд требований. Во-первых, слабая связность – сервисы должны быть независимыми друг от друга. Во-вторых, абстрактность – в этом случае интерфейс сервиса не зависит от особенностей его реализации. В-третьих, должна быть обеспечена автономность – возможность его работы при отсутствии других сервисов. Еще одно условие – отсутствие внутреннего состояния (Stateless): обеспечение независимости двух последовательных обращений к сервису. Отметим, что мы перечислили основные требования, но далеко не все существующие.
Именно независимые сервисы без внутреннего состояния позволяют разрабатывать сложные процессы обработки данных, а также управлять ими. И здесь в игру вступает интеграционная шина (Enterprise Service Bus, ESB). Ее задача как раз заключается в управлении множеством этих сервисов, реализации композитных сервисов, преобразовании данных, адаптации унаследованных протоколов, обеспечении сквозной авторизации и аутентификации и многом другом. Другими словами, шина являет собой дирижёра в оркестре сервисов. Остается один вопрос – как можно применить указанные нами преимущества решения? Ниже описаны случаи из нашей практики, которые можно назвать типичными.
История первая – о финансовой группе
В финансовой группе, включающей в себя несколько компаний и банков, практически вся разработка велась внутри, in-house. Большое количество систем было написано много лет назад по популярной тогда 2-звенной технологии «клиент–сервер». Постепенно свое применение у разработчиков нашли и Java-технологии, и .Net. В определенный момент количество используемых средств и точек интеграции стало превышать возможности ИТ-команды по их поддержке и развитию.
Отметим, что подавляющее количество интеграций было реализовано по типу «точка–точка». При этом осуществлялась передача файлов по различным протоколам (FTP, HTTP, вручную), запросов по NET8 (SQL) и ответов по ODBC (Open Database Connectivity). Также использовался web-сервис, принимающий в качестве параметра имя хранимой процедуры. Управление им заключалось в регистрации процедуры в таблице.
Основными проблемами, на которые указывали разработчики компании, являлись:
- Отсутствие единого способа получения общей информации или проведения стандартных операций (например, получения списка счетов клиента или перевода средств со счёта на счёт). Каждый раз при возникновении такой задачи она решалась заново – в Java, .Net и т.д.
- Отсутствие единой модели данных. В каждой системе понятие «Счет» было своим, со своим атрибутным составом и связями. Вследствие этого увеличивались затраты на разработку интерфейсов.
- Часто возникали ситуации, когда одна бизнес-операция требовала участия двух и более систем, при этом если в одной из них происходил сбой, остальные про это «не знали», нарушалась консистентность данных.
- Каждая система имела свой список пользователей, самостоятельно авторизовала и аутентифицировала их.
Мы использовали интеграционную шину в нашей компании для создания единого информационного пространства, обеспечивающего целостность и связанность данных между многочисленными корпоративными ИС. Эти информационные системы решают самые разные бизнес-задачи – учет контрактов, сервисных заявок, контроль проектов, трудозатрат, прогнозирование продаж и др. Каждая система использует свои справочники, содержащие общие для всех ключевые бизнес-сущности («Контракты», «Заказчики», «Проекты», «Сотрудники», «Подразделения», «Оборудование» и т.д.).
Основными задачами проекта были синхронизация необходимых данных из всех корпоративных ИС и построение системы управления мастер-данными. Мы использовали интеграционные технологии компании Tibco – одного из лидеров среди производителей ПО для интеграции корпоративных приложений и управления бизнес-процессами. Все ИС были подключены к корпоративной шине данных Tibco Active Matrix BusinessWorks. Шина обеспечивает взаимосвязь между различными ИС по протоколам JDBC, HTTP, SOAP over HTTPJMS, FTP, JMS и работает с основными СУБД – Oracle, MS SQL Server, MySQL, PostgreSQL.
Решение позволяет исключить двойной ввод информации в различные ИС и обеспечивает гарантированное качество данных (при помощи настраиваемых проверок) во всех системах.
Актуальные и непротиворечивые данные, единые для всех корпоративных систем, – это огромные возможности для компании оптимизировать затраты на решение своих бизнес-задач. В конечном итоге это единственный способ получать реальную картину результатов своей деятельности в любой момент времени – с помощью построения аналитической отчетности на основе этих данных. Созданное единое информационное пространство позволяет повысить качество и правильность принятия управленческих решений.
Как применение SOA и интеграционной шины может решить эти проблемы? Первым делом фиксируется модель данных – перечисляются сущности и их атрибутный состав. Определяется их внешнее представление, т.е. XSD-схема. Параллельно с этим выделяются основные, базовые сервисы – кирпичики, из которых строятся более сложные для использования в бизнес-процессах. В системе появляются сервисы «Список счетов клиента», «Перевод средств» и т.д. При необходимости проведения операции в нескольких системах этот процесс осуществляется в шине, где можно реализовать процедуры восстановления после сбоев (откат и повтор операций, уведомление администраторов и др.).
Каждый из создаваемых web-сервисов использует единую БД пользователей и ролей, непосредственно авторизацией и аутентификацией занимается шина.
История вторая – о сетевой компании
Основным бизнесом сетевой компании является транспортировка электроэнергии от поставщиков (электростанций) потребителям – как физическим лицам, так и промышленным предприятиям. Компания обеспечивает электроэнергией один из регионов России, имея по достаточно независимому филиалу в каждом районе и сотни километров линий электропередач. Центральный филиал в столице региона регулирует общую деятельность, управляет складами, координирует ремонтные работы. Одним из главных KPI является объем поставок, на который непосредственно влияет скорость устранения поломок и обрывов. Эта скорость, в свою очередь, зависит от оперативного определения наличия проблемы, диагностики и логистики (доставки материалов для ремонта). Также при транспортировке электроэнергии необходимо учитывать приход и расход.
Набор ПО, установленного в каждом филиале, был примерно одинаковым, однако связь между ними происходила по ненадёжным каналам. Таким образом, основные задачи, которые нужно было решить, – «приблизить» ИТ-системы филиалов к центральному филиалу, реализовать сквозные процессы.
В данном случае хорошо подошла так называемая «федеративная» архитектура шины. В каждом филиале был развернут экземпляр ESB, в котором регистрировались локальные web-сервисы. Все филиальные ESB подключили к ESB центрального офиса. Был реализован новый сквозной процесс для регистрации и обработки аварийных ситуаций, который включал в себя регистрацию аварии, маршрутизацию заявки до центра, обработку специалистами для определения необходимых материалов, направление заявок на ближайший склад и ближайшей бригаде для устранения последствий. Также мы предложили перейти на использование стандартной модели данных, принятой в энергетике (GID (Generic Interface Definition), IEC 61970 Part 4).
Отметим, что внедрение интеграционной шины может быть связано с потребностями не только ИТ-отдела в решении задач интеграции, но и бизнеса в реализации новых бизнес-процессов и решений. В любом случае внедрение потребует доработки сторонних систем, что в то же время быстро окупится.
