Серверы корпоративных приложений - ОС для корпоративных информационных систем?

Категория программного обеспечения, называемая «Корпоративные серверы приложений» (enterprise application server — EAS) по традиции считается еще одним элементом ПО промежуточного слоя, известна примерно с середины 90-х. Однако внимательный анализ показывает, что посреднические функции разрослись настолько, что EAS превратился в центральный узел корпоративной информационной системы.

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

О масштабности этого значительного, но, как ни странно, еще находящегося на стадии становления явления (например, нет принятых стандартов де-юре) можно судить по размерам инвестиции в исследования и разработки, связанные с EAS. По совокупности они измеряются многими миллиардами долларов, одна только корпорация IBM по ее собственным заявлениям тратит в год на эти цели больше 1 млрд. долл. Предполагаемый объем рынка EAS 2004 году достигнет 12 млрд. долл.

Быстро изменяется и качественный состав участников рынка EAS, поначалу среди них не было крупных фирм. Как только обнаружилась ценность серверов приложений, немедленно начался процесс поглощения новичков ветеранами, как метафору текущей ситуации на рынке можно предложить такое образное выражение: «Большие собаки доедают средних». Его можно интерпретировать следующим образом. После передела на рынке EAS действуют серьезные игроки и оставшиеся не раскупленными мелкие. Последняя, и может быть самая заметная сделка — приобретение корпорацией Hewlett-Packard одной из ярких звезд среди тех, кто до сих пор самостоятельно работал на рынке EAS, — компании BlueStone.

Еще прошедшие два года были отмечены унификацией в технологических подходах к созданию EAS, направление оформилось технологически. На флаге большинства компаний начертано: «J2EE».

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

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

По сути EAS — один из основных ингредиентов чудовищного варева, создаваемого в котле в Кремниевой долине и ее «филиалов», за которым стоят NASDAQ. Весь этот огромный бизнес умещается в скромном обозначении «.com», но измеряется цифрами с колоссальным количеством нулей.

Еще одна сложность в представлении EAS заключается в том, что географическая область распространения этих технологий не так уж широка, по большей части они оседают недалеко от тех мест, где зарождаются, вырастают как своего рода технологические эндемики. Сказанное подтверждается статистическими данными. Более 70% продуктов EAS реализуется в пределах территории США, чуть больше 20% в Японии и Западной Европе, а совсем небольшой остаток делится между всеми другими странами мира (причем большая часть зарубежных внедрений ограничена очень крупными транснациональными предприятиями).

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

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

Функциональная структура корпоративной информационной системы

Исходя из сказанного выше, прежде чем перейти непосредственно к технологическим аспектам EAS, необходимо сделать довольно пространное вступление. Прежде всего, о роли времени. Лет за 250 до нашей эры философ Теофаст сказал: «Время — самая большая ценность человеческой жизни». Сегодня и для информационных систем фактор времени оказывается самой большой ценностью. Сетевые и телекоммуникационные технологии изменили шкалу времени в бизнесе. Это относится к техническому прогрессу, к времени разработки и внедрения систем, к скорости обслуживания клиентов, ко многому-многому прочему.

Корпоративные информационные системы в США развиваются настолько стремительно, что там не удается спрогнозировать бизнес-среду и технический ландшафт даже на 5 лет вперед. Стоит вспомнить первую пресс-конференцию, посвященную представлению Java, если не ошибаюсь, осенью 1995 года. Выступавший Эд Зандер, тогда финансовый, а теперь генеральный директор Sun Microsystems, был порядком растерян и не мог внятно объяснить, в чем же, по его мнению, заключается перспективность этого языка для бизнеса. Как сложно сейчас в это поверить! Спустя пять лет Java, точнее, платформа J2EE стала важнейшим компонентом современных корпоративных информационных систем.

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

Осознать сущность происходящего далеко не просто, пока нет даже адекватной лексики. Может быть, поэтому образовался поток довольно странных неологизмов, пограничных между бизнесом и технологиями, имеющих формат «х-X» или «X2X», где вместо «x» можно подставить «e» (electronic), «i» (internet), «с» (collaborative, слово, удивительно трудно переводимое на русский язык; назовем его коллаборационизмом, но без привычного отрицательного оттенка, или просто сотрудничеством). Вместо «X» можно подставить «A» (application), «B» (business), «C» (customer), «G» (government), «P» (pier)...

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

Вот уже более 50 лет все, что бы ни делалось новое, строилось по многослойной «капустной модели». Наготу первого «железа» прикрыли языки программирования и операционные системы, и так далее, и тому подобное. Каждый уровень делал компьютер удобным для пользователя. Алгол и Фортран приблизили компьютер к математику, системы САПР к инженерам проектировщикам, персональные компьютеры —- к рядовому пользователю. Теперь на очереди удовлетворение нужд корпорации. Для этого сложились необходимые и достаточные условия. Поэтому можно утверждать, что все возможные «х-X» или «X2X», по сути, являются всего лишь названиями для создающихся новых и еще не вполне определенных внешних оболочек. Своим существованием оболочки обязаны поддерживающим их новым технологиям. Они то и есть подлинная реальность, а не сами по себе модные слова, вызывающие вполне понятный скепсис с профессиональной точки зрения.

Корпоративные приложения, многозвенная архитектура и интеграция приложений

Эволюция многоуровневой модели

Создание современных крупных информационных систем все более напоминает построение иных, сложных технических систем, материальных по своей природе. Можно обнаружить потрясающее сходство, начиная от методологии, кончая распределением труда. Удивительно другое: то, что для специалистов в традиционных отраслях стало просто банальностью, здесь воспринимается почти как открытие. Это можно отнести к стандартизации, к использованию готовых компонентов и распределению труда между исследователями и инженерами. Список «открытий» можно продолжать.

Сервер приложений

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

Еще совсем недавно можно было встретить сетования на плохую определенность этого термина (его называли ill-defined). Понятно было, что нужно нечто, а вот что именно не вполне понятно. А сегодня, спустя пару лет, внимательно вчитавшись в три слова enterprise server application, можно просто восхиться тем, кто предложил такое отличное словосочетание. Читаем название «по слогам»: программная среда (server) для выполнения приложений (application) в масштабе предприятия (enterprise). Рассмотрим эти составляющие в последовательности: приложение, корпоративная среда, интеграция приложений в масштабе предприятия.

Приложения

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

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

Нередко в качестве одного из проявлений новой парадигмы приложений называют миграцию от приложений, ориентированных на обработку больших объемов данных (data intensive), к приложениям, работающим по запросам (event-driven), или к приложениям, ориентированным на обработку процессов (process-oriented).

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

Как провести грань между приложением и прикладной программой? Скорее всего, приложение — это программный модуль, адаптированный к работе в распределенной среде, имеющий четко определенные потребительские свойства и интерфейсы с другими модулями.

Многозвенная корпоративная среда

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

Исторически первыми были одноуровневые (монолитные) системы клиент-сервер, состоявшие из мэйфреймов или мини-ЭВМ и подключаемых к ним простых терминалов. Следующим этапом стало появление двухуровневых систем клиент-сервер, возникших в эпоху первых локальных сетей и поддерживаемых dBase, FoxPro, Clipper, Paradox и другими. С него, а особенно с появлением современных графических интерфейсов (Graphical User Interface — GUI), началось движение по направлению к толстому клиенту, и постепенно стали доминировать такие средства для разработки приложений, как PowerBuilder, Visual Basic и Delphi. Здесь логика представления данных и бизнес-логика размещаются на клиенте, который общается с логикой хранения и накопления данных на сервере, используя язык структурированных запросов SQL. Недостатки архитектуры с толстым клиентом общеизвестны. Как альтернатива ей возникла также двухзвенная архитектура, но с тонким клиентом и толстым сервером. Но и она далеко не совершенна; компенсировать ее изъяны призвана трех-, а точнее, многозвенная архитектура.

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

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

Преимущества налицо.

• Изменения на каждом из звеньев можно осуществлять независимо.
• Снижаются нагрузки на сеть, поскольку звенья не обмениваются между собой большими объемами информации.
• Обеспечивается масштабирование и простая модернизация оборудования и программного обеспечения, поддерживающего каждое из звеньев, в том числе обновление серверного парка и терминального оборудования, СУБД и т.д.
• Приложения могут создаваться на стандартных языках третьего или четвертого поколения (Java, Си или Кобол).

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

В этой модели срединное место занимают корпоративные серверы приложений. Пока ни о какой формальной стандартизации многозвенной модели речи не идет.

Эволюция архитектуры клиент-сервер очень прозрачно и с хорошими примерами описана в статье [1], которая завершается замечательной фразой: «К списку неизбежных сущностей, включающему смерть и уплату налогов, мы должны добавить "постоянное совершенствование архитектуры клиент-сервер"».

Таксономия серверов приложений

Интеграция приложений

Переход от разработки прикладных программ «на месте» к внедрению готовых приложений (в большинстве случаев, распределенных) обычно называют процессом интеграции приложений (Enterprise Application Integration — EAI). Движение EAI началось с распространением ERP-систем от таких компаний, как SAP, Baan, PeopleSoft и т.д. Сейчас считается, что средствами EAI обеспечивается создание решений масштаба предприятия (enterprise-scale solution), где собираются вместе готовые покупные приложения, унаследованные и разрабатываемые специализированные новые приложения. Основные технические приемы интеграции приложений реализуются с помощью серверов корпоративных приложений.

По сути своей это переход от штучной (кустарной) разработки к индустриальным и в большей мере инженерным, чем программистским методам работы. Разделение труда, стандартизация, блочное конструирование, которые сопровождают EAI, являются совершенно естественными явлениями для развитой индустрии. Против желания напрашивается аналогия с созданием современного автомобиля. Ни одна из крупных автомобильных компаний сегодня не занимается разработкой топливного, тормозного или выхлопного оборудования, они берутся готовыми и используются практически всеми производителями. Правда, по части автомобилей преимущества инженерного подхода по сравнению с кустарным производством были осознаны почти сто лет назад благодаря деятельности Генри Кадиллака и Генри Форда.

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

Упрощенная структура EAS

Однако справедливости ради надо сказать, что приверженцы традиционного «научно-ручного» подхода к программированию больших систем активно выступают против инженерного подхода. Среди них есть свои апостолы. Пожалуй, наиболее яркая фигура — профессор Массачусетского технологического института Филип Гринспан, его статью [2] можно рекомендовать для обязательного прочтения.

Гринспан считает, что при достаточно высокой квалификации разработчиков никакие многозвенные модели не нужны, доказывает, что можно сделать все быстрее и лучше. Спорить с ним сложно, но с уверенностью можно сказать, что его позиция была бы более оправдана, если бы на рынке труда было избыток специалистов того уровня, который имеют выпускники МТИ, реальная жизнь убеждает в том, что это далеко не так.

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

Серверы приложений как промежуточный слой

У EAS, как у двуликого Януса два лица, мы уже говорили об этом выше. Одним они обращены к бизнесу, другим к технологиям. В обоих случаях EAS выполняют промежуточную функцию.

Серверы приложений в иерархической организации бизнеса

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

В этой многозвенной модели организации бизнеса на нижнем уровне находятся «первичные» технологии J2EE, Microsoft ASP, PHP, а также многое иное и относительно немногочисленные компании-производители.

Уровнем выше находятся сами EAS, они основываются на виртуальных машинах Java или на брокерах запросов ORB. На этом уровне число производителей больше, оно измеряется несколькими десятками. За место в этой позиции сейчас ведется активная борьба.

Еще выше находятся компании, которые поставляют готовые блочные приложения.

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

Серверы приложений в эволюции архитектуры клиент-сервер

Развитие архитектуры клиент-сервер от двухзвенной к многозвенной можно упрощенно представить в виде трех эволюционных шагов. До 1993 года господствовала повсеместно и продолжает жить во многих организациях двухзвенная схема. Ураган World Wide Web сделал естественным появление трехзвенной, следом за ней, как только появились корпоративные задачи, возникла многозвенная архитектура, где центральное место заняли серверы приложений.

Все множество средств для разработки Web-приложений он разбивает на четыре группы: средства для разработки Web-страниц; простые серверы приложений; корпоративные серверы приложений; серверы, включающие пакеты готовых приложений.

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

Технологии EAS в 2001 году

Еще осенью 1999 года в области EAS можно было наблюдать определенное технологическое разнообразие, но 2000 год, знаменателен тем, что J2EE был принят в качестве стандарта де-факто всеми производителями. Это принципиально изменило положение на рынке, технический уровень перестал быть предметом конкуренции, самым важным стал уровень основных и дополнительных услуг.

В число основных служб входят: поддержка и выполнение процессов; доступ к СУБД; обеспечение динамических Web-страниц; контекстное управление сессиями. Дополнительными считаются: управление загрузкой; обеспечение бесперебойной работы; методы кэширования. Одной из основных характеристик современных серверов для корпоративных приложений становится их совместимость с J2EE, они все более унифицируются на уровне основных функций. Можно сказать, что благодаря этой стандартизации функции, которые выполняют EAS все больше и больше приобретают черты операционной системы в рамках корпоративной информационной системы.

Явления прошедшего года позволяют сделать вывод о том, что на протяжении нескольких лет называли сервером приложений можно «прикладным сервером Java», душой которого являются Enterprise JavaBeans. Следующий шаг в представлении EAS заключается в том, чтобы показать, как они строятся из EJB.

Литература