Топологии серверов приложений WebSphere Application Server для обеспечения высокой доступности
В этой статье я хочу рассказать какие есть подходы для обеспечения отказоустойчивости и масштабирования инфраструктуры серверов приложений WebSphere Application Server 7 компании IBM.
Для начала немного терминологии, которая будет использоваться:
Высокая доступность (англ. High availability) — это метод проектирования системы, позволяющий достигать высокого уровня доступности системы в течение какого-либо промежутка времени.
Для бизнес-систем высокая доступность подразумевает создание избыточности в критических бизнес-системах. Тогда отказ одного компонента, будь то отказ маршрутизатора или сетевой карты или ролграмного компонента, не будет вызывать сбой приложения.
Доступность в основном выражется в процентах или в «девятках».
А = MTBF / ( MTBF + MTTR).
90% («одна девятка») — 16.8 часов простоя в неделю
99% («две девятки») — 1.7 часа простоя в неделю
99.9% («три девятки») — 8.8 часов простоя в год
99.99% («четыре девятки») — 53 минуты простоя в год
MTBF (англ. Mean time between failures ) — Средняя продолжительность работы между остановками, то есть показывает, какая наработка в среднем приходится на один отказ.
MTTR (англ. Mean Time to Restoration ) — среднее время, необходимое для восстановления нормальной работы после возникновения отказа.
SPOF (англ. single point of failure ) — часть системы, которая в случае отказа делает систему недоступной.
WAS — J2EE сервер приложений компании IBM. Существует несколько вариантов поставки:
0. Community Edition — открытый проект на базе Apache Geronimo;
1. Express — 1 узел/1 сервер приложений;
2. Base — 1 узел/ n серверов приложений;
3. Network Deployment (ND) — включает в себя набор компонет для построения масшабируемой и отказоустойчивой инфраструктуры из большого количества серверов приложений;
4. и еще несколько различных специфических вариантов (for z/OS, Hypervisor Edition, Extended Deployment).
Далее будем рассматривать все, что связано с именно с версией Network Deployment 7 (WAS ND ). На данный момент уже существют версии 8.0 и 8.5, но подходы описанные в статье применимы и к ним.
Основные термины относящиеся к топологиям Network Deployment:
Ячейка — Организационный юнит, который включает в себя менеджер развертывания(Deployment Manager) и несколько узлов(Node). Менеджер развертывания управляет узлами посредством агентов узлов(Node Agent).
Узел состоит из агента узла, который, как мы уже понимаем, используется для управления, и одним или несколькими серверами приложений (Application Server).
Такая иерархия (Ячейка / Узел / Сервер) помогает организовать все множество серверов и объединять их в группы согласно функциональности и требованиям по доступности.
Сервер приложений — JVM 5й спецификации Java EE (версии WAS 8 и 8.5 соостветствуют спецификации Java EE 6)
Профиль — набор настроек сервера приложений, которые применяются при его запуске. При старте экземпляра JVM, настройки ее окружения считываются из профиля и от его типа зависят функции которые будет выполнять сервер приложений. Менеджер развертывания, агент узла, сервер приложений — это частные примеры профилей. Далее в статье мы рассмотрим зачем и когда применять различные профили и как они взаимодействуют вместе, и чего позволяют добиться.
Stand-alone профиль отличается от федерированного тем, что управление несколькими Stand-alone профилями выполняется из различных административных консолей, а федерированные профили управляются из единой точки, что намного удобнее и быстрее.
Постановка задачи
Итак, исходя из поставленных задач по обеспечению высокой доступности некой бизнесс-системы работающей на инфраструктуре серверов приложений нам необходимо построить такую инфраструктуру, которая будет обеспечивать выполнение этих требований.
Уровень I
Cтандартная трехуровневая архитектура. Имеем один физический/виртуальный сервер на котором расположен stand-alone профиль WAS со своей административной консолью, СУБД и HTTP-сервер.
Перечислим какие точки отказа присутствуют в данной конфигурации и от уровня к уровню будем пытаться их устранить:
1. HTTP cервер;
2. Сервер приложений;
3. База данных;
4. Все програмные компоненты, которые обеспечивают взаимодействие нашего сервера с другими компонентами инфраструктуры ПО ( Firewall, LDAP, и т.д.)
5. Аппаратные средства.
Уровень II
На этом уровне мы устраняем единственную точку отказа — сервер приложений. Для этого нам надо создать кластер из друх серверов приложиний и для управления ими нам понадобятся еще две компоненты:
а) менеджер развертывания;
б) агент управления.
Менеджер развертывания фактически выполняет функцию обьединения административных консолей всех серверов приложений, которые находятся под его управлением. При изменении конфигураций одного или нескольких серверов, настройки «спускаются» от менеджера равертывания на сервера посредством агентов управления.
В случае отказа одного из серверов приложений HAManager автоматически восстановит все данные на втором сервере.
Уровень III
На этом уровне мы можем закрыть сразу несколько точек отказа — HTTP-сервер и физический сервер на котором крутятся сервера приложений. Для этого вынесем нашу БД за пределы наших физических серверов. Уже на 2-х серверах развернем 2 узла и в каждом из них создадим по паре серверов приложений. И обьеденим все сервера в единый кластер. В случае отказа одного из физических серверов данные и состояния приложений будут восстановлены на второй системе. В дополнение к этому используя балансировщик нагрузки (еще один тип профиля) мы можем распределить поступающие запросы между системами и таким образом распределить нагрузку и повысить производительность работы наших приложений. Применяя данную топологию мы получаем новую возможную точку отказа — баланcировщик нагрузки.
Уровень VI
Дополним уровень III резервным балансировщиком нагрузки и в дополнение к этому обеспечим надежность нашей БД. Детально мезанизмы кластеризации баз данных рассматривать не будем, т.к. они сами достойны отдельной статьи.
Уровень V
И финальным аккордом продублируем всю инфраструктуру и перенесем ее подальше, на случай если наш дата-центр затопит
В дополнение к этому, возможно будет не лишним вынести наши Front-end сервера в DMZ зону.
Итого
Как видим обеспечение непрерывной работы критических бизнесс-систем может быть ОЧЕНЬ затратным и прежде чем начинать построение таких решений необходимо оценить все риски и готовность к внедрению.
WebSphere Application Server Liberty Profile
Введение
Если раньше Вам приходилось сталкиваться с разработкой приложений для WebSphere Application Server (далее WAS), то Вы конечно же знаете, что это процесс небыстрый. Для этого требовалось разворачивать свой собственный, «тяжелый», сервер приложений, одна перезагрузка которого занимала длительное время. В команде разработки WebSphere долго думали над тем, как предоставить разработчикам самую простую, лучшую и доступную среду для создания новых веб-приложений для WAS. В результате в версии WAS 8.5 появился новый Liberty Profile, который значительно упрощает процесс разработки приложений для WAS.
Итак, что такое Liberty Profile и что он делает?
Где скачать?
Скачать Liberty Profile можно на сайте WASdev — WebSphere Application Server V8.5.5 Liberty Profile. Данный сайт предлагает установить Liberty Profile двумя способами:
Установка
Скачиваем файл wlp-developers-runtime-8.5.5.1.jar и запускаем команду:
Принимаем условия лицензионного соглашения, а также указываем директорию, в которую необходимо разархивировать Liberty Profile. В моем случае это директория /Users/alex/Dev/WebSphere, в ней автоматически будет создана поддиректория wlp. Собственно директория wlp и есть наш Liberty Profile. Что далее? Необходимо ознакомиться с базовыми командами, которые нам предлагает утилита server находящаяся в директории bin.
Утилита server
* create — создает новый сервер
* start — запускает сервер в фоновом режиме
* run — запускает сервер в консольном режиме
* stop — останавливает запущенный сервер
* status — проверяет, запущен ли указанный сервер
Конфигурация сервера
Конфигурация сервера хранится в файле server.xml, который, в свою очередь, находится в директории usr/servers/TestServer/. Посмотрим его содержимое:
По умолчанию сервер использует TCP/IP порт 9080 для HTTP трафика, а также порт 9081 для HTTPS трафика.
Запускаем сервер любым удобным для Вас способом и переходим в браузере на страницу http://localhost:9080/: 
Установка приложений используя папку dropins
Если приложение не использует каких-либо специфических настроек, Вы можете поместить его (как архив или папку) в директорию dropins. Запущенный сервер автоматически определит изменения в статических или динамических ресурсах, например таких как JSP. Для обновления, допустим, сервлетов необходимо удалить приложение из папки dropins, немного подождать и добавить обновленную версию.
Установка приложений используя конфигурацию сервера
Если приложение использует какие-либо специфические настройки, Вам нужно поместить его в директорию apps и настроить в файле server.xml. Для того чтобы удалить приложение, удалите его настройки из файла server.xml. Можно настроить мониториг изменений в настроенных приложениях с автоматическим перезапуском, если были изменения.
Добавим поддержку Web Services, JMS и MongoDB
Скачиваем файл wlp-developers-extended-8.5.5.1.jar и запускаем команду:
Принимаем условия лицензионного соглашения, а также указываем директорию, в которой установлен Liberty Profile.
Проверяем работоспособность Liberty Profile
Скачиваем Servlet Sample, разархивируем его в директорию Liberty Profile.
Запускаем сервер и переходим в браузере на страницу http://localhost:9122/ServletApp/:
Другие примеры можно скачать на странице Liberty Repository — Product Samples.
СОДЕРЖАНИЕ
Архитектура
«Традиционная» (в отличие от варианта Liberty) платформа WebSphere Application Server спроектирована как распределенная вычислительная платформа, которая может быть установлена на нескольких экземплярах операционной системы, совместно именуемых ячейкой WebSphere. Управление всеми экземплярами может осуществляться из узла управления, называемого диспетчером развертывания, внутри ячейки, а развертывание приложений, включая возможность выполнения скользящих обновлений, может осуществляться на подмножестве узлов ячейки. Информация о конфигурации для всей ячейки (количество узлов, какие приложения развернуты для каждого, как настроены приложения, управление сеансами и сведения о других ресурсах и т. Д.) Отслеживается в файлах конфигурации XML, которые распределяются по ячейке для каждый узел. За время существования продукта реализация этих деталей конфигурации перешла от файлов к базе данных (около v3.5) и снова к файлам (около v5).
Учитывая распределенную установку, а также учитывая, что управление всей ячейкой требует управления локальными эффектами (такими как развертывание, конфигурация журналирования и т. Д.), Общий эффект заключался в том, что безопасность WAS могла часто перекрывать локальную безопасность, если не была настроена должным образом. Например, в более ранних версиях консоли управления была возможность указать расположение файла журнала на удаленном узле. Это можно использовать для чтения / записи в произвольный файл на этом удаленном узле. По этой причине не рекомендуется запускать процессы агента сервера приложений / узла с привилегиями root, и, начиная с версии 6, конфигурация безопасности по умолчанию перешла в безопасное состояние (даже если это означало, что для включения требуемых функций требовалось ручное изменение значения по умолчанию). Первоначально все узлы ячейки находились в одном домене для управления, а также для обеспечения безопасности приложений. Однако, начиная с версии 6.1, может быть несколько доменов безопасности, а административная безопасность и безопасность приложений могут быть отдельными.
Многие продукты IBM (например, IBM InfoSphere DataStage ) используют WebSphere Application Server в качестве базовой платформы для своей инфраструктуры.
История версий
| Версия WebSphere | WebSphere Liberty (непрерывная доставка) | 9.0 | 8.5.5 | 8.5 Профиль Liberty | 8,5 | 8.0 | 7.0 | 6.1 | 6.0 | 5.1 | 5.0 | 4.0 | 3.5 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Последний пакет исправлений | 19.0.0.12 | 9.0.5.7 | 8.5.5.20 | 8.5.5.9 (следующее 16.0.0.2) | 8.5.0.2 | 8.0.0.15 | 7.0.0.45 | 6.1.0.47 | 6.0.2.43 | 5.1.1.19 | 5.0.2 | 4.0.7 | 3.5.7 |
| Дата выхода | 24 июня 2016 г. | 26 марта 2021 г. | 15 февраля 2021 г. | 15 июня 2012 г. | 15 июня 2012 г. | 17 июня 2011 г. | 17 октября 2008 г. | 30 июня 2006 г. | 31 декабря 2004 г. | 16 января 2004 г. | 3 января 2003 г. | 15 августа 2001 г. | 31 августа 2000 г. |
| Окончание поддержки | 24 июня 2016 г. (с выпуском 16.0.0.2) | 30 апреля 2018 г. | 30 апреля 2018 г. | 30 сентября 2013 г. | 30 сентября 2010 г. | 30 сентября 2008 г. | 30 сентября 2006 г. | 30 апреля 2005 г. | 30 ноября 2003 г. | ||||
| Java SE | 6 (до 17.0.0.2), 7, 7.1, 8 и 11 (с 19.0.0.1) | 8 | 6 (до 8.5.5.13), 7, 7.1 (с 8.5.5.2) и 8 (с 8.5.5.9) | 6, 7, 7.1 (начиная с 8.5.5.2) и 8 (начиная с 8.5.5.5) | 6 и 7 | 6 | 6 | 5 | 1.4 | 1.4 | 1.3 | 1.3 | 1.2 |
| Java EE | 6 (веб-профиль) и 7 | 7 | 6 | 6 (веб-профиль) и 7 (начиная с 8.5.5.6) | 6 | 6 | 5 | 1.4 | 1.4 | 1.3 | 1.3 | 1.2 | 1.2 (не полностью соответствует) |
| Сервлет | 3.0, 3.1, 4.0 | 3.1 | 3.0 | 3.1 | 3.0 | 3.0 | 2,5 | 2,4 | 2,4 | 2.3 | 2.3 | 2.2 | 2.1 и 2.2 |
| JSP | 2.2, 2.3 | 2.3 | 2.2 | 2.3 | 2.2 | 2.2 | 2.1 | 2.0 | 2.0 | 1.2 | 1.2 | 1.1 | 0.91 и 1.0 и 1.1 |
| JSF | 2.0, 2.2, 2.3 | 2.2 | 2.0 | 2.2 | 2.0 | 2.0 | 1.2 | 1.1 | 1.0 | ||||
| EJB | 3.1 (облегченная), 3.2 | 3,2 | 3.1 | 3,2 | 3.1 | 3.1 | 3.0 | 3.0 | 2.1 | 2.0 | 2.0 | 1.1 | 1.0 |
| JMS | 1.0, 2.0 | 2.0 | 1.1 | 1.1 | 1.1 | 1.1 | 1.1 | 1.1 | 1.1 | 1.02 | |||
| JDBC | 4.0, 4.1 | 4.1 | 4.1 | 4.1 | 4.0 | 4.0 | 4.0 | 3.0 | 3.0 | ||||
| JPA | 2.0, 2.1 | 2.0, 2.1 | 2.0 | 2.1 | 2.0 | 2.0 | 1.0 | 1.0 | 1.0 |
IBM поставила несколько версий и выпусков WebSphere Application Server.
В первых бета-версиях WebSphere назывался Servlet Express.
Хотя схема управления версиями x.1 и x.5 обычно указывает на второстепенный выпуск в индустрии программного обеспечения, WebSphere v6.1 и v5.1 являются основными выпусками, как и WebSphere v8.5 и v3.5.
Версии WebSphere Liberty
Версия 9.0
Версия 8.5.5
Версия 8.5.0
Возможности интеллектуального управления добавлены в редакции Network Deployment и z / OS сервера WebSphere Application server. Это объединяет операционные функции, которые ранее были доступны в отдельном предложении WebSphere Virtual Enterprise (WVE) : редактирование приложений, управление работоспособностью серверов, динамическая кластеризация и интеллектуальная маршрутизация.
Compute Grid также входит в выпуски Network Deployment и z / OS сервера WebSphere Application. Раньше это была отдельно оплачиваемая функция WebSphere XD Compute Grid для планирования и управления пакетными рабочими нагрузками Java.
Версия 7.0
Эта версия была выпущена 9 сентября 2008 г. Это сервер приложений, совместимый с Java EE 5.
Ниже перечислены основные функции, представленные в WebSphere Application Server версии 7:
Гибкое управление упрощает администрирование большого количества топологий базовой редакции WebSphere Application Server и сетевого развертывания, которые могут быть географически распределены.
Приложение бизнес-уровня используется для управления артефактами приложения независимо от упаковки или моделей программирования.
Функция конфигурации на основе свойств упрощает автоматизацию администрирования: администратор может обновить конфигурацию WebSphere Application Server версии 7 с помощью простого файла свойств.
Версия 6.1
Эта версия была выпущена 30 июня 2006 г. 11 сентября 2012 г. IBM продлила срок обслуживания V6.1 на полный год до 30 сентября 2013 г. и объявила о новых стимулах и поддержке перехода от одной версии к другой. Это сервер приложений, совместимый с Java EE 1.4, который включает следующие функции:
Поддержка технологии EJB 3.0 и поддержка некоторых стандартов веб-сервисов обеспечивалась пакетом функций EJB и пакетами функций веб-сервисов соответственно. Эти функции в этих пакетах функций были включены в основной продукт в версии 7. Функции пакета функций веб-сервисов включают:
Версия 6.0
Версия 5.1
Эта версия была выпущена 16 января 2004 г. Это сервер приложений, совместимый с J2EE 1.4.
Версия 5.0
Версия 4.0
Это был сертифицированный сервер приложений J2EE 1.2. Он унаследовал модель конфигурации на основе базы данных от V3.x для всех версий, кроме односерверной, в которой уже использовалось хранилище данных XML.
Версия 3.5 (и 3.0)
Версия 2.0
Версия 1.0
Безопасность
WebSphere поддерживает следующие механизмы аутентификации:
Руководство по WebSphere Application Server (документация)
ОнЛ@йн руководство с примерами по WebSphere Application Server
Этот сайт предлагает системным администраторам, разработчикам и архитекторам информацию по конфигурированию среды исполнения WebSphere Application Server V6.1, по формированию пакетов и по размещению Web-приложений, а также сведения о повседневных задачах, связанных с управлением средой WebSphere®.
Информация здесь представленная входит в серию справочных пособий, а вся эта серия предназначена для того, чтобы вы получили подробную информацию обо всем диапазоне продуктов WebSphere Application Server. Тут вы найдете детальное исследование сред исполнения WebSphere Application Server V6.1 и процесса администрирования.
Данный перевод включает информацию о конфигурировании и администрировании WebSphere Application Server V6.1 и WebSphere Application Server Network Deployment V6.1 на распределенных платформах (за исключением iSeries™) и WebSphere Application Server for z/OS® V6.1.
Часть 1. Основы
Данная часть знакомит вас с WebSphere Application Server V6.1. Здесь содержится информация об архитектуре времени выполнения, средствах администрирования и основах конфигурирования и управления средой исполнения.
Данная часть включает следующие главы.
• Глава 1. «WebSphere Application Server».
• Глава 2. «Управление системой: Технический обзор».
• Глава 3. «Знакомство с профилями».
• Глава 4. «Основы администрирования».
• Глава 5. «Администрирование с применением скриптов».
• Глава 6. «Конфигурирование ресурсов WebSphere».
• Глава 7. «Управление Web-серверами».
IBM WebSphere представляет собой ведущую программную платформу для электронного бизнеса по требованию (e-business on demand®). При своем полном лидерстве в области электронного бизнеса, WebSphere развивается, чтобы удовлетворять потребности компаний, сталкивающихся со сложными требованиями бизнеса, такими как необходимость в повышении эффективности операций, в укреплении доверия клиентов и в интеграции разнородных систем. WebSphere предоставляет необходимые возможности в сложной современной бизнес-среде.
Архитектура IBM WebSphere позволяет вам создавать важные для бизнеса Web-приложения. WebSphere включает в себя широкий диапазон продуктов, помогающих разрабатывать и обслуживать Web-приложения. Эти продукты созданы для того, чтобы клиентам проще было создавать, размещать Web сайты и осуществлять управление динамическими Web-сайтами с большей эффективностью.
В данной главе мы рассмотрим новый продукт WebSphere Application Server V6.1 для распределенных платформ и WebSphere Application Server для z/OS.
1.1. Общий обзор продукта
В основе продуктов WebSphere лежит технология Java. В течение многих лет многие производители программного обеспечения совместно работали над серверными технологиями прикладного программирования, которые помогают создавать доступные через Web, распределенные и не зависящие от платформы приложения. Эти технологии в совокупности объединяет марка Java 2 Platform, Enterprise Edition (J2EE). Она отличается от платформы Java 2 Standard Edition (J2SE™), с которой знакомы большинство клиентов. J2SE поддерживает разработку клиентских приложений с богатым графическим пользовательским интерфейсом. Платформа J2EE основана на J2SE платформе. J2EE включает прикладные технологии определения бизнес-логики и доступа к корпоративным ресурсам, таким как базы данных, системы планирования ресурсов предприятия (Enterprise Resource Planning, ERP), системы обмена сообщениями, почтовые системы и т.п.
Потенциальная польза J2EE для клиентов огромна. Среди преимуществ J2EE можно назвать следующие.
• Направляемый архитектурой подход к разработке приложений позволяет снизить стоимость обслуживания и помогает сформировать информационно-технологическую (ИТ) инфраструктуру с возможностью масштабирования и включения в себя новых служб.
• Разработка приложений ориентирована на уникальные бизнес-требования и правила, такие как обеспечение безопасности и поддержка транзакций. Это повышает производительность и укорачивает цикл разработки.
• Технологии, соответствующие промышленным стандартам, позволяют клиентам выбирать платформы, средства разработки и промежуточное программное обеспечение, которые будут лежать в основе их приложений.
• Встроенная поддержка Интернет- и Web-технологий позволяет создавать приложения нового поколения, которые предлагают услуги и информацию более широкому диапазону покупателей, поставщиков и других партнеров без необходимости в интеграции разных фирменных систем.
1.2. WebSphere Application Server
WebSphere Application Server предоставляет среду для выполнения основанных на Web-технологиях приложений для электронного бизнеса. Сервер приложений функционирует как промежуточное программное Web-обеспечение или средний уровень в трехуровневой среде электронного бизнеса. Первый уровень представляет собой HTTP-сервер, который обрабатывает запросы от клиента-браузера. Третий уровень это база данных бизнеса (например, DB2 UDB for iSeries) и бизнес-логика (например, традиционные бизнес-приложения, такие как обработка заказа). Средний уровень это WebSphere Application Server, который предлагает основу для единой и организованной связи между HTTP-запросами, бизнес-данными и логикой.
WebSphere Application Server доступен для широкого диапазона платформ и в составе различных комплектаций, ориентированных на конкретные нужды бизнеса. Также он служит основой для других продуктов WebSphere, таких как WebSphere Enterprise Service Bus и WebSphere Process Server, предоставляя для запуска этих специализированных приложений сервер приложений.
На рис. 1.1. показан общий обзор WebSphere Application Server.
Рис. 1.1. Общий обзор WebSphere Application Server
Сервер приложений является ключевым компонентом продукта WebSphere Application Server, предоставляющим среду исполнения для приложений, удовлетворяющих спецификациям J2EE 1.2, 1.3 и 1.4. Клиенты обращаются к этим приложениям с помощью стандартных интерфейсов и интерфейсов прикладного программирования (API). Эти приложения, в свою очередь, имеют доступ к широкому диапазону внешних ресурсов, таких как существующие системы, базы данных, Web-службы и ресурсы обмена сообщениями, которые могут использоваться для обработки клиентских запросов. В версии 6.1 сервер приложений получил возможность выполнения портлетов, совместимых с JSR 168, и приложений Session Initiation Protocol (SIP), написанных в соответствии со спецификацией JSR 116.
В пакетах Base и Express вы ограничены созданием только одиночных серверов приложений. Пакет Network Deployment позволяет расширить эту среду, добавив несколько серверов приложений, которые управляются из одной точки и могут объединяться в кластеры для обеспечения масштабируемости системы и высокой доступности приложений.
WebSphere Application Server поддерживает асинхронный обмен сообщениями с использованием JMS-провайдера и соответствующей системы обмена сообщениями. WebSphere Application Server включает в себя полностью интегрированного провайдера JMS 1.1, который называется провайдером по умолчанию системы обмена сообщениями. Данный провайдер дополняет и расширяет WebSphere MQ и сервер приложений. Его можно использовать для обмена сообщениями между серверами приложений, а также для обеспечения обмена сообщениями между WebSphere Application Server и существующей средой WebSphere MQ.
WebSphere Application Server предлагает возможности аутентификации и авторизации для обеспечения безопасности административных и пользовательских приложений. Среди возможных реестров пользователей можно выделить реестр пользователей операционной системы, реестр LDAP (например, Tivoli® Directory Server), собственные реестры, реестры, основывающиеся на файлах или интегрированные хранилища. Наряду с имеющимися по умолчанию возможностями аутентификации и авторизации, вы можете использовать для обеспечения безопасности приложения и внешнего провайдера авторизации, совместимого с Java Authorization Contract for Containers (JACC). Клиент IBM Tivoli Access Manager, встроенный в WebSphere Application Server, совместим с JACC, и его можно применять для обеспечения без опасности ресурсов, находящихся под управлением WebSphere Application Server. Данная клиентская технология предназначена для использования в сочетании с Tivoli Access Manager Server (поставляемом в пакете Network Deployment).
WebSphere Application Server работает с Web-сервером (например, IBM HTTP Server) и переправляет запросы от браузеров приложениям, работающим в среде WebSphere Application Server. Для установки предлагаются подключаемые модули (плагины) Web-сервера для поддерживаемых Web-браузеров. Плагин направляет запрос на соответствующий сервер приложений и выполняет перераспределение нагрузки между серверами, входящими в кластер.
Пакет WebSphere Application Server Network Deployment включает в себя такие компоненты Edge Component, как Caching Proxy и Load Balancer, которые используются в крупномасштабных системах с высокой доступностью. Использование этих компонентов помогает снизить нагрузку на Web-сервер, повысить доступность материалов и улучшить производительность Web-сервера.
