Метка: EDA

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

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

Почему не все сервисы одинаково полезны

inversionВ программировании известен такой архитектурный паттерн как Inversion Of Control. Суть его в следующем. Традиционно, повторно используемый код оформлялся в виде функций, которые впоследствии вызывались из основной программы. Функции оформлялись в виде статических библиотек, динамических библиотек или вообще в виде сервисов. Приходил программист. Брал функциональные требования, реализовывал бизнес-логику в виде отдельной программы, которая при необходимости вызывала эти самые функции. Inversion Of Control переставляет все с ног на голову. Мы пишем готовую программу, внутри которой реализуем повторно используемый функционал. При этом мы предусматриваемые некоторые точки расширения, в которых вызываются функции, реализующие бизнес-логику. В качестве примера можно привести функцию обработки сообщений главного окна приложения Windows именуемую MainWndProc(). В объектно-ориентированном программировании приложение часто наследуется от некоторого базового класса. Continue reading «Почему не все сервисы одинаково полезны»

Архитектура информационных систем для менеджеров. Миграция или интеграция?

Хочу поделиться с заказчиками(пользователями) информационных систем одним маленьким секретом. Только сразу убедительно прошу, когда вы будете пользоваться этим секретом, пожалуйста, на меня не ссылайтесь. Не хочу лишний раз ссориться с коллегами по цеху. Договорились? Тогда рассказываю.
Continue reading «Архитектура информационных систем для менеджеров. Миграция или интеграция?»

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

Перед отпуском я написал серию сообщений о 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»

Интранет, интеграционная среда или корпоративный портал?

Очень много отзывов собирает tibbr в сообществе Enterprise 2.0. И это при том, что толком его никто пока и не видел. TIBCO предлагает свое решение только крупным клиентам. Описание на сайте более чем лаконично. Никаких trial, демо-версий или вебкастов. В сети я даже внятных скриншотов не обнаружил (что подозрительно похоже на появление Sharepoint 2010 в прошлом году). Тем не менее, обсуждения идут в блогах Gartner и Forrester, CMSWare и ZDNet. Почему такой интерес? Кому TIBCO бросила вызов, на который нельзя не ответить? Попробуем разобраться чуть глубже в том, что есть tibbr
Continue reading «Интранет, интеграционная среда или корпоративный портал?»