| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > Сервер приложений -- это всегда вебсервер? |
| Автор: Dims 20.1.2010, 16:36 |
| Не пойму, сервер приложений -- это всегда веб-сервер? Можно ли (имеет ли смысл) для, например, GlassFish, написать приложение, с которым общается "толстый" клиент, работающий на отдельном компьютере и написанный на обычной Java или вообще на другом языке? |
| Автор: Egik2 20.1.2010, 16:41 |
| Java сервер приложений - сервер приложений, поддерживающий технологию Java EE. Эта технология включает в себя и веб, следовательно - любой сервер приложений обязан поддерживать и веб-технологии. |
| Автор: powerOn 20.1.2010, 16:56 | ||
Можно толстый клиент, и на Java и на другом языке. Важно определить способ их взаимодействия. Обычно это веб-сервисы (soap или rest), работающие на HTTP транспорте. |
| Автор: Dims 20.1.2010, 16:57 | ||
| А кроме веба, есть ли какие-то другие общепринятые способы общаться с приложением, работающем на сервере? Например, описанная мной схема -- на сервере работает приложение, у которого нет интерфейса, а с ним общается клиентская часть, работающая на компьютере пользователя -- является ли общепринятой? Предназначены ли серверы приложений для создания таких решений? Добавлено через 1 минуту и 1 секунду Или, заходя с другой стороны, какое преимущество для серверной части работать внутри сервера приложений, а не быть отдельностоящей программой? Добавлено через 3 минуты и 54 секунды
Допустим, я хочу, чтобы клиентская программа оперативно реагировала на события, происходящие на сервере. Позволит ли HTTP осуществить такое? Кажется, что HTTP потребует, чтобы клиент всегда сам опрашивал состояние. Добавлено через 5 минут и 47 секунд Иначе говоря, могу ли я установить постоянный канал связи между клиентом и приложением на сервере и получать по этому каналу сообщения о событиях? Точнее говоря, понятно, что так или иначе могу, но является ли это предусмотернным способом написания программ для серверов приложений? |
| Автор: Egik2 20.1.2010, 17:03 |
| Еще можешь использовать например Java RMI (Remote Method Invocation), протокола вызова удаленных процедур для Java. Но и в этом случае по любому клиент вызывает серверное приложение. |
| Автор: Dims 20.1.2010, 17:59 |
| А может серверное приложение вызвать клиента? |
| Автор: MisterCleric 20.1.2010, 18:03 |
| А можно еще сокетное соединение, тогда тебе неважно какой клиент. Главное определится с протоколом взаимодействия, например какой-либо XML-формат сообщений. Тогда ты просто на клиенте запускаешь демона, который переодически будет опрашивать сервер. Можно также посмотреть в сторону JMS и такой подход как рассылка/подписка. Но всяко лучше смотреть в сторону каких-то стандартов. Да, SOAP, получается поверх HTTP и чуть медленней прямого взаимодействия через RMI, но таким образом ты не завязыаешь на определенный тип клиента: ты просто написал сервис, запубликовал протокол в виде WSDL и ву-а-ля - клиенты плодитесь! Для примера у меня такая ситуация: Я изначально выбрал для своего приложения архитектуру WebService и не ошибся: Первым клиентом моего приложения было бэкофисное приложение на Делфи, которые через процедуры Оракла и пакет utl_http посылало мне SOAP-запросы и разбирало XML-ответы из того же SOAP, А теперь планируется еще один клиент с готовой архитектурой на JBOSS-ESB. И выйдет усе просто: повесить мой сервис на ESB не составит труда, а обмен сообщениями через шину уже есть норма. Дальше всего лишь надо будет этой аппликухе реализовать протокол взаимодействия с моим сервисом. В общем усе зависит от потребностей проекта и знаний. Да, чуть не забыл: сам мой сервис является сокетным клиентом другого удаленного приложение на C++. Просто я формирую тоже XML по требуемому от меня протоколу. |
| Автор: powerOn 20.1.2010, 19:24 | ||
Что бы сервер мог вызвать, или оповестить о чем либо клиента, необходим протокол поддерживающий подобную фитчу. При этом соединение должно быть долгим, т.е. клиент и сервер открывают длительное TCP соединение (на весь сеанс), и отправляют друг другу асинхронные сообщения. Клиент может "дёрнуть" сервер и наоборот. Пример такого протокола - XMPP, он же Jabber. HTTP, на основе которого практически всегда создаются веб-сервисы, такого не поддерживает. У него порядок: открыл соединение, сделал запрос, получил ответ, закрыл соединение. Сеанс поддерживается за счет HTTP сессии и его идентификатора гуляющего между запросами. |
| Автор: Egik2 20.1.2010, 20:39 | ||
Кстати да, абсолютно согласен, можно таким образом решить твою проблему. Например вот пример: http://java.sun.com/products/jms/tutorial/1_3_1-fcs/doc/client.html Однако в этом случае ты лишишься многих достоинств web сервисом, например "кросязычность". |
| Автор: dobrolub 20.1.2010, 21:02 |
| можно ещё глянуть на framework для серверных приложений. http://www.jboss.org:80/netty/documentation.html |
| Автор: Dims 21.1.2010, 10:30 | ||||
Я знаю, отсюда и вопрос! С одной стороны читаю, что бины как бы живут в сервере приложений. Возникает привлекательная картинка: бины живут себе в сервере приложений, обеспечивают бизнес-логику, а к ним можно обращаться откуда-то извне. Но с другой стороны как читаю про серверы приложений, так сразу вижу, что написано про всякие веб-сервисы. Создаётся впечатление, что серверы приложений заточены исключительно под них, а это уже не так привлекательно. Если я хочу сделать клиента с низкой латентностью, то есть, который мгновенно и без задержек реагирует на действия пользователя, то это должен быть "толстый" клиент. Получается, писать для него серверную часть под какой-либо сервер приложений -- бессмысленно? Добавлено через 2 минуты и 28 секунд
Интересно, спасибо! Остаётся вопрос: какие выгоды для серверной части работать внутри сервера приложений? |
| Автор: serger 21.1.2010, 13:30 | ||
Стандартизированная и общая инфраструктура, в том числе проще организовать взаимодействие м/у частями, администрировать. |
| Автор: Dims 21.1.2010, 13:39 |
| Я тут читаю и прихожу к выводу, что вместо EJB и сервера приложений лучше использовать Spring Framework. Так ли это? |
| Автор: serger 21.1.2010, 15:39 | ||
Но запускать его тоже можно под app server... |
| Автор: powerOn 21.1.2010, 19:06 | ||
По этому вопросу однозначного мнения быть не может. Каждый для себя решает что лучше в зависимости от поставленных задач и методов, выбранных для их решения. |
| Автор: Dims 21.1.2010, 20:44 | ||
Но необязательно. А готовый функционал тоже даётся, плюс к тому нет таких требований к написанию. |
| Автор: COVD 21.1.2010, 21:10 | ||
Сначала появилось EJB. Sun призвал всех на освоение новой технологии - легко, быстро и на профессиональном уровне создавать клиент-серверные приложения. Пипл с энтузиазмом отреагировал на призыв, но потом начал роптать, мол, не легко и не быстро и в 95% случаев избыточно. И тогда нарисовался Spring с идеей "Не нужно нам все в одном флаконе - принцип Голливуда рулит". Если в приложении больше трех классов, то надо использовать Spring, а то можно запутаться. И теперь уже Spring везде и за что он только не берется. |
| Автор: NeoNYura 27.1.2010, 18:33 |
| Если мне не изменяет память Спринг появился как альтернатива Enterprise JavaBeans, так как их первые реализации были достаточно не удобны. В итоге J2ee подросло и окрепло. Но и спринг не стоял на месте. Некоторым конторам больше Spring нравится а некоторым EE, однозначно сказать что лучше мне кажется не возможно. |
| Автор: COVD 28.1.2010, 22:22 | ||
Точно. Создатели Спринг книгу публиковали http://www.amazon.com/Expert-One-One-Development-without/dp/0764558315 |
