Технология Клиент-Сервер 2007'4

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

Ajax для Java-разработчиков: Создание масштабируемых Comet-приложений с использованием Jetty и Direct Web Remoting

Автор: Филипп Маккарти (Philip McCarthy)
Материал предоставил: http://www.ibm.com/developerworks
Опубликовано: 22.10.2008

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

В Ajax-приложениях для решения этой проблемы используются два фундаментальных подхода: либо браузер может ежесекундно опрашивать сервер на предмет наличия обновлений, либо сервер может хранить открытым соединение, установленное браузером, и передавать данные, когда они станут доступными. Такая технология долговременного соединения получила название Comet (см. раздел "Ресурсы"). В данной статье рассказывается о том, как можно совместно использовать движок Jetty servlet и DWR для простой и эффективной реализации Comet-приложения.

Почему Comet?

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

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

Чем отличается Jetty 6

Внутри механизма Continuations сервера Jetty

Извлечение пользы из Continuations

Написание приложения, основанного на Continuations

Создание Comet-клиента

DWR 2: Reverse Ajax

Заключение

Вы увидели, как Jetty Continuations совместно с Comet может обеспечить эффективное, масштабируемое решение для управляемых событиями Ajax-приложений. Я не предоставил никаких показателей масштабируемости Continuations, поскольку производительность в реальных приложениях зависит от очень многих факторов. Оборудование сервера, выбор операционной системы, реализация JVM, конфигурация Jetty и, конечно же, дизайн вашего Web-приложения и профиль трафика, все это влияет на производительность Jetty Continuations под нагрузкой. Однако Грег Вилкинс (Greg Wilkins) из Webtide (главные разработчики Jetty) опубликовал официальный доклад по Jetty 6, сравнивающий производительность Comet-приложения с и без Continuations, обрабатывающего 10000 одновременных запросов (см. раздел "Ресурсы"). В его тестах использование Continuations сокращает расход потоков и, попутно, потребление стека более чем в 10 раз.

Вы также узнали, насколько легко можно реализовать управляемое событиями Ajax-приложение, используя технологию DWR Reverse Ajax. DWR не только намного сокращает объем кодирования на стороне клиента и сервера, но Reverse Ajax также абстрагирует из вашего кода весь механизм передачи данных сервером. Можно свободно переключать методы (Comet, опрос или даже комбинирование), просто изменяя конфигурацию DWR. Вы свободно можете экспериментировать и искать лучшую по производительности стратегию для вашего приложения, никак не изменяя код.

Если вы хотите поэкспериментировать с вашим собственным Reverse Ajax-приложением, отличным способом дополнительного изучения является загрузка и исследование кода демонстрационных материалов DWR (часть дистрибутива DWR в исходных кодах. См. раздел "Ресурсы"). Доступен также пример кода, использованный в данной статье, если вдруг вы захотите выполнить примеры самостоятельно.

Ресурсы

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

Copyright © 1994-2016 ООО "К-Пресс"