Асинхронный Ajax для революционных веб-приложений

import org.mortbay.util.ajax.Continuation;

service(request, response) {
    Continuation continuation = ContinuationSupport
        .getContinuation(request, this);
    ...
    continuation.suspend();
    response.getWriter().write(message);
}

To cause the request processing to be resumed when a chat message is ready:

message.setValue("Howdy");
continuation.resume();

Кот

API Tomcat 6, возможно, ближе всего к основам NIO асинхронной обработки запросов. Интерфейс Tomcat CometProcessor должен быть реализован сервлетом, обрабатывающим push-взаимодействие, но, как только он будет создан, доступны различные события, и запрос и ответ могут быть обработаны произвольным потоком.

import org.apache.catalina.CometProcessor;

public class Processor implements CometProcessor {

public void event(CometEvent event)  {
    request = event.getHttpServletRequest();
    response = event.getHttpServletResponse();

    if (event.getEventType() == EventType.BEGIN) { ...
    if (event.getEventType() == EventType.READ)  { ...
    if (event.getEventType() == EventType.END)   { ...
    if (event.getEventType() == EventType.ERROR) { ...
}

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

message.setValue("Howdy");
response.getWriter().write(message);
event.close();

смола

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

public class CometServlet extends GenericCometServlet {
    public boolean service(ServletRequest request,
                           ServletResponse response,
                           CometController cometController)
      ...
      return true;
    }

    public boolean resume(ServletRequest request,
                          ServletResponse response,
                          CometController cometController)
      PrintWriter out = res.getWriter();
      out.write(message);
      return false;
}

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

message.setValue("Howdy");
cometController.wake();

WebLogic

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

import weblogic.servlet.http.AbstractAsyncServlet;
import weblogic.servlet.http.RequestResponseKey;

class Async extends AbstractAsyncServlet {

public boolean doRequest(RequestResponseKey rrk) {
    ... = rrk;
    return false;
}

public void doResponse(RequestResponseKey rrk, Object message) {
    rrk.getResponse().getWriter.write(message);
}

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

message.setValue("Howdy");
AbstractAsyncServlet.notify(rrk, message);

Стеклянная рыба

GlassFish предоставляет наиболее гибкий API, и одной из его сильных сторон является то, что асинхронная возможность может быть обнаружена и использована во время выполнения. Когда addCometHandler () вызывается для cometContext, запрос приостанавливается.

    CometContext context =
        CometEngine.getEngine().register(contextPath);
    context.setExpirationDelay(20 * 1000);
    SuspendableHandler handler = new SuspendableHandler();
    handler.attach(response);
    cometContext.addCometHandler(handler);

class SuspendableHandler implements CometHandler  {
    public void onEvent(CometEvent event) {
    response.getWriter().println(event.attachment());
    cometContext.resumeCometHandler(this);
}  

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

message.setValue("Howdy");
cometContext.notify(message);

Кроме того, GlassFish предоставляет гарантию доставки и API-интерфейсы качества обслуживания.

атмосфера

Atmosphere (mosp.dev.java.net) — это инфраструктура, которая скрывает реализацию Comet / Ajax Push для конкретного контейнера, стремясь упростить разработку и улучшить переносимость асинхронных веб-приложений. Используя API Atmosphere, вы теперь можете писать переносимые приложения, не беспокоясь о контейнере, на котором вы будете развертывать. Что еще более важно, если контейнер не поддерживает Comet / Ajax Push, Atmosphere все равно будет работать, эмулируя его непосредственно в рамках.

Атмосфера призвана упростить разработку и улучшить переносимость асинхронных веб-приложений. Любой объект Java может быть расширен с помощью функций асинхронного сервера с помощью нескольких аннотаций, как показано ниже:

@Grizzlet(Grizzlet.Scope.APPLICATION)
@Path("myGrizzlet")
public class MyGrizzlet{

    @Suspend(6000)
    @GET     
    @Push
    public String onGet(){        
        return "Suspending the connection";
    }

    @POST     
    @Push
    public String onPost(@Context HttpServletRequest req,
                         @Context HttpServletResponse res) throws IOException{  
        res.setStatus(200);
        res.getWriter().println("OK, info pushed");
        return req.getParameter("chatMessage");
    }  

Сервлет 3.0

Servlet 3.0 будет охватывать возможность приостановить и возобновить соединение, но не будет поддерживать возможности асинхронного чтения / записи и гарантии доставки. Как интеграция лучших идей, существующих в существующих API, Servlet EG всегда обращает внимание общественности на обратную связь. Должен ли он иметь метод re-entrant service ()? Должны ли фильтры поддерживаться как для входящего запроса, так и для исходящего возобновленного ответа? Сейчас самое время высказать свое мнение.

Предел двух соединений

Наличие отличного серверного API — это только часть истории. Практическая проблема, возникающая при попытке реализовать push, заключается в том, что большинство браузеров обычно имеют ограничение в два соединения с данным сервером. Если пользователь открывает два окна браузера, каждое из которых пытается установить принудительное соединение с сервером, оба разрешенных TCP-соединения используются. Это означает, что любые пользовательские события (такие как нажатие на кнопку или ссылку) не будут отправляться на сервер — отсутствует доступное TCP-соединение для его передачи. Следовательно, нам нужно использовать одно TCP-соединение для нескольких окон браузера.

Сервер Ajax Push ICEfaces был создан для решения этой проблемы с помощью JMS для координации всех push-обновлений по одному каналу. В браузере используется технология опроса файлов cookie JavaScript для обмена уведомлениями об обновлениях через окна браузера (HTML5 postMessage () упростит реализацию здесь). Это обеспечивает надежную доставку push-обновлений из нескольких веб-приложений на сервер в несколько вкладок или окон браузера.

Для GlassFish ICEfaces предоставляет модуль центра обновлений, который позволяет легко добавлять и устанавливать Ajax Push Server, автоматически настраивая темы JMS.

Разработка асинхронных приложений

Мы рассмотрели варианты API Servlet, которые позволят нам разрабатывать масштабируемые push-приложения, но факт заключается в том, что сегодня не так много разработчиков работают непосредственно с Servlet API. Разработчики работают с API-интерфейсами, такими как Cometd, DWR и ICEfaces, в значительной степени скрывая основные возможности сервлетов. Итак, давайте кратко рассмотрим, как использовать эти фреймворки.

Для разработчика, концентрирующегося на JavaScript, отличный выбор — Cometd. Cometd основан на идее обмена сообщениями «публикация / подписка» с помощью рефлектора на стороне сервера. Обратите внимание, что сервер потенциально является просто отражателем и может быть реализован на любом языке, служа только ретранслятором сообщений между конечными точками JavaScript. Конечно, серверные API также возможны, и они доступны для различных серверов. Обратите внимание, что системы, основанные исключительно на обмене сообщениями клиентов, страдают от «проблемы позднего присоединения». Если вы присоединились к приложению поздно, у вас может не быть правильного промежуточного состояния для применения текущих сообщений.

Перейдя больше к сфере Java-разработки, у нас есть DWR, или «Direct Web Remoting». DWR, по сути, предоставляет знакомый Java RMI (или удаленный вызов метода, если он вам не знаком), соединенный с JavaScript. Прежде всего, DWR используется для предоставления JavaBean-компонентов на стороне сервера через объектно-ориентированные интерфейсы JavaScript, но возможен и «обратный» подход: DWR можно использовать для вызова методов JavaScript в клиенте из Java-кода на стороне сервера. Для иллюстрации заслуживают внимания два метода: addScript () позволяет приложению вызывать общий фрагмент JavaScript на группе указанных страниц, а setValue () позволяет приложению равномерно обновлять группу DOM браузера с указанным значением. Это мощные возможности на стороне клиента, доступные на сервере; Однако,они требуют, чтобы приложение сохраняло детальное знание содержимого просматриваемой страницы.

Теперь, когда мы увидели несколько API и фреймворков, мы должны сделать шаг назад и спросить, с какими идеальными разработчиками и дизайнерами приложений будет работать для создания приложения Ajax Push.

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

public class PageBean  {
    String text;

    public String getText()  {
        return text;
    }

    public void setText(String text)  {
	   this.text = text;
    }

}

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

<f:view
        xmlns:f="http://java.sun.com/jsf/core"
        xmlns:h="http://java.sun.com/jsf/html" >
  <html>
    <body>
      <h:form>
        <h:inputText value="#{pageBean.text}" />
      </h:form>
    </body>
  </html>
</f:view>

Но создание приложений таким естественным способом не только в нашем воображении. Такое четкое разделение между моделью и представлением является одной из сильных сторон JavaServer Faces (JSF), и разработчики и дизайнеры считают его очень продуктивным (даже если «разработка» и «дизайн» — это роли, выполняемые одним и тем же человеком в разное время) , Когда мы смотрим на предоставленный синтаксис, мы видим, что он ничего не говорит об Ajax (JavaScript не виден); все же, разве этого не должно быть достаточно для определения приложения Ajax? Мы описали объекты в модели (в Java), компоненты, которые видны в представлении (в XHTML), и как представление соотносится с моделью (в языке выражений). Фреймворк должен быть в состоянии перевести это в приложение Ajax для нас;действительно, это именно тот контракт, который ICEfaces предоставляет разработчикам приложений. Больше ничего не нужно для определения Ajax-приложения.

Но как насчет толчка? Когда мы считаем, что ICEfaces постепенно обновляет страницу с текущими значениями модели в ответ на пользовательские события, это маленький шаг, чтобы попросить, чтобы страница постепенно обновлялась с текущими значениями модели в ответ на события на стороне сервера. Другими словами, для того, чтобы приложение на стороне сервера могло вызвать передачу рендеринга страницы JSF, достаточно, чтобы инфраструктура могла вносить в браузер дополнительные изменения. Это делает добавление функций push простым как две строки кода.

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

SessionRenderer.addCurrentSession("chat")

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

SessionRenderer.render("chat")

Это отображает все окна всех пользователей в группе «чат» (автоматически определяя пошаговые изменения страницы) и передает эти изменения страницы в браузеры пользователей. Добавление push-функций в существующее приложение JSF часто может быть сделано не более чем в двух строках кода.

Кроме того, доступны более детальные API (например, для направления push-обновлений в определенные окна); пожалуйста, смотрите руководство разработчика ICEfaces для деталей.

Вывод

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