Метка: ESB

Уровни зрелости разработчиков интеграционных решений

esbЛет 7-10 тому назад, во времена всеобщего увлечения сервис-ориентированной архитектурой было модно придумывать уровни зрелости SOA сервисов. Open Group придумал Service Integration Maturity Model (OSIMM). IBM отметился свое трактовкой уровней зрелости (см., например Solution design in WebSphere… ), обещающий достигнут пятого из семи возможных уровней зрелости посредством внедрения WebSphere Process Server  (см. рисунок ниже). Ну, а Microsoft c Informatica-ой занимались оценкой уровней зрелости в деле интеграции данных (A Maturity Model for Data Integration) В общем, каждый занимался своим делом. IBM даже порывался сделать у нас консалтинговый проект, но мы сами приписали себе второй или третий уровень зрелости и сразу согласились на пилотный проект с WS Process Server.По результатам пилота мы даже приняли решение внедрить BPEL Engine, правда не от IBM-а, а open source, да и WebSphere Message Broker из эксплуатации вывели (кому нужен инструмент не того уровня зрелости 😉 Continue reading «Уровни зрелости разработчиков интеграционных решений»

Трансформация ИТ: сервисная архитектура и интеграция

47702335-33ad-c494-7ae5-98bbcc7ac027Десять лет прошло с момента публикации аналитиком компании Gartner Ефимом Натисом (Yefim V. Natis) статьи Applied SOA: Conquering IT Complexity Through Software Architecture. Это статья довольно быстро была переведена на русский язык и вышла в журнале «Открытые системы» под заголовком Покорение сложности ИТ. Примерно в это же время в отечественных компаниях начались разговоры про сервис-ориентированную архитектуру,  интеграционные среды, а чуть позже трансформацию ИТ. За прошедшие десять лет мы узнали множество новых слов: облачные вычисления, социальные сети, мобильные приложения и даже большие данные,  но так и не научились контролировать сложность корпоративных информационных систем. Давайте отойдем немного назад и попробуем разобраться почему Continue reading «Трансформация ИТ: сервисная архитектура и интеграция»

Архитектура частного облака

PartlyCloudy1На протяжении нескольких лет тема облачных вычислений (cloud computing) была целиком и полностью спекулятивной. Вероятно, причиной тому являлся приоритет бизнес-модели над технологиям. Технологические лидеры, безусловно, рассказывали широкой общественности о том,  что же такое облако; поясняли, что облака бывают публичные, частные и гибридные, но за всеми этими разговорами отчетливо виднелись длинные уши маркетинга и продаж. И желание у персонажей, которых я назвал «технологическими лидерами» было только одно – вместо лицензий и проектов продавать услуги. Причем не так как раньше, не услуги по разработке программного обеспечения, а услуги, оплачиваемые постоянно, в ходе всего жизненного цикла. На сегодняшний день ситуация поменялась. Покупка услуг по подписке стала привычным делом. Мы стали покупать не только услуги ЖКХ или пакеты услуг связи, но и музыку по 169 рублей в месяц в Apple Music. Вероятно, скоро можно будет подписаться  на месячный пакет еды в близлежащем супермаркете. В общем, тема бизнес-модели стала неактуальной. Пришло время поразбираться в технологиях. Continue reading «Архитектура частного облака»

Зачем организациям Enterprise Service Bus

050833689Я много раз рассказывал о том, что сервисную шину в компании мы использовали не по назначению. Мы не разрабатывали сервисы для того, чтоб предоставлять их внешним приложениям для доступа к данным и операциям других систем, как это описывается в сценариях интеграции приложений. И пусть простят меня команды, которым пришлось использовать эти сервисы: разработчики мобильных приложений, сервисных платформ и т.д. Эти решения делались не для вас. Сервисную шину мы использовали для того, чтоб разрабатывать сервисы для наших клиентов в строгом соответствием с гартнеровским pace layer подходом. Continue reading «Зачем организациям Enterprise Service Bus»

Адаптивный кейс-менеджмент и основные данные

Перед отпуском я написал серию сообщений о SOA, ESB, EDA и Master Data Management. Потом я написал о том, как собрать это все вместе. А по возвращении из отпуска позволил себе добавить в эту конструкцию еще и BPM. Но честно говоря, я еще не сказал главного, о чем мне и напомнил доклад Анатолия Левенчука «Между проектами и процессами: адаптивное управление кейсами». Настоятельно рекомендую его послушать.

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

Continue reading «Адаптивный кейс-менеджмент и основные данные»

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 жив и здоров)

Continue reading «Event-driven architecture»