То, что в системах управления технологическими процессами или в классических «АСУшных» задачах, подобных управлению движением поездов или самолетов, резервированию билетов и т.д., является очевидным, в информационных системах для бизнеса стало откровением. Как ни парадоксально, понадобилось накопить полувековой опыт, чтобы признать необходимость работы в режиме реального времени и обработки входного потока событий. Появление EDA стало первым шагом к нормализации этой странной ситуации.

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

Однако комплект деталей для сборки постоянно расширяется. С появлением средств моделирования бизнес-процессов (business process modeling, BPM) и введением в оборот архитектуры, управляемой событиями (event driven architecture, EDA), он наконец приобретает черты завершенности. Подходы, реализованные в BPM и EDA, вводят естественный порядок. Они позволяют сначала построить модель, а затем объединить отдельные фрагменты в единую систему, адаптированную к условиям внешней среды.

Однако ни моделирование, ни способность реагировать на внешние возмущения не являются чем-то принципиально новым — в отличие от приложения этих подходов к ИТ-системам управления бизнесом. При проектировании других систем управления моделирование применяется уже много десятилетий, и можно найти множество примеров компьютерных систем, отрабатывающих входной поток и управляемых им:

  • конвейеры, позволяющие на одном производстве собирать разные модели; входным потоком событий являются заказы на требуемые детали;
  • управление сетевыми конфигурациями; в данном случае входной поток — события в сети;
  • система продажи авиационных билетов, способная адаптироваться к специфическим требованиям каждого покупателя;
  • системы управления технологическими процессами, в которых входной поток событий формируется датчиками, расположенными на объекте управления;
  • системы управления фондовыми биржами, где событиями являются сделки;
  • операционные системы компьютеров, которые способны обрабатывать запросы на прерывания, поступающие от периферийных устройств.

Любое предприятие существует в реальном мире, наполненном событиями. Оно не может не отрабатывать входной поток событий из окружающего мира, но даже при наличии самых развитых информационных систем это происходит неявно, в основном на уровне управленческого персонала. (Корпоративные информационные системы потому и не включены в приведенный выше перечень, что на них пока возлагается весьма ограниченная часть функций, а все остальное выполняет управленческий персонал.) Так вот, реализация идей EDA знаменует собой начало миграции функций обработки событий от людей к автоматизированным системам.

Этой тенденции уделяют большое внимание в аналитической компании Gartner. Эксперты компании полагают, что в ближайшее время EDA окажется в центре внимания ИТ-отрасли*. Кроме того, идеи EDA позволят лучше осознать, что такое архитектура, ориентированная на сервис (service oriented architecture, SOA). Совместно SOA и EDA позволят сформировать подходы к предприятию, управляемому в режиме реального времени.

Меморандум Шульте

Термин EDA предложил Рой Шульте, аналитик компании Gartner, в опубликованном 9 июля 2003 года отчете с длинным названием «Повышение значимости событий для интеграции приложений. В будущем приложения станут в большей степени управляться событиями, чем современные. Пять движущих сил». Этот документ неожиданно быстро оказался в списке наиболее цитируемых работ по интеграции приложений, а его автор приобрел широкую известность среди специалистов.

Шульте утверждает, что бизнес начнет использовать EDA в период с 2004-го по 2008 год, поскольку существующие технологии интеграции приложений, практически игнорирующие события, перестают соответствовать требованиям бизнеса. Отныне и впредь будут востребованы иные подходы к интеграции, учитывающие поток событий во внешней среде. Это мнение подкрепляется существованием множества практических предпосылок для создания «новых приложений» и «новой интеграции». Иными словами, EDA — не изобретение колеса: многое уже готово, но многое еще предстоит сделать.

В отчете формулируется пять основных тезисов, определяющих особенности будущего внедрения EDA. С интересными рассуждениями Шульте можно согласиться практически во всем, за исключением слишком вольной интерпретации самого термина «архитектура». Стоило бы вести речь о системах, способных реагировать на события, о системах, реализующих событийные бизнес-процессы. Подобные системы могут быть построены на самых разных архитектурных принципах, в том числе еще неизвестных; пример тому — живые организмы.

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

Бизнес-процессы, подчиненные событиям, — это не просто ускорение или улучшение существующих процессов; такие процессы принципиально отличаются от «обычного бизнеса». Важно то, что они органично воспринимаются практикующими менеджерами и аналитиками. По сути, эти процессы совпадают с их естественным мировосприятием, в котором поведение лица, принимающего решение, исключительно подчинено необходимости реагировать на происходящее. Одно из немаловажных преимуществ заключается в том, что появляется возможность оперативно исправлять ошибки, вполне возможные в человеческой деятельности, но способные нарушить традиционные процессы.

II. SOA — промежуточный этап на пути к EDA. Активная миграция в направлении архитектур, ориентированных на сервисы, позволяет проложить путь к адаптации событийных приложений и интеграции, поскольку они реализуются на основе распределенных слабосвязанных компонентов, которые характерны для SOA (можно указать, в частности, на такие свойства, как модульность, инкапсуляция, документированный интерфейс). Однако Шульте считает, что SOA в большей степени привязана к клиент-серверной архитектуре, а потому SOA и EDA хотя и родственные, взаимодополняющие явления, но не разные уровни одной иерархии.

III. Индустрия готова к поддержке EDA. Многие производители уже поставляют или готовятся к поставке необходимых программного обеспечения промежуточного слоя и средств разработки, адаптированных к особенностям новой архитектуры.

  • Для наиболее простых приложений вполне подходит существующее программное обеспечение промежуточного слоя, ориентированное на обмен сообщениями и на Web-сервисы. Могут быть использованы известные серверы приложений на основе J2EE, но, скорее всего, дальнейшее совершенствование серверов будет нацелено на их большую адаптацию к обработке событий.
  • Более сложные «событийные» приложения, которые используют контентно-зависимую маршрутизацию сведений о событиях и средства управления бизнес-процессами, могут быть реализованы специализированными интеграционными брокерами. Такие инструменты появятся не раньше 2006 года.
  • Самые сложные формы событийных приложений потребуют использования методов обработки сложных событий (complex event processing, CEP). Основным теоретиком этого направления является Дэвид Лукхэм, статью о работах которого можно найти в разделе «Экстремальные технологии» этого выпуска журнала. Кроме того, сейчас такой деятельностью занимаются нескольких компаний-«стартапов».

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

IV. Процесс стандартизации уже начинается. Обще?принятых стандартов для EDA пока не существует, но есть надежда, что они появятся в течение нескольких лет. «Ледоколом» эффективной стандартизации в этой сфере может служить достигший зрелости процесс стандартизации SOA. Хотя общее представление об архитектуре SOA и ее преимуществах теоретически было получено еще в начале 90-х годов, потребовалось почти десять лет (в том числе около пяти лет — на выработку стандартов для Web-сервисов), чтобы она обрела зримые черты. Есть основания полагать, что признаваемые большинством производителей стандарты на схемы обмена сообщениями в CEP, как и языки описания событий (event-processing language, EPL) могут появиться уже в 2007 году.

V. Формируются новые требования к аппаратному обеспечению. Необходимость обработки событий окажет существенное воздействие прежде всего на создание сетевого оборудования. Оно должно обеспечить передачу больших объемов информации с меньшей задержкой и большей надежностью.

Следующая Большая Вещь

Год спустя после появления отчета Роя Шульте компания Gartner опубликовала документ, озаглавленный «Миссия и будущее интеграции, версия 2» (2.0 The Mission and Future of Integration). В нем событийный подход к проектированию систем назван «следующей большой вещью», только теперь речь идет об архитектуре бизнеса, а не о системной архитектуре, как следовало из отчета Шульте.

Рис. 2. Обмен сообщениями между провайдером и потребителем

Показателен следующий пассаж, с которого начинается новый отчет: «События дополнят, но не заменят сервисы в архитектуре, ориентированной на сервисы». Можно признать «Миссию» одной из самых интересных работ, в которых осмысливается роль технологий, предназначенных для интеграции приложений. Хотелось бы порекомендовать ее для прочтения тем, кому небезынтересны системные взгляды на корпоративные информационные системы (regionals4.gartner.com/regionalization/ img/gpress/pdf/gartner_exec_report_sample_WEB.pdf).

В этой работе Gartner содержится ответ на ряд ключевых вопросов. Прежде всего, обсуждается, какое влияние окажут SOA и EDA на интеграцию приложений и какие изменения привнесут SOA и EDA в практику проектирования средств интеграции приложений. Предпосылкой к возникновению этих вопросов служит изменившаяся роль интеграции приложений. Надо признать, интеграция приложений в единую систему еще не стала основной задачей разработчиков систем. Так, В 1998 году интеграция стимулировалась прежде всего необходимостью внедрения систем планирования ресурсов предприятия, в 2000-м — модой на системы управления отношениями с клиентами, наконец, в 2004-м — усилившимися в Соединенных Штатах требованиями к контролю над деятельностью предприятий.

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

  • стратегия интеграции приложений;
  • соответствующая команда или даже центр компетенции;
  • соответствующая программная инфраструктура промежуточного слоя.

Все это вместе позволит собрать в единый механизм отдельно взятые приложения. Это одна из сложнейших задач, с которыми когда-либо приходилось сталкиваться ИТ-департаментам предприятий. Практически все решения, унаследованные к сегодняшнему дню, построены на основе представления, что отдельные компоненты, данные и процессы не связаны между собой, причем построены с использованием различных средств, включая операционные системы, языки программирования, платформы для приложений, СУБД.

Существуют три основных подхода к интеграции приложений, два из которых вполне тривиальны. Первый базируется на простом согласовании данных (data consistency). Второй является более сложным, многоступенчатым процессом (multistep process) и основан на согласованной технологической цепочке, состоящей из связанных между собой операций. Оба подхода имеют право на существование, но лишь третий, названный композитными приложениями (composite applications), действительно позволяет создавать системы, управляемые событиями. При его использовании независимые приложения кооперируются для выполнения одного бизнес-процесса. Композитные приложения можно рассматривать как развитие многоступенчатого процесса, интегрирующего несколько уровней цепочек.

Для получения композитных приложений необходимо объединить унаследованные и приобретаемые вновь приложения путем создания специализированных кодов. Они могут быть написаны на языках третьего или четвертого поколения, а также сгенерированы с использованием средств моделирования. Создается система, состоящая из существующих приложений, которые занимают отведенные им места. В некоторых случаях может применяться «движок» microflow BPM engine, представляющий собой уменьшенную версию механизма управления бизнес-процессами (business process management, BPM) и позволяющий «оркестровать» диалог между композитными приложениями. (Подобный «движок» отличается от традиционного, «долго живущего» BPM тем, что активизируется лишь на несколько секунд.)

Рис. 5. Доставка с гарантией

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

По мнению авторов отчета, в качестве языка кодирования интерфейсов SOA будет использоваться XML, для документирования интерфейсов — язык Web Services Description Language (WSDL), а для организации процедуры обмена сообщениями — протокол Simple Object Access Protocol (SOAP). Признавая эти средства преобладающими, авторы «Миссии» все же считают необходимым отметить, что SOA не является универсальным «лекарством». Остаются ниши и для процессов, использующих простое согласование данных, и для многошаговых процессов.

В подходах SOA и EDA много общего, поскольку они представляют собой способы комбинации разнообразных программных компонентов в большие распределенные приложения. Однако есть существенное структурное различие. SOA — это двунаправленная коммуникация типа «запрос-ответ», делегирующая работу подчиненным процедурам, а в EDA используется однонаправленный обмен сообщениями. Соответственно, EDA является дополнением, а не заменой SOA. Состояние зрелости SOA и EDA может быть представлено на традиционной для Gartner кривой фаз адаптации технологий, часто называемой «кривой хайпа».

В качестве основной технологии при практической реализации SOA и EDA, скорее всего, будет использоваться корпоративная сервисная шина (enterprise service bus, ESB). О том, что это действительно так, можно судить по вниманию компаний IBM и Microsoft к данной группе технологий, включающей в себя серверы приложений и инструментальные платформы для приложений. Аналитики Gartner предсказывают, что в 2006 году IBM выведет на рынок продукт WebSphere ESB; со своей стороны, Microsoft включит соответствующую технологию Indigo в состав Longhorn, следующего поколения операционных систем Windows в 2006-м или в 2007 году.

События и сервисы — две стороны медали

Появление EDA ввергло в замешательство многих на фоне еще не вполне пережитого шока, вызванного распространением идей SOA. За последние годы у ИТ-общественности сформировался устойчивый иммунитет к прогнозам аналитиков, а потому негативная реакция на их очередное «открытие» выглядит вполне закономерной. В свою очередь, реакцией на этот негатив стала статья ведущего специалиста аналитической компании ZapThink Джейсона Блумберга, озаглавленная «SOA + EDA = FUD?», которая распространилась по Сети во множестве копий. Блумберг задается вопросом, не является ли ажиотаж, разворачивающийся вокруг EDA, продолжением шумихи, связанной с SOA, и дает на него отрицательный ответ.

Часто SOA и EDA различают по трем параметрам — по связанности приложений, режиму обмена сообщениями между ними и уровню синхронизации приложений.

Перечислим свойства, характерные для SOA.

  • Слабая связанность. SOA позволяет разработчикам, провайдерам и потребителям сервисов взаимодействовать вне зависимости от использованных ими технических решений и с минимальным знанием друг о друге — достаточно умения идентифицировать и использовать необходимый сервис.
  • Обмен сообщениями в режиме «запрос-ответ». SOA предполагает, что потребитель запрашивает получение некоторых данных или некоторой функциональности, а провайдер сервиса отвечает ему, реализуя этот запрос.
  • Синхронность. SOA поддерживает синхронный режим сервиса, то есть при отработке запроса обе стороны находятся в режиме взаимодействия.

EDA, в первом приближении, отличается по этим показателям иными характеристиками.

  • Отсутствие связи. В EDA публикатор сообщения не знает, кто является подписчиком, и наоборот. Взаимодействие ограничивается обменом данными, и между отдельными подсистемами не устанавливается каких-либо тесных отношений.
  • Обмен сообщениями в режиме «публикация-подписка». EDA поддерживает отношения «многих со многими», то есть публикатор делает сообщение известным всем входящим в сеть, а те, кто подписаны на сообщения или авторизованы, могут их получать.
  • Асинхронность. EDA поддерживает режим, в котором сообщение посылается без ожидания немедленной реакции на него.

Из перечисленных несовпадений делается вывод, что перед нами — два совершенно разных явления. Но так ли это? Не ошибочна ли такая простая дихотомия? Чтобы лучше разобраться в том, что общего между EDA и SOA и чем они различаются, вернемся к основополагающим вещам — событиям, сервисам и архитектуре.

  • События. Простым событием называют происходящее в реальном мире изменение состояния окружающей среды. В бизнесе простым событием может быть изменение состояния предприятия или окружающей его среды, заказ товара, поставка, поступление платежа. Простое событие в программном обеспечении — это запись о простом событии. Сложным событием является связка из двух и более простых событий.
  • Сервисы. Обычно под сервисами понимают представление функциональности программного обеспечения в виде интерфейсов, обеспечивающих прием и передачу сообщений.
  • Архитектура. Согласно стандарту IEEE P1471/D5.3, архитектура программного обеспечения является основополагающим руководством для построения какой-либо системы, реализованным в виде ее компонентов, их отношений между собой и с внешней средой, а также принципов проектирования и эволюции системы.

События, сервисы и архитектура образуют единое целое. События — это форма проявления жизни, они происходят в реальном мире. Сервисы — один из возможных способов (если не единственный) установления взаимодействия между компонентами сложных систем. Наконец, архитектура определяет, как такие системы строятся.

С появлением Web-сервисов, а потом и SOA возникло понимание того, что компоненты систем могут быть слабо связанными. Из этого был сделан однозначный вывод: слабая связанность является обязательным признаком сервисной архитектуры. Но, рассмотрев примеры систем в окружающей среде, мы увидим, что связанность компонентов и ориентация на сервисы представляют собой независимые характеристики. Системы могут быть жестко, слабо или совсем не связанными, но одновременно с этим ориентированными или не ориентированными на сервисы. Кроме того, они могут управляться или не управляться событиями.

SOA и EDA представляют собой первые попытки построить архитектуры, хоть в какой-то мере соответствующие многообразию окружающего мира. В каждом из этих архитектурных подходов воплощен фрагмент такого многообразия.

SOA как основа EDA

В отчете компании ZapThink, озаглавленном Events vs. Services: the real story, best practices in event-driven SOA и датированным октябрем 2004 года, рассмотрены четыре возможных способа реализации SOA: простой обмен сообщениями, «публикация/подписка», маршрутизация сообщений о событиях и надежный обмен сообщениями. Здесь сервис рассматривается как частный случай события.

Первым механизмом реализации SOA стал непосредственный обмен сообщениями между провайдером и потребителем сервисов (replay/request). Предполагается, что потребитель посылает запрос в виде сообщения и ждет ответного сообщения, содержащего нужный сервис. Сообщение заказчика должно содержать обратный адрес и спецификацию желаемого действия. Ответное сообщение поставщика может содержать желаемые сведения или, к примеру, быть пустым.

Механизм «публикация/подписка» в некоторых случаях ассоциируют с EDA, хотя он точно так же может быть использован и для создания SOA. Потребитель подписывается на сведения об определенных категориях событий, описывая средствами метаданных интересующие его события. Провайдер сервисов или промежуточное звено анализирует заявку и передает сведения о событиях подписчику.

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

Асинхронность освобождает от излишней связанности двух сторон, но предполагает абсолютную надежность сети. Если сеть «падает», сообщения могут оказаться потерянными. Встроенные хранилища сообщений позволяют установить асинхронную передачу сообщений о событиях без риска их потери.

Все четыре механизма активно развиваются; разрабатываются несколько поддерживающих их стандартов, в том числе WS-ReliableMessaging, WS-Eventing и WS-Notification. Однако с точки зрения систем, управляемых событиями, наиболее перспективным из них, по мнению большинства аналитиков, является ESB. Его рассматривают в качестве первого шага к созданию так называемой «нервной системы предприятия». С одной стороны, он может взаимодействовать с разнообразными серверами приложений, выравнивая различия между приложениями, а с другой — полностью реализует требования EDA.

SOA и EDA и поддержка систем реального времени

В апреле 2004 года состоялась Internet-конференция «Сервисы и события — секретные составляющие эффективного предприятия», организованная аналитической компанией ebizQ. Ее основным итогом стало признание участвовавшими в ней экспертами того факта, что только подходы на основе SOA и EDA могут обеспечить предприятиям эффективное ведение бизнеса.

Как повысить скорость выполнения бизнес-процессов, увеличить их точность и гибкость? Нужно поменять природу прикладных систем, отказаться от монолитных систем. Следует перестать рассматривать каждое приложение по отдельности и начать видеть систему в целом. Сегодня SOA, а вскоре и EDA станут фундаментальными основами проектирования таких систем. Эти два архитектурных подхода позволят сблизить системы управления бизнесом с требованиями реального времени, то есть построить предприятие, работающее в режиме реального времени (real-time enterprise, RTE).

В этом смысле SOA и EDA взаимно дополняют друг друга. Архитектура SOA позволяет легко и быстро создавать новые и перестраивать имеющиеся ресурсы в соответствии с меняющимися условиями бизнеса. Архитектура EDA, со своей стороны, позволяет автоматически и без временных задержек инкорпорировать данные о происходящих событиях. Совместно SOA и EDA вполне могут стать своего рода «архитектурным каркасом» (architectural framework) систем, поддерживающих бизнес в режиме реального времени. Преимущества RTE состоят в том, что увеличивается способность предприятия к поддержке новых и изменению старых бизнес-целей, обеспечивается более полное использование приложений, снижаются уровень риска и стоимость внедрения новых сервисов.

Одно из возможных практических решений проблемы совместимости SOA и EDA предложила компания Tibco в документе, который был озаглавлен Enabling Real-Time Business Through A Service-Oriented and Event-Driven Architecture. Данное решение оформлено в виде трехуровневой модели, ядром которой являются три ставших уже классическими компонента SOA, обеспечивающих ее функционирование, но не являющихся архитектурными:

  • средства регистрации и обнаружения сервисов (Service Registration & Discovery), поддерживаемые стандартом UDDI;
  • средства описания сервисов (Service Description), поддерживаемые стандартом WSDL;
  • средства передачи запросов и транспортировки (Service Request/Transport), поддерживаемые стандартом SOAP.

Первый уровень SOA — это системная архитектура, поэтому в его создании помимо традиционных проектировщиков должны участвовать специалисты, называемые системными архитекторами.

Второй уровень SOA разделяется на пять составляющих. Совместно они позволяют «собрать» отдельные способные к взаимодействию сервисы в действующую систему, пригодную для эксплуатации.

  • Оркестровка сервисов. Выполняя оркестровку, архитектор предоставляет возможность разработчикам, с одной стороны, и представителям заказчика — с другой, собрать множество сервисов в единую систему, адекватную потребностям бизнеса.
  • Управление метаданными. В данном случае роль архитектора состоит в подготовке набора данных о сервисах и приложениях, которые позволят разработчикам отдельных приложений действовать автономно друг от друга.
  • Мониторинг и администрирование. Архитектору необходимо предоставить администратору будущей системы возможность осуществлять мониторинг готовности и производительности отдельных приложений и сервисов. Администратор должен иметь возможность вводить в систему новые сервисы по мере их появления.
  • Безопасность. Архитектор формулирует требования к проектировщикам, относящиеся к контролю над доступом, к аутентификации и авторизации запросов, к шифрованию критически важных данных, а при необходимости — и требования к физической безопасности.
  • Надежность, готовность, масштабируемость. Архитектор определяет требования к надежности и готовности отдельных сервисов и системы в целом, а также способность системы адаптироваться к изменениям нагрузки.

Третий уровень — функциональные элементы EDA. Главная задача архитектора при работе на этом уровне состоит в обеспечении асинхронного обмена сообщениями по мере возникновения событий. Отсутствие обязательности в непосредственной реакции на сообщение или в подтверждении получения требует создания такой системы, которая сохраняла бы возможность получения сообщений о событиях даже при ее временной неработоспособности. Еще одна задача — задача управления событиями — состоит в превращении системы в такое «место», где события могли бы идентифицироваться, агрегироваться и управляться примерно так же, как в современных системах управляются данные или процессы.

IBM и EDA

Принятие корпорацией IBM нового технологического направления является если не необходимым, то уж точно достаточным условием для подтверждения его истинности. На появление EDA корпорация ответила объявлением инициативы IBM Common Event Infrastructure (CEI). В нынешнем виде CEI представляет собой модульный набор для обработки событий, реализующий следующие функции:

  • транспортировка событий (event transport);
  • шина распространения событий (event bus distribution);
  • обеспечение жизнеспособности событий (event persistence);
  • подписка на события (event subscription);
  • модернизация событий (event updates);
  • очереди событий (event queries);
  • метаданные событий (event metadata).

CEI использует общую базу событий Common Base Event (CBE), основана на системе обмена сообщениями, которая имеется в IBM WebSphere, и использует концентратор обмена сообщениями, выполненный по технологии ESB. Рассмотрение CEI с большей степенью детализации выходит за рамки данной статьи: эта инициатива упомянута лишь для подтверждения серьезности идеи создания корпоративных информационных систем, способных функционировать в соответствии с потоком внешних событий.

О страхе, неуверенности и сомнении

Аббревиатура FUD (fear, uncertainty, doubt) впервые была использована известным разработчиком мэйнфреймов Джином Амдалом, когда, уйдя из корпорации IBM, он создал собственную компанию в надежде потягаться с самим Голубым Гигантом. Амдал писал: «Продавцы IBM вселяют страх, неуверенность и сомнение в умы потенциальных покупателей, которые рассматривают возможность приобретения продукции с маркой Amdahl». С тех пор этим термином стали обозначать неэтичную по отношению к конкурентам маркетинговую политику.

Один из новейших примеров массированного применения методов FUD — публикация Halloween. Так стали называть внутренние документы корпорации Microsoft, помеченные грифом «Для внутреннего использования», в которых выражалось негативное отношение к программному обеспечению с отрытыми кодами, в частности к Linux, говорилось об угрозе со стороны сообщества Open Source и мерах борьбы с такими программами. Несмотря на внутренний характер этих документов, они стали известны главному апологету идей Open Source Эрику Раймонду, были опубликованы и широко обсуждались в 1998 году.

В прямо-таки карикатурном виде методика FUD применялась компанией SCO в процессе против корпорации IBM в 2003 году.

В настоящее время аббревиатуру FUD чаще всего используют для обозначения чувства страха или неуверенности, вызываемого агрессивной популяризацией непроверенных технологий.

Кто такой системный архитектор

Мэрилин Гор в своей работе «Размышления о роли архитектора информационных систем» дает следующее определение: «Системный архитектор (System Architect) — это лидер всего готовящегося решения, это тот, кто проектирует, продумывает и создает внешнюю сторону проекта, его результат, который должен соответствовать представлениям заказчика. Системный архитектор отвечает за потребительские качества проекта, он управляет знаниями в процессе создания этих качеств. В своей деятельности он напрямую взаимодействует с менеджером проекта (Project Manager), вместе с которым они образуют единую руководящую команду. Кроме того, он взаимодействует с представителем заказчика — менеджером бизнес-системы (Business System Manager), обеспечивая совместно с ним соответствие продукта представлению о нем».