Не пойму, сервер приложений -- это всегда веб-сервер?

Можно ли (имеет ли смысл) для, например, GlassFish, написать приложение, с которым общается "толстый" клиент, работающий на отдельном компьютере и написанный на обычной Java или вообще на другом языке?

Java сервер приложений - сервер приложений, поддерживающий технологию Java EE.
Эта технология включает в себя и веб, следовательно - любой сервер приложений обязан поддерживать и веб-технологии.

Можно толстый клиент, и на Java и на другом языке. Важно определить способ их взаимодействия. Обычно это веб-сервисы (soap или rest), работающие на HTTP транспорте.

А кроме веба, есть ли какие-то другие общепринятые способы общаться с приложением, работающем на сервере?

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

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

Добавлено через 3 минуты и 54 секунды

Допустим, я хочу, чтобы клиентская программа оперативно реагировала на события, происходящие на сервере. Позволит ли HTTP осуществить такое? Кажется, что HTTP потребует, чтобы клиент всегда сам опрашивал состояние.

Добавлено через 5 минут и 47 секунд
Иначе говоря, могу ли я установить постоянный канал связи между клиентом и приложением на сервере и получать по этому каналу сообщения о событиях? Точнее говоря, понятно, что так или иначе могу, но является ли это предусмотернным способом написания программ для серверов приложений?

Еще можешь использовать например Java RMI (Remote Method Invocation), протокола вызова удаленных процедур для Java.
Но и в этом случае по любому клиент вызывает серверное приложение.

А может серверное приложение вызвать клиента?

А можно еще сокетное соединение, тогда тебе неважно какой клиент. Главное определится с протоколом взаимодействия, например какой-либо XML-формат сообщений.
Тогда ты просто на клиенте запускаешь демона, который переодически будет опрашивать сервер.
Можно также посмотреть в сторону JMS и такой подход как рассылка/подписка.
Но всяко лучше смотреть в сторону каких-то стандартов.
Да, SOAP, получается поверх HTTP и чуть медленней прямого взаимодействия через RMI, но таким образом ты не завязыаешь на определенный тип клиента: ты просто написал сервис, запубликовал протокол в виде WSDL и ву-а-ля - клиенты плодитесь!
Для примера у меня такая ситуация:
Я изначально выбрал для своего приложения архитектуру WebService и не ошибся:
Первым клиентом моего приложения было бэкофисное приложение на Делфи, которые через процедуры Оракла и пакет utl_http посылало мне SOAP-запросы и разбирало XML-ответы из того же SOAP,
А теперь планируется еще один клиент с готовой архитектурой на JBOSS-ESB. И выйдет усе просто: повесить мой сервис на ESB не составит труда, а обмен сообщениями через шину уже есть норма. Дальше всего лишь надо будет этой аппликухе реализовать протокол взаимодействия с моим сервисом.

В общем усе зависит от потребностей проекта и знаний.

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

Что бы сервер мог вызвать, или оповестить о чем либо клиента, необходим протокол поддерживающий подобную фитчу. При этом соединение должно быть долгим, т.е. клиент и сервер открывают длительное TCP соединение (на весь сеанс), и отправляют друг другу асинхронные сообщения. Клиент может "дёрнуть" сервер и наоборот. Пример такого протокола - XMPP, он же Jabber.
HTTP, на основе которого практически всегда создаются веб-сервисы,  такого не поддерживает. У него порядок: открыл соединение, сделал запрос, получил ответ, закрыл соединение. Сеанс поддерживается за счет HTTP сессии и его идентификатора гуляющего между запросами.

Кстати да, абсолютно согласен, можно таким образом решить твою проблему.
Например вот пример:
Simple JMS clients
Однако в этом случае ты лишишься многих достоинств web сервисом, например "кросязычность".


Это сообщение отредактировал(а) Egik2 - 20.1.2010, 20:43

можно ещё глянуть на framework для серверных приложений.

http://www.jboss.org:80/netty/documentation.html

Это сообщение отредактировал(а) dobrolub - 20.1.2010, 21:30

Я знаю, отсюда и вопрос! С

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

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

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

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

Добавлено через 2 минуты и 28 секунд

Интересно, спасибо!

Остаётся вопрос: какие выгоды для серверной части работать внутри сервера приложений?

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

Я тут читаю и прихожу к выводу, что вместо EJB и сервера приложений лучше использовать Spring Framework. Так ли это?

Но запускать его тоже можно под app server...

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