Глобальные промышленные серверы




Третий путь — вполне самостоятельное направление, цель которого — удовлетворить в одном "сверхпродукте" или комплексе продуктов одной фирмы-производителя все потребности современного промышленного предприятия — своего рода скатерть-самобранка от автоматизации. Многие фирмы — производители систем 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.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 году.

 



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2022-09-06 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: