Третий путь — вполне самостоятельное направление, цель которого — удовлетворить в одном "сверхпродукте" или комплексе продуктов одной фирмы-производителя все потребности современного промышленного предприятия — своего рода скатерть-самобранка от автоматизации. Многие фирмы — производители систем SCADA движутся сейчас в этом направлении, и мне кажется, что больше всех здесь преуспела фирма Wonderware, выпустившая продукт FactorySuite. Кроме возможностей систем SCADA, в нем реализованы функции Batch Control, программирование логических контроллеров, ведение проектов, контроль качества продукции и некоторые функции автоматизации административного управления. Фирма Intellution, помимо систем SCADA, предлагает пакет типа Batch Control и пакеты с Интернет-функциями. Список фирм можно продолжить. Но все их предложения еще так далеки от полного комплексного решения задач автоматизации. Трудно представить, чтобы в ближайшее время появилась компания, способная решить все задачи предприятия на современном техническом уровне. Но кто знает?..
EDA — архитектура,управляемая событиями
Приходится констатировать, что создание даже сложных корпоративных информационных систем долгое время напоминало скорее сбор головоломок-пазлов с использованием метода «научного тыкая, нежели конструирование. Чтобы убедиться в этом, достаточно сравнить сложившуюся в ИТ культуру проектирования с классическими школами проектирования в области создания самолетов, судов или мостов. Далеко не простой процесс сборки этой самой мозаики отягощен не только отсутствием общей схемы прототипа, но и неполнотой комплекта фрагментов, из которых строится система.
|
Однако комплект деталей для сборки постоянно расширяется. С появлением средств моделирования бизнес-процессов (business process modeling, BPM) и введением в оборот архитектуры, управляемой событиями (event driven architecture, EDA), он наконец приобретает черты завершенности. Подходы, реализованные в BPM и, EDA вводят естественный порядок. Они позволяют сначала построить модель, а затем объединить отдельные фрагменты в единую систему, адаптированную к условиям внешней среды.
Однако ни моделирование, ни способность реагировать на внешние возмущения не являются чем-то принципиально новым — в отличие от приложения этих подходов к ИТ-системам управления бизнесом.
Любое предприятие существует в реальном мире, наполненном событиями. Оно не может не отрабатывать входной поток событий из окружающего мира, но даже при наличии самых развитых информационных систем это происходит неявно, в основном на уровне управленческого персонала. Так вот, реализация идей EDА знаменует собой начало миграции функций обработки событий от людей к автоматизированным системам.
Этой тенденции уделяют большое внимание в аналитической компании Gartner. Эксперты компании полагают, что в ближайшее время EDA окажется в центре внимания ИТ-отрасли. Кроме того, идеи EDА позволят лучше осознать, что такое архитектура, ориентированная па сервис (service oriented architecture, SOA ). Совместно SOA и EDA позволят сформировать подходы к предприятию, управляемому в режиме реального времени.
МЕМОРАНДУМ ШУЛЬТЕ
Термин EDA предложил Рой IПульте, аналитик компании Gartner, в опубликованном 9 июля 2003 года отчете с длинным названием «Повышение значимости событий для интеграции приложений. В будущем приложения станут в большей степени управляться событиями, чем современные. Пять движущих сил». Этот документ неожиданно быстро оказался в списке наиболее цитируемых работ по интеграции приложений, а его автор приобрел широкую известность среди специалистов.
|
Шульте утверждает, что бизнес начнет использовать EDA в период с 2004-го по 2008 год, поскольку существующие технологии интеграции приложений, практически игнорирующие события, перестают соответствовать требованиям бизнеса. Отныне и впредь будут востребованы иные подходы к интеграции, учитывающие поток событий во внешней среде.
I. Стратегии бизнеса требуют создания систем, учитывающих поток внешних событий. Бизнес-процессы, подчиненные событиям, — это не просто ускорение или улучшение существующих процессов; такие процессы принципиально отличаются от «обычного бизнеса». Важно то, что они органично воспринимаются практикующими менеджерами и аналитиками Одно из немаловажных преимуществ заключается в том, что появляется возможность оперативно исправлять ошибки, вполне возможные в человеческой деятельности, но способные нарушить традиционные процессы.
II. SOA —промежуточный этап на пути к EDA. Активная миграция в направлении архитектур, ориентированных па сервисы, позволяет проложить путь к адаптации событийных приложений и интеграции, поскольку они реализуются на основе распределенных слабосвязанных компонентов, которые характерны для SОA (можно указать, в частности, на такие свойства, как модульность, инкапсуляция, документированный интерфейс). Однако Шульте считает, что SOA в большей степени привязана к клиент-серверной архитектуре, а потому SOA и EDA хотя и родственные, взаимодополняющие явления, по не разные уровни одной иерархии.
|
III. Индустрия готова к поддержке EDA. Многие производители уже поставляют или готовятся к поставке необходимых программного обеспечения промежуточного слоя и средств разработки, адаптированных к особенностям новой архитектуры.
Для наиболее простых приложений вполне подходит существующее программное обеспечение промежуточного слоя, ориентированное на обмен сообщениями и на Wеb-сервисы, Могут быть использованы известные серверы приложений на основе J2EE, но, скорее всего, дальнейшее совершенствование серверов будет нацелено на их большую адаптацию к обработке событий.
Более сложные «событийные» приложения, которые используют контентно-зависимую маршрутизацию сведении о событиях и средства управления бизнес-процессами, могут быть реализованы специализированными интеграционными брокерами. Такие инструменты появятся не раньше 2006 года.
Самые сложные формы событийных приложений потребуют использования методов обработки сложных событий (complex event processing, СЕР).
IV. Процесс стандартизации уже начинается. Общепринятых стандартов для EDA пока не существует, но есть надежда, что они появятся в течение нескольких лет. «Ледоколом» эффективной стандартизации в этой сфере может служить достигший зрелости процесс стандартизации SOA. Хотя общее представление об архитектуре SOA и ее преимуществах теоретически было получено еще в начале 90-х годов, потребовалось почти десять лет (в том числе около пяти лет —на выработку стандартов для Web-сервисов), чтобы она обрела зримые черты. Есть основания полагать, что признаваемые большинством производителей стандарты на схемы обмена сообщениями в СЕР, как и языки описания событий (event-processing language, ЕРЕ) могут появиться уже в 2007 году.
V.Формируются новые требования к аппаратному обеспечению. Необходимость обработки событий окажет существенное воздействие прежде всего на создание сетевого оборудования. Оно должно обеспечить передачу больших объемов информации с меньшей задержкой и большей надежностью.
СЛЕДУЮЩАЯ БОЛЬШАЯ ВЕЩЬ
Год спустя после появлении отчета Роя Шульце компания Gartner опубликовала документ, озаглавленный «Миссия и будущее интеграции, версия 2» (2.0 The Mission and Future of Integration). В нем событийный подход к проектированию систем назван «следующей большой вещью», только теперь речь идет об архитектуре бизнеса, а не о системной архитектуре, как следовало из отчета Шультс.
В этой работе Gartner содержится ответ на ряд ключевых вопросов. Прежде всего, обсуждается, какое влияние окажут SOA и ЕDA на интеграцию приложений и какие изменения привнесут SOA и EDA в практику проектирования средств интеграции приложений. Предпосылкой к возникновению этих вопросов служит изменившаяся роль интеграции приложении. Надо признать, интеграция приложений в единую систему еще не стала основной задачей разработчиков систем. Так, В 1998 году интеграция стимулировалась прежде всего необходимостью внедрения систем планирования ресурсов предприятия, в 2000-м — модой на системы управления отношениями с клиентами, наконец, в 2004-м — усилившимися в Соединенных Штатах требованиями к контролю над деятельностью предприятий.
Однако все это в прошлом, а сегодня настала пора переосмыслить природу интеграции приложений с позиций создания комплексной системы управления бизнес-процессами. Практически все решения, унаследованные к сегодняшнему дню, построены на основе представления, что отдельные компоненты, данные и процессы не связаны между собой, причем построены с использованием различных средств, включая операционные системы, языки программирования, платформы для приложений, СУБД.
Существуют три основных подхода к интеграции приложений, два из которых вполне тривиальны, Первый базируется па простом согласовании данных (data consistency). Второй является более сложным, м ногоступенчатым процессом (multistep process) и основан на согласованной технологической цепочке, состоящей из связанных между собой операций. Оба подхода имеют право на существование, но лишь третий, названный композитными приложениями (composite applications), действительно позволяет создавать системы, управляемые событиями. При его использовании независимые приложения кооперируются для выполнения одного бизнес-процесса. Композитные приложения можно рассматривать как развитии многоступенчатого процесса, интегрирующего несколько уровней цепочек.
Для получения композитных приложений необходимо объединить унаследованные и приобретаемые вновь приложения путем создания специализированных кодов. Они могут быть написаны на языках третьего или четвертою поколения, а также сгенерированы с использованием средств моделирования. Создается система, состоящая из существующих приложении, которые занимают отведенные им места. Приложения, созданные на принципах SOA, легче встраиваются в композитные приложения по двум причинам, Вo-первых, они по определению являются модульными, а потому крупные работы проще разбивать на отдельные задачи. Во-вторых, они обладают свойством инкапсуляции, то есть способностью к прозрачному описанию интерфейсов, изолирующих внутренние части компонентов от внешних контактов. Все это позволяет организовывать взаимно независимую деятельность групп разработчиков, каждая из которых может сосредоточиваться на своей теме, не уделяя значительного внимания вопросам координации.
В подходах SOA и EDA много общего, поскольку они представляют собой способы комбинации разнообразных программных компонентов в большие распределенные приложения. Однако есть существенное структурное различие, SOA — что двунаправленная коммуникации типа «запрос-ответ», делегирующая работу подчиненным процедурам, а в ЕDA используется однонаправленный обмен сообщениями. Соответственно, EDA является дополнением, а не заменой SOA. В качестве основной технологии при практической реализации SOA и EDA, скорее всего, будет использоваться корпоративная сервисная шина (enterprise service bus,ESB). О том, что это действительно так, можно судить по вниманию компаний IBM и Microsoft к данной группе технологий, включающей я себя серверы приложений и инструментальные платформы для приложений. Аналитики Gartner предсказывают, что в 2006 году IBM выведет на рынок продукт WebSphere ESB; со своей стороны, Microsoft включит соответствующую технологию Indigo в состав Longhorn, следующего поколения операционных систем Windows в 2006-м или в 2007 году.