Ответ 1
Поднимите Comet Architecture, которая была выбрана Novell для питания своего продукта Pulse после оценки ряда различных технологий.
Реализация Lift Comet использует одно HTTP-соединение для опроса для изменения произвольного количества компонентов на странице. Каждый компонент имеет номер версии. Длительный опрос включает номер версии и GUID компонента. На стороне сервера слушатель подключен ко всем GUID, указанным в запросах длительного опроса. Если какой-либо из компонентов имеет более высокий номер версии (или номер версии увеличивается в течение периода длительного опроса), дельта (набор JavaScript, описывающий изменение от каждой версии) отправляется клиенту. Дельты применяются, а номер версии на клиенте устанавливается на самый высокий номер версии для набора изменений.
Подъем включает в себя длительный опрос с управлением сеансом, так что если запрос попадает в один и тот же URL-адрес во время длительного опроса, который вызвал бы голод в связи с подключением, длительный опрос прекращается, чтобы избежать голода в сети (некоторые браузеры имеют не более двух HTTP-соединений в названный сервер, другие - не более 6). Lift также поддерживает DNS-серверы с DNS-серверами для длительных запросов опроса, так что каждая вкладка в браузере может выполнять длительный опрос против другого сервера подстановочных DNS-серверов. Это позволяет избежать проблем, связанных с голоданием.
Подъем динамически обнаруживает контейнер, в котором работает сервлет, и на Jetty 6 и 7 и (скоро) Glassfish, Lift будет использовать реализацию "продолжения" платформы, чтобы избежать использования нити во время длительного опроса.
Лифт JavaScript может сидеть на вершине jQuery и YUI (и мог также сидеть поверх Prototype/Scriptaculous.) Фактический код опроса включает в себя откат при сбоях соединения и другие "изящные" способы борьбы с неудачными отказами подключения.
Я посмотрел на Atmosphere, CometD, Akka (все технологии Comet, ориентированные на JVM). Ни один из них (в то время, когда я их оценивал) поддерживал несколько компонентов на страницу или предотвращение голода в связи.
Novell начал с нуля и выбрал Lift to power Pulse по очень веским причинам.
С точки зрения безопасности, Lift beats Spring + Spring Безопасность снижается. См. http://www.mail-archive.com/[email protected]/msg13020.html
В принципе, безопасность безопасности выпекается в вашем приложении. Приложения по умолчанию устойчивы к распространенным проблемам (межсайтовый скриптинг, повторные атаки, подделки с запросами на кросс-сайт). Приложения по умолчанию устойчивы к параметрированию. Карта sitemap определяет правила навигации по сайту и правила доступа. Это означает, что у вас никогда не было ссылки, на которую никто не может щелкнуть. Вам не нужно иметь внешний фильтр (например, Spring Security), который вам нужно настроить независимо от вашего приложения (whoops... переместил страницу, но забыл убедиться, что файл безопасности w760 > был обновлен.)
Ох... и если вы не хотите использовать язык шаблонов, вот полный компонент чата в разделе "Подвижная комета":
class Chat extends CometActor with CometListener {
private var msgs: List[String] = Nil
def registerWith = ChatServer
override def lowPriority = {
case m: List[String] => msgs = m; reRender(false)
}
def render = {
<div>
<ul>
{
msgs.reverse.map(m => <li>{m}</li>)
}
</ul>
<lift:form>
{
SHtml.text("", s => ChatServer ! s)
}
<input type="submit" value="Chat"/>
</lift:form>
</div>
}
}
И чтобы вставить это на страницу: <lift:comet type="Chat"/>