Метка: 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 из эксплуатации вывели (кому нужен инструмент не того уровня зрелости 😉 Продолжить чтение «Уровни зрелости разработчиков интеграционных решений»

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

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

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

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

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

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

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

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

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

Продолжить чтение «Адаптивный кейс-менеджмент и основные данные»

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

Продолжить чтение «Event-driven architecture»

Forrester: SOA жив и здоров

Примерно таким заголовком анонсировали интернет издания мартовское исследование Forrester SOA Adoption 2010: Still Important, Still Strong Оказывается 71% опрошенных компаний уже используют SOA или собираются это сделать в течении 2011 года. То же самое говорит почти половина средних и малых компаний. Организации довольны результатами, получаемыми от сервис-ориентированной архитектуры и не собираются от неё отказываться. Безусловно, определенная часть опрошенных просто не понимает о чем говорит, но единодушие в ответах респондентов показывает, что «пациент скорее жив, чем мертв».

Не менее интересное исследование появилось в конце апреля The Forrester Wave™: Enterprise Service Bus, Q2 2011. Рынок ESB продолжает неплохо расти. Кроме вполне привычных для ESB задач, таких как маршрутизация сообщений и преобразование данных 35% компаний используют ESB непосредственно для разработки сервисов, а 14% для прикладной разработки на BPEL (28% используют BPEL для оркестровки). Кстати, с языком исполнения бизнес-процессов WS_BPEL ситуация тоже интересная. 2-3 года назад только ленивый не говорил о том, что SOA и BPM – браться на век. Затем из лагеря BPM стали отчетливо слышаться голоса, что BPEL not for people. В ответ могу попрекнуть разработчиков BPMS в монолитности архитектуры их флагманских продуктов. Далеко не все BPMSы, те который для людей, а не так называемый IC-BPMS, отвечают принципам сервис-ориентированной архитектуры, потому как сервисов они не предоставляют. В итоге, у больших вендоров в линейке присутствуют как минимум по два продукта: один для быстрого рисования процессов и пользовательских интерфейсов к ним, а другой для интеграции в корпоративную информационную систему, т.е. интероперабельный. Продолжить чтение «Forrester: SOA жив и здоров»

Услуга интеграции приложений для оператора связи

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

Потребности оператора связи в интеграции приложений можно условно разбить на следующие группы: Продолжить чтение «Услуга интеграции приложений для оператора связи»

Сценарии интеграции приложений. Интранет-портал

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

Таким образом, это сообщение можно назвать Сценарии интеграции приложений(4). Чуть раньше я уже писал о том, что Digital Workplace является зонтичной концепцией, композитным приложением, предоставляющим доступ к функциям других приложений. В полной мере это относится и к данным. Т.е. по сути Digital Worplace, он же новый интранет это способ избавить корпоративный ИТ ландшафт от множества маленьких приложений в стиле база данных плюс окошки, сократить усилия за счет повторного использования однажды разработанных компонент. Если этого своевременно не сделать, то мы довольно быстро получим сложнейшие интеграционные задачи, описанные в заметке Сценарии интеграции приложений(2) Это идеальный вариант. Сервис-ориентированная архитектура (SOA), как её видели стратеги десяток лет назад


Как и все благие намерения SOA разбилась о рифы реальности. И главное причина тому интероперабили (interoperability) унаследованных приложений, вернее её отсутствие. Большинство приложений делалось для людей, а не для интеграции. Для людей(пользователей) в прямом смысле, т.е. каждый из разработчиков считал, что с его приложением будет работать человек, а не другая информационная система. Интеграция приложений – это уже набор конкретных практик, возникших из желания обеспечить согласованную работу множества систем, по возможности, не напрягая при этом пользователей. Именно поэтому корпоративный интранет портал или, если угодно, digital workplace является основным элементом интеграции приложений, не менее важным, чем Enterprise service bus, ETL или же очереди сообщений.