Топологии серверов приложений WebSphere Application Server для обеспечения высокой доступности. Серверы приложений

Как веб- сервер различает, что надо сделать с файлом, на который указывает URL , - передать его содержимое клиенту или запустить файл на выполнение? Существует два способа распознавания файлов, содержащих тексты CGI -сценариев.

• Первый способ заключается в том, что при установке веб-сервера один из каталогов специально выделяется для хранения сценариев. Обычно такой каталог получает имя cgi-bin (или Scripts для веб-сервера IIS). В этом случае, если клиент запрашивает файл из каталога cgi-bin , сервер воспринимает такой запрос как команду на запуск сценария. Файлы из других каталогов интерпретируются как HTML-документы.
• Второй способ использует расширение файла. При настройке сервера указывается, что файлы с определенными расширениями содержат коды сценариев.

Идентификация по расширению используется относительно редко. Чаще всего все сценарии помещаются в cgi-bin , /Scripts или в другой каталог, специально выделенный для их хранения.

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

Информация , передаваемая клиенту, должна соответствовать протоколу HTTP , т.е. состоять из заголовка и тела ответа. Как правило, получив данные от сценария, сервер самостоятельно добавляет первую строку заголовка.

НТТР/1.0 200 OK

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

Самый естественный формат для браузера - формат HTML . Результаты работы сценария обычно оформляются в виде веб-страницы, т.е. возвращаемые данные следует дополнить дескрипторами HTML . Таким образом, ответ CGI -сценария клиенту обычно выглядит так:

Content-type: text/html ответ сценария ……………………

Обратите внимание на пустую строку после выражения Content-type: text/html . Она обязательно должна присутствовать в ответе, в противном случае клиент воспримет все последующие данные как продолжение заголовка.

После компиляции программы необходимо скопировать исполняемый файл в каталог cgi-bin (или в другой каталог, предназначенный для размещения исполняемых файлов) из которого он может запускаться веб-сервером на выполнение по запросу клиента.

Для вызова данного сценария достаточно включить в веб-страницу следующий фрагмент HTML -кода:

• Если атрибут method имеет значение " GET ", строка параметров передается вместе с URL вызываемого сценария. Разделителем между URL и строкой параметров является символ " ?".
• Если атрибут method имеет значение " POST ", строка параметров передается в теле HTTP-запроса.

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

Если атрибут METHOD дескриптора имел значение " GET ", строка параметр передается серверу в качестве значения переменной окружения QUERY_STRING .

При использовании метода POST данные доставляются сценарию по-другому. Они передаются через стандартный поток ввода (STDIN). Чтобы сценарий смог определить, сколько символов следует читать из стандартного ввода, веб- сервер устанавливает значение переменной окружения CONTENT_LENGTH , равным длине строки параметров.

Получив управление, сценарий в первую очередь должен выяснить, с помощью какого метода выполнялась передача параметров . Эта информация содержится в переменной окружения REQUEST_METHOD .

Таким образом, в простейшем случае, чтобы выполнить обработку строки параметров, достаточно знать назначение трех переменных окружения:

Сценарии

К основным достоинствам разработки приложений на стороне веб-сервера в форме сценариев можно отнести следующие:

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

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

В плане быстродействия сценарные языки можно разделить на:

• Языки динамического разбора (например, command.com). Интерпретатор считывает инструкции из файла программы минимально требующимися блоками, и исполняет эти блоки, не читая дальнейший код.
• Предварительно компилируемые (например Perl). Вначале считывается вся программа, затем компилируется либо в машинный код, либо в один из внутренних форматов, после чего получившийся код исполняется.

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

Были рассмотрены возможности двух серверных платформ для терминальных решений. Но на рынке произошли изменения: появился новый сервер от Microsoft — "MS Windows 2000 Advanced Server", практически полностью уничтожающий различия между продуктами Microsoft и Citrix. Новый сервер обладает такими возможностями, как:

• Служба кластеризации и перераспределения нагрузки
• Поддержка протокола RDP5
• Поддержка доступа к серверу при помощи браузера IE (компонент ACTIVE X)
• Доступ к серверу печати, COM-портам и буферу обмена клиента.

Также стоит отметить появление на рынке продукта от компании Corel, который, к сожалению, в продажу на территории России не поступал и пока никакого независимого тестирования не проходил.

Основные задачи, которые выполняет сервер приложений — выполнение задач клиента и отправка изменившегося окна клиента. Здесь имеет смысл отметить два момента.

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

Второй показатель — скорость доставки обновленного экрана клиента. Здесь тоже имеет смысл обратить внимание на то, что даже если сервер у Вас фантастически быстр, то на повышение производительности будет влиять скорость соединения сервера с клиентом.

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

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

Выбор сервера приложений

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

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

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

Пример

Общее количество рабочих мест — 20. 10 пользователей используют только Microsoft Word, Excel, Outlook, IE (отдел продаж, маркетинга и PR), 3 пользователя используют только 1C (бухгалтерия), 4 пользователя используют IE, Outlook (начальники отделов), 2 пользователя очень редко используют Word и, наконец, остается системный администратор, загружающий все подряд от PhotoShop до J++.

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

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

Какие параметры вы должны получить:

1. Пиковая нагрузка на процессор. Частота пиковой нагрузки на процессор за день. Средняя продолжительность такой нагрузки.
2. Средняя загрузка процессора за день. Желательно также найти почасовую среднюю нагрузку.
3. Пиковое использование памяти. Частота пиковой нагрузки за день. Средняя продолжительность такой нагрузки.
4. Среднее использование памяти в течение дня, почасовая средняя нагрузка.

Вы должны провести такое испытание со всеми группами пользователей.

Далее вы легко можете получить так называемые "минимальные" показатели сервера приложений — помножьте средние показатели на количество пользователей в группе и сложите все группы. вы получите просто фантастические запросы к памяти — для нашего примера: около 780 Мбайт оперативной памяти и около 2 ГГц суммарной занятости процессора.

Но не стоит пугаться — метод, описанный выше неправилен:), так как терминальный сервер умеет эффективно использовать память.

К примеру, общий объем загружаемых компонентов Microsoft Word в памяти около 9 Мбайт, но 8 Мбайт из данного блока приходится на словари, графику и помощника. Когда будет запущена следующая копия Word, эти 8 Мбайт не будут загружены или продублированы — они будут доступны обеим копиям. Если какая-нибудь из них попробует изменить эту восьми мегабайтную часть, то измененная часть будет отделена и потребует немного памяти. Использование данного механизма распределения памяти позволяет экономить память. Но степень данной экономии вы сможете определить, только используя второго, подключенного к терминальному серверу клиенту. То есть вы подключаете второго клиента или запускаете записанную ранее роботом программу действий второй раз.

Итак, вы смогли определить примерные размеры приложений при повторном запуске. Далее вы должны составить примерную временную таблицу загруженности данного приложения в память. К примеру: Word — 27% времени, Excel — 10% времени, IE — 100% времени. Далее вы умножаете то количество памяти, которое действительно требуется на количество пользователей использующих данное приложение и на полученную таблицу. Получившиеся "мегабайто-сапиенс" и есть то минимальное количество памяти, которое вам потребуется (для нашего примера — около 340 Мбайт).

Процессорная мощность может быть вычислена и нормальным способом — вы можете просто сложить среднюю загруженность терминального сервера. Далее перевести эту загруженность в какие-либо масштабируемые единицы — к примеру, мегагерцы или показатели производительности какого либо теста процессора. Здесь стоит обратить внимание на то, что мегагерц — наихудший вариант, ибо 166MMX работает не 5 раз медленнее 800 МГц Athlon, но какой показатель наилучшим образом подходит для сравнения, к сожалению, сказать сложно.

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

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

вам должно быть известно количество таких моментов в течение рабочего дня и их распределение. Если таких перегрузок немного, то вы смело можете забыть про них, если же очень много то вам придется выделить дополнительные ресурсы памяти и процессора. К примеру, выяснилось, что обычная перегрузка происходит каждые 20 минут. При этом загрузка процессора возрастает на 200 МГц, плюс затрачивается в среднем около 10 Мбайт памяти. Продолжительность около 15 секунд. Практически именно данные показатели вы должны прибавить к минимальным. А вот утренняя перегрузка обладает другими качествами — предположим 20 перегрузок в течение 10 минут, длительностью около 20 секунд. вам тогда придется учитывать более сложную ситуацию — возникновение, скажем, двух перегрузок одновременно.

Итак, в итоге вы получили показатели: процессорная мощность — около 600 мегагерц процессор, 400 мегабайт оперативной памяти. Далее вы должны выделить память для самой операционной системы и ее сервисов. К примеру, если вы собираетесь инсталлировать Windows 2000 Advanced Server, смело прибавляйте 128 Мбайт памяти и около 40 МГц для внутренних задач.

Итог — 640 МГц на 512 Мбайт оперативной памяти.

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

Если вашим пользователям потребуется часто пользоваться жестким диском, рассмотрите возможность использования SCSI-контролера и SCSI-диска — это позволит разгрузить процессор, и уменьшить количество перегрузок.

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

После выбора

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

Во-первых, вы должны выбрать, будете ли вы использовать продукты компании Citrix или остановитесь на продуктах от Microsoft. Более дорогой вариант — Metaframe, обладает несколькими не очень важными с моей точки зрения возможностями:

• Program Neighborhood. Применение данного компонента практически бессмысленно, если количество пользователей менее 100, в любом случае вы сможете, используя стандартные средства администрирования, добиться той же эффективности
• Video Frame — данный компонент позволяет нескольким операторам или скажем только вам наблюдать за работой клиентов и если надо вмешиваться в их работу.
• Поддержка передачи звука
• Поддержка IPX/SPX, и некоторых другие протоколы, включая соединение по нуль модемному кабелю.

Наиболее важное отличие между данными терминальными серверами лежит в протоколе подключения клиентов. Microsoft использует для этого RDP 5.0, Citrix — ICA.

Эти протоколы имеют собственные плюсы и минусы. К примеру, ICA — платформенно-независимый протокол, клиент может работать на любой платформе, будь он веб-браузером или старым добрым Lunix. Протокол от Microsoft работает только на 2 клиентах — WIN16 и WIN32, но это дает ему возможность использовать вызовы WINAPI, что резко сокращает размер и количество передаваемых пакетов. В итоге данный протокол чаше демонстрирует возможность комфортной работы на полосе 4-8 Кбайт в секунду, когда Citrix даже при установке SPEEDSCREEN2 (утилиты для сжатия потока ICA) не демонстрирует показатели лучше 10 килобайт в секунду.

Как это может отразиться на работе вашего предприятия? Если вам придется подключать удаленное подразделение, то использование коммерческих линий часто оказывается очень дорогим удовольствием и сжатие потока будет очень важно. К примеру, для очень комфортного подключения одного клиента по RDP5.0 придется использовать два модема 33.6, а по ICA — в обязательном порядке выделенный канал.

Второй фактор при покупке данных продуктов — возможность приобрести их на территории России. Если продукты Microsoft еще присутствуют, то продукты от компании Citrix вам придется поискать. Как дополнительный плюс надо отметить русифицированость продуктов Microsoft.

Инсталляция

Windows 2000 Advanced Server

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

Citrix Metaframe 1.8

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

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

Настройка сервера после установки

Здесь я приведу несколько советов по улучшению состояния серверов:

1. Отключите сжатие потока, если ваши клиенты не обладают мощными процессорами. Это также должно снизить нагрузку на сервер.
2. Не используйте сервер как прокси, веб-сервер, сервер баз данных. Для этих целей выделите другую рабочую станцию.
3. Отключите или снизьте до 1-2 Мбайт кэширование битмэпов в случае использования бездисковых клиентов. Это разгрузит сеть и убыстрит работу.
4. Уменьшите до 640х480 точек и 16 цветов размер клиентского десктопа. Это резко снизит нагрузку на сеть и даст еще немного ресурсов серверу.
5. Отключите любые скрин-сейверы на стороне клиента, или, проще говоря, не инсталлируйте их.
6. Попытайтесь избавиться от любых DOS-компонентов или любых компонентов, активно использующих графику.
7. Отключите всевозможные видеоэффекты, заставки, фоны рабочего стола и тому подобные прелести.
8. Отключите шифрование, так как оно примерно на 5 процентов снижает скорость работы клиента.
9. Попробуйте отделить сегмент сети, в которой работает ваш сервер приложений и клиенты, это снизит нагрузку на сеть.
10. Увеличьте кэш битмапов до максимума, в случае использования дисковых клиентов. Это резко увеличит скорость обновления экрана.
11. Запретите пользователям использовать какие либо другие средства, кроме регламентированных (обязательно выключите пинбол при установке сервера, так как данное приложение готово загрузить все предлагаемые ему мощности;))

Данные советы, надеюсь, помогут высвободить определенные ресурсы, как сети, так и сервера приложений. Но существуют ситуации, когда требуется добиться еще большего результата в использовании сети — к примеру, получить возможность работы на 2-3 килобайтной полосе.

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

Основной вопрос в таких сетях: как отразится резкое снижение полосы пропускания на качестве работы.

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

Задержка при передаче данных была принудительно установлена в 0.25 секунды (я думаю, что большие задержки даже в России получить сложно). Все битмапы были предварительно кэшированы. Использовался RDP 5.0.

Канал 8 Кбайт в секунду

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

Канал 6 Кбайт в секунду

Резко возрастает время появления диалогов, даже при повторном запросе. Пауза между выводом символа в Word и нажатием кнопки около секунды. Но нормальная работа еще возможна.

Канал 4 Кбайта в секунду

Я ожидал открытие экрана авторизации около минуты. Технически работать еще можно, но ни скроллинг, ни любой вывод графики уже невозможен. При попытке нажатия на кнопку "Пуск" приходится ждать около 2 секунд. Данный режим подходит только для специализированных приложений.

Канал 2 Кбайта в секунду

Технически данная информация может помочь вам в принятии решения о подключении удаленного терминала. Если терминал используется для работы операционистки, то миграция с DOS на такую систему не прибавит комфорта (привычного для Windows), но и не понизит качества работы.

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

Если вам требуется консультация по установке терминальных серверов или построении корпоративных систем управления на их основе, то пишите мне по почте.

За счет использования разумной комбинации существующих технологий можно реализовать поразительные возможности такого вида приложений. Например, при соединении Web-сервера Apache с языком серверных сценариев PHP, получаем сервер приложений. Но в маркетинге этим термином обычно обозначают комплексное решение, которое содержит в себе все необходимые компоненты технологий. Такой подход к построению сервера приложений иногда даже облегчает разработку, поскольку существуют унификации разрабатываемых моделей и их централизованная поддержка.

Для ответа на вопрос, может ли конкретное сервисное программное обслуживание считаться сервером приложений, необходимо сравнить его заявленные функции с теми атрибутами, которые присущи данному виду серверов:

Предоставление сервисных услуг для программ.

Предоставление модели контейнера для приложений.

Обеспечение управления приложениями. Представление средств их разработки.

Соответствие стандартам и индустриальным спецификациям.

Обслуживание веб-страниц, поскольку в этом существует реальная востребованность.

Преимущества при работе с серверами приложений:

Целостность кода и данных. Размещение на выделенном сервере дает для всех клиентов гарантию доступа к модернизированному ПО. Исключается работа с данными из устаревших программ.

Централизованное управление. Все изменения в конфигурации прикладных программ выполняются централизованно.

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

Производительность. На сервер приложений можно возложить задачу по балансировке сетевого трафика. Результат – равномерное распределение нагрузки между физическими серверами системы.

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

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

Сначала были Файл-сервер и Принт-сервер, довольно быстро к ним добавился Почтовый сервер. Не успели мы как следует привыкнуть к Web-серверам, как судьба подкидывает нам новые испытания - изволь осваивать Сервер Приложений. Особая проблема возникает при переложении понятия на русский язык. Тут уже путаница становится просто невообразимой. Искушенный читатель может с досадой воскликнуть - «Э! Да что же тут нового? Это же обычная многозвенка: сервер приложений, сервер базы данных и клиент!» - и прекратить чтение. Однако, Сервер Приложений - это Федот, да не совсем тот.

Итак, начнем по порядку, чтобы и не столь искушенный читатель понял, что имеется в виду. Предмет наших размышлений - это Application Server или Сервер Приложений. Ныне модно в качестве предисловия давать рекламу наоборот - перечислять то, чего в написанном нет; то ли из ложной скромности, то ли следуя завету Микеланджело: убирать все лишнее. Поэтому вы не найдете в этой статье серьезного доказательного сравнения технических реализаций Серверов Приложений, описания методов и приемов работы с этими реализациями, примеров файлов, листингов и кусков кода - приведен лишь список источников, в которых можно все это отыскать. Здесь же займемся более общими, но не менее увлекательными вопросами - что такое Сервер Приложений, зачем это нужно, как это покупать и выбирать и как с этим работать. Предвижу недовольство читателей, которые убеждены в том, что их не пускают на «кухню» и, следовательно, в приготовленном кушанье будет намешано неизвестно что. Приведу краткие соображения, почему следует читать и писать не только сугубо технические статьи. Прежде чем готовить еду, надо определить что - суп или гарнир, легкий ужин или обед для званых гостей, надо составить меню, заготовить продукты, выработать план изготовления, а уже потом приступать к поварскому ритуалу. Какой этап важнее - на этот предмет существует известная сказка, в которой плотник, портной и кукольник спорят, кому должна принадлежать сделанная ими кукла. Насколько я помню, в сказке побеждал кукольник, поскольку именно он вдохнул в куклу жизнь. В этом смысле таким волшебником несомненно является программист-разработчик. Нимало не преуменьшая его роль, я все-таки замечу, что современные программные приложения всегда плод коллективной работы. Поэтому провал или даже неудовлетворительное выполнение любого промежуточного этапа могут безнадежно загубить все дело.

Но, довольно реверансов. Нас ждет Сервер Приложений, которому просто не терпится убедить вас в том, что без него не обойтись.

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

Первая эра - эра эксклюзивного «монолита», когда компьютерные программы, или потом, пакеты программ, выполнялись на одном компьютере. Особого выбора у потенциальных потребителей программных продуктов тогда не было - или сам разрабатывай, или заказывай у опытных людей. Тогдашние операционные системы не баловали богатством возможностей - работает приложение на компьютере - и хорошо. Оно могло работать годами, выполняя раз навсегда закрепленные функции, и все были довольны. Это время часто называют и «эрой мэйнфреймов», хотя именно мэйнфреймы подошли вплотную к «тихой революции». От них появилась возможность приставить к одному серверу несколько «глаз» - терминалов, которые позволили плавно перейти в «клиент-серверную эру». Вот тут то и появляется служака «сервер». Сервер работает, служит, выполняя задания его величества клиента. Клиент от простенького «застенчивого» терминала вырастает до важного и значительного повелителя. Нынешний революционный момент характеризуется тем, что серверы не могут, а клиенты не хотят существовать по-старому. Первые не могут справиться с обилием поставленных перед ними требований, а вторые недовольны качеством обслуживания их запросов. Выход - в дальнейшей специализации. То, что пыхтя и отдуваясь выполняет несчастный сервер, теперь будет распределено на множество серверков - компонентов, каждый из которых успешно выполняет свою функцию. В такой компании клиенты превращаются в равноправные компоненты, чья задача - представительство функциональных сотоварищей (других компонентов) для пользователя, сидящего перед дисплеем.

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

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

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

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

Итак, если со стороны бизнеса все красиво, как на затейливом персидском ковре, то зато на изнанке - уйма всяких узелков и зацепок. Последние годы мировое программное сообщество усиленно пытается внести порядок в эту изнанку, в чем, надо сказать весьма преуспело. Основная возможность здесь - стандартизация компонентов, приведение их к единой природе. Блоки здания должны быть сопрягаемы. Нити ковра должны быть из близких материалов. Идея здесь достаточно проста - внешние интерфейсы компонентов должны быть описаны в едином стиле - на одном и том же языке. Поэтому два известных на сегодняшний день стандарта, CORBA и COM+ создали свои варианты IDL - Языка Описания Интерфейсов. CORBA, COM+ и технология Java, которая, естественно, использует для описания интерфейсов язык Java, предлагают близкие подходы к методу взаимодействия компонентов. На основе описания внешних интерфейсов создаются прокси (заместители) для клиента и сервера, которые позволяют им связываться друг с другом в реальном времени. Прокси для клиента принято называть стабом, а прокси для сервера - скелетоном. (Мы договорились - я не претендую на изложение технологий, а только даю краткий взгляд на них. Поэтому, в частности, не касаюсь возможностей динамического взаимодействия компонентов в технологии CORBA, когда внешние интерфейсы не определены на момент компиляции системы и появляются дополнительные динамические элементы.)

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

• ССМ (CORBA Component Model)- компонентная объектная модель, компонентное развитие модели бизнеса ВОМ - Business Object Model;
• BOCA (Business Object Component Architecture) - принципы архитектуры компонентных систем, развитие OMA (Object Management Architecture) на вышележащий уровень стандартизации;
• CDL (Component Definition Language)- язык определения компонентов, развитие IDL.

Разработка этих стандартов продвигается, правда, не так быстро, как хотелось бы всем заинтересованным сторонам. Но признанным героем на поле стандартизации компонентов стала технология компании Sun - Enterprise Java Beans (EJB). Возможно причина ее успеха в том, что в «семейном кругу» одного языка программирования намного проще решить вопросы взаимодействия. Тем более языка молодого и резвого, который многие проблемы, такие как вызов удаленных методов (RMI - Remote Method Invocation), умеет решать сам. Не иcключено, что универсальные цели консорциума OMG, развивающего технологию CORBA, - объединить компоненты, написанные на разных языках программирования, функционирующие на разных системах и разных компьютерах в разных точках земного шара, являются в данном случае некоторым тормозом. В дальнейшем мы увидим как две технологии, сомкнувшись, отбросив амбиции, дают замечательный результат на радость всем заинтересованным сторонам.

Что же такое этот «бин» (beаn - боб) и почему, стремительно выскочив как джин из бутылки в компьютерный мир, он уже завоевал такую популярность? Если перевести определение Sun как можно ближе к оригиналу - то «это модель для создания и развертывания серверных компонентов многократного использования, написанных на языке Java.» Продолжим вместе с Sun расплетать косу этого определения, - «компоненты - это заранее разработанные куски программного кода, которые могут быть установлены в работающие прикладные системы». Если классы Java образуют компонентную модель для проектирования приложений в технологии Java, то Java Beans логически развивает эту модель на следующем уровне интеграции создания автоматизированных систем и абстрагирования от процесса программирования - стадии внедрения. По сути, это переход от разработки приложения под заказ из готовых программных компонентов к сборке из готовых ЕJB действующих компонентов. Если раньше дома складывали из кирпичей, то теперь - из комнат-секций. Cлово Enterprise в названии Enterprise Java Beans означает новую ступень технических задач, стоящих перед программными приложениями. Такие задачи привычны для приложений уровня Предприятия: поддержка распределенности, службы именования, транзакций, безопасности, уведомлений-сообщений, долговременного хранения, и т.д. Неудивительно, что этот список напоминает список Служб технологии CORBA.

С точки зрения разработки, EJB представляют собой Java-классы специального типа вместе с описателем-паспортом бина и параметрами среды функционирования, которые бин умеет обрабатывать. Описатель бина (Deployment Descriptor) в свою очередь представляет собой XML-файл, в котором содержатся правила, связанные с управлением бином, например, права доступа пользователей к бину. Несколько бинов могут объединяться, образуя приложения, Java-апплеты и новые бины.

Рис. 4. Контейнер Enterprise Java Beans

По технологии EJB бобы-бины размещаются в стручке - контейнере (рис. 4) На контейнер возложены обязанности по защите бинов и поддержке их взаимоотношений с внешним миром: регистрация-прописка объектов, обеспечение для них внешних интерфейсов, создание и разрушение реализаций этих объектов, охрана безопасности, управление их состояниями и координация транзакций. В технологии не определено, как конкретно должен быть реализован контейнер. Это могут быть как многопоточные процессы на отдельном сервере, в которых выполняются бины, так и законченные программные приложения, которые можно переносить или распределять между серверами и/или процессами. Клиентские бины обрабатываются внутри виртуальных контейнеров, таких как Web-страницы, формы, составные документы, и т.д.

В технологии определены два основных типа бинов. Session Beans - сеансы клиент-серверного взаимодействия отрабатывают действия клиента, например, запись в базу данных, выполнение вычислений, и т.д. Это окна клиента в мир программных приложений. Они, в свою очередь, также бывают двух типов:

• Stateless session - не умеют сохранять свое состояние и существуют только на протяжении текущего сеанса. В случае сбоя сеанс не может быть восстановлен;
• Stateful session - сохраняют свое состояние; сеанс может быть восстановлен.

Entity Bean - компоненты объектного представления данных, размещаемых в хранилище. Entity Bean транзакционны и восстанавливаемы. Каждая их реализация имеет уникальную метку, называемую «первичным ключом» (Primary Key) по аналогии с таблицами баз данных. В свою очередь эти бины делятся на две группы по способу определения где, в каком хранилище и как хранятся данные:

• Bean-Managed Persistence - самостоятельные бины, управление хранением осуществляется на уровне бинов;
• Container-Managed Persistence - «опекаемые» бины, чьим хранением заправляет контейнер.

Кроме класса, реализующего функциональность бина, в него входят два обязательных класса, реализующие два типа интерфейсов:

• Home Interface - доступ к «домашним» службам бина, таким как начало или отбой для Session Bean или поиск Entity Bean. Этот интерфейс реализует все службы жизненного цикла компонента и позволяет контейнеру управлять и руководить его поведением;
• Remote Interface - доступ к бизнес-службам бина.

Клиентские приложения общаются с бинами через контейнер, который открывает наружу оба интерфейса бина: Home и Remote. С помощью первого открывается сеанс или находится нужный бин, а с помощью второго - осуществляется отработка действий клиента в Session или транзакционная механика обработки Entity.

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

Обратимся вновь к интерпретации Sun. Под Сервером Приложений в технологии Java понимается программное приложение, обеспечивающее оптимальную среду для выполнения EJB. Сервер Приложений занимается «коммунальным хозяйством» дома - программной системы. На его руках надзор за системными ресурсами, такими как процессы, потоки, память, связь с базами данных, сетевые отношения, выравнивание загрузки распределенных узлов. Кроме этого важнейшая обязанность Сервера Приложений заключается в предоставлении cle;, компонентам.

Еще раз хочу подчеркнуть, что технология EJB, впрочем, как и технология CORBA не предоставляет готовые программные решения - контейнеры, Сервера Приложений, а только стандарты на такой тип программного обеспечения.

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

Стандарты продолжают захватывать все новые области информационных технологий. Но, если в сетевых технологиях стандарты полностью прижились, то в области программных приложений они еще только набирают силу. Понятны опасения специалистов использовать в собственных решениях «неправильный» стандарт, который зачастую, невзирая на грамотные технические решения, заложенные в его основу, не идет дальше прекрасных инициатив и не получает развития. Выбирая дорогу, всегда есть опасность оказаться в тупике. Именно поэтому стоит внимательно читать указатели (в смысле дорожные знаки) и прислушиваться к мнению мирового сообщества. Серверы Приложений уже сейчас имеют реализации от большинства крупных производителей программных систем (компании Inprise, Oracle, Sybase, Sun, BEA, Iona, IBM). Кроме того, в данной области архитектуры программных приложений пока не появилось ни одного достойного конкурента. Так что стиль пока единственный - Сервер Приложений.

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

«А надо ли городить огород?, - спросит недоверчивый читатель. - Зачем мне такое дополнительное ПО для моего сугубо конкретного программного приложения?»

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

Чтобы постройка программного приложения не напоминала возведение Вавилонской башни, в технологии EJB расписано, кто именно должен принимать участие в проекте. Комплексная бригада строителей здания состоит, по представлению компании Sun, из следующих профессионалов.

Архитектор

Поставщик серверной платформы (EJB Server Provider) - специалист в области распределенной платформы и служб. Он предоставляет инфраструктуру разработки и среду выполнения для программных приложений.

Конструктор

Поставщик контейнеров (EJB Container Provider) - эксперт в области распределенных систем, системной безопасности и поддержки транзакций. Он обеспечивает системный уровень контейнеров, то есть системную оболочку для одного или более компонентов - Enterprise Bean.

Снабженец

Поставщик бизнес-компонентов (Enterprise Bean Provider) - аналитик в функциональной области, который реализует бизнес-компоненты как разработчик или подбирает готовые.

Монтажник

Компоновщик Приложений (Application Assembler) - также эксперт-функционал, собирающий программное приложение из строительных блоков - бизнес-компонентов. Его взгляд на соответствующий бизнес должен быть более общим и универсальным, чем у Снабженца - Поставщика бизнес-компонентов.

Прораб

Внедренец (Deployer) - специализируется в установке приложений. Он настраивает приложение на реальную среду.

Управдом

Администратор системы (System Administrator) - обеспечивает работоспособность системы на этапе эксплуатации.

Конечно, то, что компания Sun описала именно такие роли, не означает, что любой проект, связанный с Enterprise Java Beans обязательно требует одного и только одного указанного специалиста и именно такой состав комплексной бригады. Да и найти, скажем, готового поставщика контейнеров не так-то просто. Что совершенно необходимо - так это не упустить специфические для компонентного проекта моменты: выбор архитектуры и способы реализации системных служб, определение структуры и поведения контейнеров и проработка вопросов внедрения (развертывания).

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

Разочарованный читатель возмутится: «Зачем же нам объясняли про EJB, если в определении про них нет ни слова!» Попробую пояснить. Я намеренно привела универсальное определение Сервера Приложений, которое относится ко всем типам компонентов (CORBA, EJB, COM+). Серверы Приложений, зародившись внутри технологии EJB, оказались столь удобны, что достаточно уверенно продвигаются как единое решение для всех компонентных технологий. Реализации Серверов Приложений уже умеют работать с разными компонентами. В качестве примера приведу Application Server компании Inprise, который можно успешно использовать в среде компонентов EJB и CORBA. Другой наблюдаемый процесс - смыкание технологий Java и CORBA. С небольшой долей натяжки можно считать, что EJB могут иметь двойное гражданство, а именно представлять собой еще и CORBA-объекты. С моей точки зрения, поддержка CORBA является необходимым условием для конкурентности реализации Сервера Приложений. Ведь из всех перечисленных технологий только эта поддерживает Унаследованные Системы - функционально пригодные, но технически устаревшие. Если считать парк автоматизации современного предприятия или компании некоторым поселением - деревушкой или городком, создаваемая интеллектуальная компьютерная среда должна включать уже существующие постройки. Одинаково неправильно требовать сноса существующих зданий или не обращать на них внимания.

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

1. Интеграционный Сервер Приложений. (Application -integration-centric application server)

Основная задача такого Сервера - интеграция Бизнес-приложений в единую интеллектуальную среду. Такие Серверы особенно актуальны для организации приложений, связанных с задачами типа Supply Chain (Цепочки Поставщиков) и электронной коммерции. К таким серверам относятся реализации крупнейших поставщиков брокеров объектных запросов - компаний Inprise и Iona.

2. Информационный Сервер Приложений (Data-centric application server)

Деятельность такого сервера сконцентрирована на манипулировании данными. В качестве хранилищ могут выступать произвольные приложения, которые, в частности, не обязательно представляют собой реляционные базы данных и, уж тем, более объектные. Такие серверы берут на себя организацию представления распределенных данных, хранящихся в различных источниках, в объектной парадигме. Естественно, Oracle поставляет серверы именно такого типа.

3. Обрабатывающий Сервер Приложений (Processing-centric application server)

Центральной заботой таких серверов является обеспечение специфической бизнес-логики. Например, сервер, реализующий распределенные вычисления, или сервер ERP-системы. К таким реализациям относится IBM Websphere.

4. Управляющий Сервер Приложений (Rules-based application server)

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

5. Сервер XML (XML Server)

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

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

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

Рис. 5. Java 2 Enterprise Edition

Вскользь упомяну о следующих усилиях по созданию технологии компонентного программного обеспечения, снова связанных с Java. Это J2EE (Java 2 Enterprise Edition) - стандарт для многозвенных систем уровня предприятия, прикладная платформа, обеспечивающая взаимодействие Enterprise Java Beans, Java Server Pages, апплетов и сервлетов. рис. 5 в точности иллюстрирует то, как это выглядит у компании Sun.

Средства взаимодействия компонентов располагаются в нижней части рисунка. J2EE впервые стандартизовала выполнение родного для Java протокола удаленных вызовов методов через Internet - IIOP (Internet InterOrb Protocol). Таким образом, к сотрудничеству между CORBA и Java добавился еще один пункт. Серверные компоненты заключены в контейнеры, взаимодействующие с помощью специальных коннекторов. На уровне контейнеров задаются системные сервисы: Транзакций, Сообщений и Почты. На верхнем уровне находится API-интерфейс и Средства управления. Сказать об этой технологии в контексте Серверов Приложений меня вынудило не только то, что этот стандарт является логическим развитием технологии EJB, в которой впервые определился наш герой, но и то, что уже появляются Серверы Приложений, удовлетворяющие новому стандарту. Я имею в виду уже упоминавшийся Application Server (Inprise).

Но, стоп, боюсь, что Вы уже устали от обилия технологий и нагромождения стандартов? Если да - то тогда обратитесь к рис. 6, где я попыталась свести все воедино.

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

Легче ли создавать программные системы с помощью Сервера Приложений? Я бы покривила душой, если бы однозначно ответила - «да», хотя мне и очень хочется это сделать. Как всяким инструментом, к тому же непростым, им надо научиться пользоваться. Его нужно применять только в определенных условиях, как по инфраструктуре, так и по программному обеспечению. Отдельный вопрос - какую именно реализацию Сервера Приложений следует использовать. Сервер Приложений - верный друг, но только для заботливого и грамотного хозяина.

Об авторе

Марина Аншина - сотрудник отдела системной интеграции компании «ТопС, Системный Интегратор». С ней можно связаться по электронной почте по адресу: [email protected]

Моральный кодекс молодого строителя программного обеспечения - Сервера Приложений

Источники

27 ответов

В большинстве случаев эти термины Web Server и сервер приложений используются взаимозаменяемо.

Ниже перечислены некоторые ключевые отличия в функциях веб-сервера и сервера приложений:

• Веб-сервер предназначен для обслуживания содержимого HTTP. Сервер приложений также может обслуживать HTTP-контент, но не ограничивается только HTTP. Он может быть предоставлен для поддержки других протоколов, таких как RMI/RPC
• Веб-сервер в основном предназначен для обслуживания статического контента, хотя большинство веб-серверов имеют плагины для поддержки языков сценариев, таких как Perl, PHP, ASP, JSP и т.д., через которые эти серверы могут генерировать динамический контент HTTP.
• Большинство серверов приложений имеют в своем составе Web-сервер, что означает, что сервер приложений может делать все, на что способен веб-сервер. Кроме того, сервер приложений имеет компоненты и функции для поддержки сервисов уровня приложения, таких как пул соединений, объединение объектов, поддержка транзакций, службы обмена сообщениями и т.д.
• Поскольку веб-серверы хорошо подходят для статического контента и серверов приложений для динамического контента, большинство производственных сред имеют веб-сервер, выступающий в качестве обратного прокси-сервера для сервера приложений. Это означает, что при обслуживании запроса страницы статическое содержимое (например, изображения/статический HTML) обслуживается веб-сервером, который интерпретирует запрос. Используя какой-то метод фильтрации (в основном расширение запрашиваемого ресурса), веб-сервер идентифицирует запрос динамического содержимого и прозрачно пересылает сервер приложений.

Пример такой конфигурации - сервер HTTP Apache Tomcat и сервер Oracle (ранее BEA) WebLogic. HTTP-сервер Apache Tomcat - это веб-сервер, а Oracle WebLogic - это сервер приложений.

В некоторых случаях серверы тесно интегрированы, такие как IIS и.NET Runtime. IIS - это веб-сервер. При использовании среды выполнения.NET среда IIS может предоставлять приложения.

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

Веб-сервер : служит для контента в Интернете с использованием протокола http.

Сервер приложений : хосты и раскрывают бизнес-логику и процессы.

Я думаю, что главное, что веб-сервер предоставляет все через HTTP-протокол, в то время как сервер приложений не ограничивается им.

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

Это подробный ответ с некоторыми сценариями, чтобы четко понимать разницу, сходство и то, как оба могут работать совместно, и все

Сервер приложений - это термин, который иногда смешивается с веб-сервером . Хотя веб-сервер обрабатывает главным образом протоколы HTTP , сервер приложений имеет дело с несколькими различными протоколами, включая не ограниченный, HTTP .

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

Информация, перемещаемая между сервером и его клиентом, не ограничивается простой разметкой экрана, а взаимодействием между ними.

В большинстве случаев сервер создает это взаимодействие через API-интерфейс компонента , например J2EE (платформа Java 2), EJB (Enterprise JavaBean) и другие различные модели прикладных программ.

Пример:

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

Сценарий 1: веб-сервер без сервера приложений

у вас есть интернет-магазин с только веб-сервером и сервером приложений. На сайте будет представлен экран, на котором вы можете выбрать продукт. Когда вы отправляете запрос, сайт выполняет поиск и возвращает результат HTML обратно своему клиенту. Веб-сервер отправляет ваш запрос непосредственно на сервер базы данных (будьте терпеливы, я объясню это в нашем следующем самородок) и ждет ответа. После получения веб-сервер формирует ответ в файл HTML и отправляет его в ваш веб-браузер. Эта обратная и четвертая связь между сервером и сервером базы данных происходит каждый раз, когда выполняется запрос.

Сценарий 2. Веб-сервер с сервером приложений

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

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

Надеюсь, что это поможет.

Как указывал Rutesh и jmservera, различие является нечетким. Исторически сложилось, что они были разными, но через 90 эти две ранее отличающиеся категории смешивали черты и эффективно сливались. На данный момент лучше всего предположить, что категория продуктов "Сервер приложений" является строгим надмножеством категории "веб-сервер" .

Некоторая история. В ранние дни браузера Mosaic и гиперссылки на контент возникла эта вещь, называемая "веб-сервером", которая обслуживала содержимое веб-страницы и изображения через HTTP. Большая часть контента была статичной, а протокол HTTP 1.0 был всего лишь способом отправки файлов. Быстро категория "веб-сервер" эволюционировала, чтобы включить возможности CGI - эффективно запускать процесс на каждом веб-запросе для создания динамического контента. HTTP также созрел, и продукты стали более сложными, с кешированием, защитой и функциями управления. По мере того, как технология созрела, мы получили специфическую для Java технологию на стороне сервера от Kiva и NetDynamics, которые в конечном итоге слились в JSP. Microsoft добавила ASP, я думаю, в 1996 году к Windows NT 4.0. Статический веб-сервер узнал некоторые новые трюки, так что это был эффективный "сервер приложений" для многих сценариев.

В параллельной категории сервер приложений развился и существовал в течение длительного времени. компании поставляли продукты для Unix, такие как Tuxedo, TopEnd, Encina, которые были философски получены из приложений управления и мониторинга приложений для мэйнфреймов, таких как IMS и CICS. Microsoft предлагала Microsoft Transaction Server (MTS), который позже превратился в COM+. Большинство из этих продуктов указали "закрытые" протоколы коммуникаций, специфичные для продукта, для соединения "толстых" клиентов с серверами. (Для Encina протокол comms был DCE RPC, для MTS - DCOM и т.д.). В 1995/96 годах эти традиционные серверные продукты приложений начали внедрять базовые возможности HTTP-связи, сначала через шлюзы. И линии начали размываться.

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

В этот момент линия между "сервером приложений" и "веб-сервером" является нечеткой. Но люди продолжают использовать термины по-разному, в качестве акцента. Когда кто-то говорит "веб-сервер" , вы часто думаете, что HTTP-ориентированный, веб-интерфейс, ориентированные приложения. Когда кто-то говорит "Сервер приложений", вы можете подумать "более тяжелые нагрузки, функции предприятия, транзакции и очередность, многоканальная связь (HTTP + больше). Но часто это тот же продукт, который обслуживает оба набора требований к рабочей нагрузке.

веб сервер

Запустите python -m "SimpleHTTPServer" и перейдите по адресу http://localhost: 8080 . То, что вы видите, это веб-сервер в его работе. Сервер просто обслуживает файлы по HTTP, хранящиеся на вашем компьютере. Ключевым моментом является то, что все это делается поверх протокола HTTP. Также существуют FTP-серверы, например, которые делают то же самое (обслуживая сохраненные файлы), но поверх другого протокола.

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

Скажем, у нас есть крошечное приложение, как показано ниже (фрагмент из Flask).

@app.route("/") def homepage(): return "My homepage" @app.route("/about") def about(): return "My name is John"

Небольшой пример программы отображает URL / на homepage() функции homepage() а /about - на функцию about() .

Для запуска этого кода нам нужен сервер приложений (например, Gunicorn) - программа или модуль, который может прослушивать запросы от клиента и, используя наш код, возвращать что-то динамически. В примере мы просто возвращаем очень плохой HTML.

О какой бизнес-логике говорят все остальные? Итак, поскольку URL-адрес отображается где-то конкретно в нашей кодовой базе, мы гипотетически показываем некоторую логику о том, как работает наша программа.

резюмируя

веб-сервер - обслуживает файлы, хранящиеся где-то (чаще всего.css,.html,.js). Обычными веб-серверами являются Apache, Nginx или даже Python SimpleHTTPServer.

Сервер приложений - обслуживает файлы, созданные на лету. По сути, большинство веб-серверов имеют какие-то плагины или даже поставляются со встроенными функциями для этого. Существуют также строгие серверы приложений, такие как Gunicorn (Python), Unicorn (Ruby), uWSGI (Python) и т.д.

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

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

Веб-сервер → среда программирования

Причал: сервлет

Apache: Php, CGI

Серверы приложений → среда программирования

Сервер приложений WebLogic: EJB

Важнейшим отличием является то, что серверы приложений поддерживают технологию распределенного компонента , предоставляя такие функции, как удаленный вызов и распределенные транзакции, такие как EJB в мире Java или COM +/strong > на платформе Microsoft. Http-сервер часто поддерживает некоторые более простые среды программирования, часто скрипты, такие как ASP (.NET) в случае Microsoft или Servlet, включая JSP и многие другие в случае Java или PHP и CGI в случае Apache.

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

Наконец, стоит отметить, что картина искажена "легкими контейнерами", такими как Spring Framework, которые чаще всего дополняют назначение серверов приложений более простым способом и без инфраструктуры сервера приложений. И поскольку аспект распространения в приложениях перемещается из распределенного компонента в сторону парадигмы обслуживания и архитектуры SOA, для традиционных серверов приложений все меньше и меньше места.

Веб-сервер исключительно обрабатывает запросы HTTP/HTTPS. Он служит для содержания в Интернете с использованием протокола HTTP/HTTPS.

Сервер приложений обслуживает бизнес-логику для прикладных программ через любое количество протоколов, возможно, включая HTTP. Прикладная программа может использовать эту логику так же, как вызовет метод для объекта. В большинстве случаев сервер предоставляет эту бизнес-логику через компонентный API, такой как компонентная модель EJB (Enterprise JavaBean), найденная на серверах приложений Java EE (Java Platform, Enterprise Edition). Главное, что веб-сервер предоставляет все через HTTP-протокол, в то время как сервер приложений не ограничен этим. Таким образом, сервер приложений предлагает гораздо больше услуг, чем веб-сервер, который обычно включает в себя:

• API (собственный или нет) API
• Управление жизненным циклом объекта
• Управление состоянием (сеанс)
• Управление ресурсами (например, пулы подключений к базе данных)

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

Сервер приложений может (но не всегда) запускаться на веб-сервере для выполнения программной логики, результаты которой затем могут быть доставлены веб-сервером. Этот пример сценария сервера веб-сервера/сервера приложений. Хорошим примером в мире Microsoft является отношение Internet Information Server/SharePoint Server. IIS - это веб-сервер; SharePoint - это сервер приложений. SharePoint сидит "сверху" IIS, выполняет определенную логику и обслуживает результаты через IIS. В мире Java существует, например, аналогичный сценарий с Apache и Tomcat.

Поскольку веб-серверы хорошо подходят для статического контента и серверов приложений для динамического контента, большинство производственных сред имеют веб-сервер, выступающий в качестве обратного прокси-сервера для сервера приложений. Это означает, что при обслуживании запроса страницы статическое содержимое, такое как images/Static html, обслуживается веб-сервером, который интерпретирует запрос. Используя какой-то метод фильтрации (в основном расширение запрашиваемого ресурса), веб-сервер идентифицирует запрос динамического содержимого и прозрачно пересылает сервер приложений.

Пример такой конфигурации - Apache HTTP Server и BEA WebLogic Server. HTTP-сервер Apache - это веб-сервер, а BEA WebLogic - сервер приложений. В некоторых случаях серверы тесно интегрированы, такие как IIS и.NET Runtime. IIS - это веб-сервер. при наличии среды выполнения.NET. IIS способен предоставлять сервисы приложений.

Web Server Programming Environment Apache PHP, CGI IIS (Internet Information Server) ASP (.NET) Tomcat Servlet Jetty Servlet Application Server Programming Environment WAS (IBM WebSphere Application Server) EJB WebLogic Application Server (Oracle"s) EJB JBoss AS EJB MTS COM+

Основное различие между веб-сервером и сервером приложений заключается в том, что веб-сервер предназначен для обслуживания статических страниц, например HTML и CSS, тогда как сервер приложений отвечает за генерацию динамического содержимого путем выполнения кода на стороне сервера, например, JSP, сервлета или EJB.

Какой из них я должен использовать?
Как только вы узнаете разницу между веб-сервером и сервером приложений и веб-контейнерами, легко определить, когда их использовать. Вам нужен web server такой как Apache HTTPD, если вы обслуживаете статические веб-страницы. Если у вас есть Java-приложение с JSP и сервлетом для генерации динамического контента, вам понадобятся web containers такие как Tomcat или Jetty. Хотя, если у вас есть приложение Java EE, использующее EJB, распределенные транзакции, обмен сообщениями и другие полезные функции, вам нужен полноценный application server такой как JBoss, WebSphere или Oracle WebLogic.

Веб-контейнер является частью веб-сервера, а веб-сервер является частью сервера приложений.

Веб-сервер состоит из веб-контейнера, в то время как сервер приложений состоит из веб-контейнера и EJB-контейнера.

Веб-сервер выполняет HTTP-протокол для обслуживания веб-страниц. Сервер приложений может (но не всегда) запускаться на веб-сервере для выполнения программной логики, результаты которой затем могут быть доставлены веб-сервером. Этот пример сценария сервера веб-сервера/сервера приложений.

Хорошим примером в мире Microsoft является отношение Internet Information Server/SharePoint Server. IIS - это веб-сервер; SharePoint - это сервер приложений. SharePoint сидит "сверху" IIS, выполняет определенную логику и выполняет результаты через IIS.

В мире Java существует, например, аналогичный сценарий с Apache и Tomcat.

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

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

С одной стороны, веб-сервер обслуживает веб-контент (HTML и статический контент) по протоколу HTTP. С другой стороны, сервер приложений представляет собой контейнер, на котором вы можете создавать и выставлять бизнес-логику и процессы клиентским приложениям с помощью различных протоколов, включая HTTP, в архитектуре n-уровня.

Таким образом, сервер приложений предлагает гораздо больше услуг, чем веб-сервер, который обычно включает в себя:

• API (собственный или нет) API
• Управление жизненным циклом объекта,
• Управление состоянием (сеанс),
• Управление ресурсами (например, пулы подключений к базе данных),
• Балансировка нагрузки, сбой...

В терминах Java есть еще один: веб-контейнер (или, точнее, контейнер сервлетов). Это, скажем, между веб-сервером и сервером приложений. Веб-контейнер в терминах Java - это сервер приложений, который в основном реализует только часть JSP/Servlet Java EE и не имеет нескольких основных частей Java EE, таких как поддержка EJB. Примером является Apache Tomcat.

Граница между этими двумя становится все более тонкой.

Серверы приложений предоставляют бизнес-логику клиенту. Таким образом, подобный сервер приложений включает в себя набор методов (не обязательно, хотя и может быть сетевым компьютером, позволяющим многим запускать на нем программное обеспечение) для выполнения бизнес-логики. Таким образом, он просто выводит желаемые результаты, а не HTML-контент. (аналогично вызову метода). Так что это не строго HTTP-протокол.

Но веб-серверы передают HTML-контент в веб-браузеры (строго на основе HTTP). Веб-серверы могли обрабатывать только статические веб-ресурсы, но появление сценариев на стороне сервера помогло веб-серверам также обрабатывать динамическое содержимое. Где веб-сервер принимает запрос и направляет его на script (PHP, JSP, CGI-скрипты и т.д.), Чтобы СОЗДАТЬ HTML-контент, который будет отправлен клиенту. Затем веб-сервер знает, как отправить их обратно клиенту. ПОТОМУ ЧТО, что действительно знает веб-сервер.

Сказав это, в наши дни разработчики используют оба эти метода вместе. Если веб-сервер принимает запрос и затем вызывает script для создания HTML, НО script снова вызовет ЛОГИКУ сервера приложений (например, Получить данные транзакции), чтобы заполнить содержимое HTML.

Таким образом, в этом случае оба сервера были эффективно использованы.

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

Я прочитал много статей по этой теме и нашел довольно удобной.

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

Веб-сервер работает на компьютере, который "прослушивает" специально по каналу TCP/IP с использованием одного из "интернет-протоколов" (http, https, ftp и т.д.) и делает все, что он делает на основе этих входящие запросы... Как правило, (как определено на языке оригинала), он извлекал/сгенерировал и вернул html-страницу клиенту, либо извлечен из статического файла html на сервере, либо построен динамически на основе параметров входящего запроса клиента.

Все вышеперечисленное просто слишком усложняет что-то очень простое. Сервер приложений содержит веб-сервер, на сервере приложений есть еще несколько дополнений/расширений к нему, чем стандартные веб-серверы. Если вы посмотрите на TomEE в качестве примера:

CDI - Apache OpenWebBeans EJB - Apache OpenEJB JPA - Apache OpenJPA JSF - Apache MyFaces JSP - Apache Tomcat JSTL - Apache Tomcat JTA - Apache Geronimo Transaction Servlet - Apache Tomcat Javamail - Apache Geronimo JavaMail Bean Validation - Apache BVal

Вы увидите, что Tomcat (веб-контейнер/сервер) - это еще один инструмент в арсенале серверов приложений. Вы можете получить JPA и другую технику на веб-сервере, если хотите, но серверы приложений просто упакуют все эти вещи для вашего удобства. Чтобы быть полностью классифицированным как сервер приложений, вам, по существу, необходимо выполнить список инструментов, определенных некоторым стандартом.

Фактически Apache - это веб-сервер, а Tomcat - сервер приложений. Когда HTTP-запрос поступает на веб-сервер. Затем статическое содержимое отправляется обратно в браузер через веб-сервер. Есть ли логика и сделать это, а затем этот запрос отправляется на сервер приложений. после обработки логики, тогда ответ отправляется на веб-сервер и отправляется клиенту.

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

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