Я много раз рассказывал о том, что сервисную шину в компании мы использовали не по назначению. Мы не разрабатывали сервисы для того, чтоб предоставлять их внешним приложениям для доступа к данным и операциям других систем, как это описывается в сценариях интеграции приложений. И пусть простят меня команды, которым пришлось использовать эти сервисы: разработчики мобильных приложений, сервисных платформ и т.д. Эти решения делались не для вас. Сервисную шину мы использовали для того, чтоб разрабатывать сервисы для наших клиентов в строгом соответствием с гартнеровским pace layer подходом. Читать далее Зачем организациям Enterprise Service Bus
Метка: EDA
Почему не все сервисы одинаково полезны
В программировании известен такой архитектурный паттерн как Inversion Of Control. Суть его в следующем. Традиционно, повторно используемый код оформлялся в виде функций, которые впоследствии вызывались из основной программы. Функции оформлялись в виде статических библиотек, динамических библиотек или вообще в виде сервисов. Приходил программист. Брал функциональные требования, реализовывал бизнес-логику в виде отдельной программы, которая при необходимости вызывала эти самые функции. Inversion Of Control переставляет все с ног на голову. Мы пишем готовую программу, внутри которой реализуем повторно используемый функционал. При этом мы предусматриваемые некоторые точки расширения, в которых вызываются функции, реализующие бизнес-логику. В качестве примера можно привести функцию обработки сообщений главного окна приложения Windows именуемую MainWndProc(). В объектно-ориентированном программировании приложение часто наследуется от некоторого базового класса. Читать далее Почему не все сервисы одинаково полезны
Архитектура информационных систем для менеджеров. Миграция или интеграция?
Хочу поделиться с заказчиками(пользователями) информационных систем одним маленьким секретом. Только сразу убедительно прошу, когда вы будете пользоваться этим секретом, пожалуйста, на меня не ссылайтесь. Не хочу лишний раз ссориться с коллегами по цеху. Договорились? Тогда рассказываю.
Читать далее Архитектура информационных систем для менеджеров. Миграция или интеграция?
Адаптивный кейс-менеджмент и основные данные
Перед отпуском я написал серию сообщений о SOA, ESB, EDA и Master Data Management. Потом я написал о том, как собрать это все вместе. А по возвращении из отпуска позволил себе добавить в эту конструкцию еще и BPM. Но честно говоря, я еще не сказал главного, о чем мне и напомнил доклад Анатолия Левенчука «Между проектами и процессами: адаптивное управление кейсами». Настоятельно рекомендую его послушать.
Прежде чем перейти к главному, я все же соберу ссылки на все упомянутые выше сообщения:
- 10.07.2011 Event-driven architecture. Размышления о том, является ли SOA архитектурой и нужна ли для её построения ESB.
- 17.07.2011 Как сделать хороший API? О необходимости абстрагирования для построения повторно-используемых программных интерфейсов
- 12.08.2011 Интерес к управлению данными возвращается.
- 15.08.2011 Master Data Management, EDA, ESB, SOA: собираем все вместе. О том, что для управления основными данными нужна и сервисная шина и управляемая событиями архитектура.
- 17.09.2011 … добавляем бизнес-процессы. Несколько рассуждений о BPM и MDM вместо сочинения о на тему «как я провел лето»
Master Data Management, EDA, ESB, SOA: собираем все вместе
Реализация повторно используемых интерфейсов предполагает, что мы будем хотя бы чуть-чуть абстрагироваться от конкретных задач и требований сегодняшнего дня. Иначе интерфейсы нам придется переделывать постоянно. Повторю пример из комментариев к сообщению Как сделать хороший API? При разработке программного интерфейса к каталогу книг методы
getBookAuthor(…) и getBookPublisher(…)
выглядят вполне уместно. Однако проходит время и заказчик понимает, что первоначально придуманных свойств недостаточно. Появляются требования по получению новых параметров, например ISDN. В какой-то момент разработчику это надоедает, и он разрабатывает функцию
getBookProperty(authorID,…)
Выглядит уже лучше. Правда затем в ассортименте виртуального магазина к книгам могут добавиться компакт-диски и другие товары, у которых и автора нет и ISDN, зато есть другие свойства. В результате неизбежного рефакторинга книжки должны превратиться а item-ы, а исходная функция в
getItemProperty(itemID, propertyID,…)
Преимущества такого подхода достаточно очевидны. Впрочем, в дополнение к преимуществам появляются и определенные сложности. Одна из них состоит в необходимости разработки дополнительных функций для получения списка item-ов и списка их свойств. Причем перечни свойств элементов различных типов может не совпадать. Описание структуры данных принято выносить в мета-данные (meta-data management). Т.е. у нас должен появиться справочник, в который мы будем вносить эти данные и программные интерфейсы для чтения этих справочников из приложений. Вот мы и добрались до управления основными данными (master data management, нормативно-справочная информация) о котором говорили в сообщении Интерес к управлению данными возвращается Это станет особенно актуальным если информацию получать мы будем из нескольких разнородных приложений с различными программными интерфейсами. Кстати именно в этом случае нам понадобится ESB и управляемая событиями архитектура (Even-driven architecture) Может показаться, что я противоречу своим более ранним сообщениям. Однако, если разобраться чуть глубже, то станет понятно почему это не так (см. рисунок)
В каждом из унаследованных приложений свои структуры данных и свои программные интерфейсы (в одном книжки, в другом компакт-диски ). В каждом, в лучшем случае, свои справочники свойств или же тривиальный хардкод, что встречается чаще. Первое что нужно сделать – научить приложения уведомлять MDM-систему обо всех изменениях в справочниках (Event Driven стиль). В крайнем случае, можно наладить ETL процесс, который будет регулярно сканировать базу данных на предмет выявления изменений и отражать их в MDM. Для того чтоб получить перечень свойств книг или перечень свойств компакт-дисков, очевидно, не следует вызывать API унаследованных приложений, а следует обратиться к MDM системе. (Подробнее см. Gregor Hohp Programming Without a Call Stack – Event-driven Architectures) И в завершении картинки у нас появляется сервисная шина предприятия (ESB), которая берет на себя функции преобразования запросов из getItemProperty() в реализованный унаследованным приложением getBookAuthor(), а так же маршрутизации запросов между приложениям. Кроме того, ESB окажется полезным и при чтении MDM, например, для сокрытия задержек обновления данных в MDM, кеширования запросов и т.д. Сам процесс обновления данных в MDM системе можно и даже нужно реализовать в ESB, т.к. это позволит нам реализовать достаточно эффективные стратегии управления данными. Не стану углубляться в подробности, т.к. описание данных стратегий потребует некоторого погружения в описание архитектуры Web. Интересующихся отсылаю к диссертации изобретателя стиля RESTful Роя Филдинга (краткое введение в тему RESTful и Enterprise 2.0)
Event-driven architecture
В 2006 году Gartner закрыл аналитическую группу, которая занималась управляемой событиями архитектурой (Event-driven architecture, EDA). Термин EDA предложил аналитик Gartner Roy W. Schulte тремя годами раньше в работе The Growing Role of Events in Enterprise Applications Обзор работы на русском языке можно посмотреть в статье EDA — архитектура, управляемая событиями До какого-то момента SOA и EDA в сознании аналитиков шли рука о руку (см., например 2.0 The Mission and Future of Integration), но потом управляемая событиями архитектура впала в немилость и была забыта. Может быть, концепция была слишком революционной, а может идея Complex event processing (CEP) отвлекла на себя основной внимание, но из-за задержки внедрения таких технологий как RFID ушла в тень, прихватив с собой и EDA, не важно. Для нас важно другое:
- во-первых, в отличии от SOA, EDA – это действительно архитектура, т.е. определенный подход к построению информационной системы предприятия;
- во-вторых, концепция управляемой событиями архитектуры объясняет, почему сегодня интерес к сервисной шине предприятия (ESB) опережает интерес к SOA (см. ссылки в сообщении Forrester: SOA жив и здоров)
Интранет, интеграционная среда или корпоративный портал?
Очень много отзывов собирает tibbr в сообществе Enterprise 2.0. И это при том, что толком его никто пока и не видел. TIBCO предлагает свое решение только крупным клиентам. Описание на сайте более чем лаконично. Никаких trial, демо-версий или вебкастов. В сети я даже внятных скриншотов не обнаружил (что подозрительно похоже на появление Sharepoint 2010 в прошлом году). Тем не менее, обсуждения идут в блогах Gartner и Forrester, CMSWare и ZDNet. Почему такой интерес? Кому TIBCO бросила вызов, на который нельзя не ответить? Попробуем разобраться чуть глубже в том, что есть tibbr
Читать далее Интранет, интеграционная среда или корпоративный портал?
Приложение управления бизнес-приложениями
Чтобы понять рекурсию нужно понять рекурсию
Много слов сказано для обоснования полезности промежуточного ПО, интеграционных сред, систем управления бизнес-процессами. И количество «оппортунистических» связей между приложениями они сокращают, и интеграционные решения унифицируют и сквозные бизнес-процессы, включающие несколько приложений, реализуют. Всё это, безусловно, важно. Но не это главное.
Уже не один год существует класс информационных систем называемый application management. Эти системы позволяют удаленно развертывать и конфигурировать приложения, мониторить состояние системы, диагностировать ошибки, управлять квотами и т.д. Развитие облачных вычислений (cloud computing) дало дополнительный импульс application management. Насколько мне известно, в Windows Azure при наступлении определенных событий, например превышении загрузки процессора выше определенной черты или увеличении количества входящих сетевых запросов, можно автоматически поднять еще одну виртуальную машину и развернуть на ней дополнительный экземпляр приложения.
Не трудно провести аналогию между системами application management и интеграционными средами и BPMS. Только вторые управляют содержательной частью бизнес-приложений. Обычно, с бизнес-приложениями работают люди. Но по мере роста и развития информационной системы предприятия все чаще возникает необходимость заменить этих людей автоматизированными системами. Сценарии таких ситуаций следующие:
- Управление вводом данных. Когда возникает необходимость за ограниченный промежуток времени ввести в систему несколько десятков тысяч записей, люди становятся бессильны. До определенной степени можно расширять штат низкооплачиваемых сотрудников, занимающихся вводом, но это довольно затратный подход. Намного проще: загрузить данные подготовленные внешним приложением, например, переложить задачу ввода каких-либо запросов на партнеров и клиентов (системы self-service). Другой пример управления вводом данных – автоматическое добавление записей по событию. Многие сервисные службы создают инциденты не только по запросам пользователей, но и на основании событий систем мониторинга. (Подробнее об обработки событий см. ниже)
- Управление справочниками. Большинство бизнес-приложений используют справочники. Когда в различных системах ведутся разные справочники одних и тех же объектов, задача управления этими системами становится крайне сложной. Как только количество используемых систем превысит десяток – время задуматься о централизованном ведении справочников, а задачу управления справочниками возложить на интеграционную среду.
- Управление рабочими процессами (workflow). Сейчас трудно найти систему, внутри которой не было бы функций workflow. Однако такие workflow начинаются и заканчиваются «внутри» системы. Разделение труда между подразделениями предприятия, возможно и повышает его производительность, но в качестве цены за это формирует высоченные барьеры между подразделениями. В то же время, бизнес-процессы любого предприятия являются общими. Иногда в процессе участвуют не только подразделения одной компании, но и подразделения компаний-партнеров. Рабочии процессы – это единая сеть, требующая координации и согласованной работы. Идея бизнес-сервиса, как рабочего процесса, управляемого информационной системой была изложена мной в сообщении Программный интерфейс к бизнесу
- Обработка событий. На фоне всеобщего увлечения сервис-ориентированной архитектурой (SOA), управляемая событиями архитектура (even-driven architecture, EDA) осталась практически незамеченной. Однако, построение адаптивной информационной системы компании требует именно такого подхода. SOA сервисы интересны только в той степени, в которой они помогают компании реагировать на те или иные бизнес-события. Можно написать сотню сервисов, ни одним из которых никто и никогда не воспользуется. Событийный подход вносит смысл в информационную систему компании. Заставляет нас задумываться над вопросом «зачем», для каких случаев, мы разрабатываем тот или иной сервис. Перехват и маршрутизация событий, пожалуй, наиболее значимая ценность, привносимая интеграционными средами в корпоративный ИТ-ландшафт.
- Обработка исключений. Однако не все события поддаются автоматической обработке. Рано или поздно возникает ситуация не предусмотренная ни в требованиях к решению, ни в спецификации взаимодействий, ни в техническом задании. Огромная ошибка заключается в том, чтоб рассматривать такую ситуацию как ошибку, записать сообщение в системный лог и остановить бизнес-процесс. С каждой такой ситуацией должен кто-то разбираться. Появившиеся ошибки это та самая обратная связь от эксплуатации к развитию, помогающая своевременно корректировать бизнес-процессы и модернизировать приложения. Вопреки распространенному мнению интеграционная среда не является «системой без пользователей». Наоборот, это система для наиболее подготовленных и эрудированных пользователей, способных анализировать исключительные ситуации как с точки зрения ИТ, так и с точки зрения бизнеса и своевременно принимать адекватные решения.
Я надеюсь, что некоторые из изложенных мною соображений, расширят арсенал аргументов в пользу использования интеграционных сред в ИТ-инфраструктуре компаний. Комментарии и дополнения, как всегда, приветствуются.