С чего начать использование Java на сервере

Кластеризация методом умножения, «запусти-ка мне глассфиш на трех серверочках мое приложение», или нормальная, контролируемая? С ерлангом удобно, например, положить на каждую ноду по отдельному куску функциональности, и потом прозрачно звать функции этих нод. Например, вот на этой ноде будут числодробилки, а на этой - бизнес-логика. Или в игре, один кусок игровой локации - один сервер. На PHP и Питоне так это вообще единственный вменяемый способ, но на них приходится самому сочинять и выставлять какое-то внутреннее апи для каждой ноды, юзать всякие стремные протобуфы чтобы не тормозило и трахаться когда версия апи поменялась. А на ерланге все максимально супер тупо и супер прозрачно, изолента и ножницы - вот и все что нужно чтобы сделать кластер.

Ты уверен в этом?

Я так хочу.

Вот можете посмотреть как все делается на Java EE 7

https://www.dropbox.com/s/9yct3ppvlujish1/jeeweb1.zip

1. Ставите Wildfly 8 Beta. Запускаете standalone.sh или .bat

2. Ставите Maven 3.

3. Устанавливаете все переменные окружения которые они просят.

4. Из папки где pom.xml делаете mvn install wildfly:deploy

5. http://localhost:8080/jeeweb1/

Потом можно будет deploy заменить на redeploy.

Первая сборка очень долгая потому что очень много чего себе будет качать Maven

Две точки входа в приложение.

ArithmeticWebservice - REST сервис

ArithmeticWebsocketEndpoint - вебсокет

Вот EJB с сервисом, я показал как делать сервисы бизнес-логики - AdditionService. Да это именно тот жирный EJB с кучей бойлерплейта о котором все говорят. Not anymore :)

Магический клас активирующий JAX-RS - внезапно JaxRSActivator

По настоящему непрерывное - веб-сокет. Но чем не подходит HTTP с keep alive, о жизненом цикле которого не нужно даже думать, а все писать как будто его нет?

у хттп стремный перфоманс и нагрузка на сервер, например

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

Ну можно говорить куда кидать разные EJB. А если лень разбираться, то просто написать отдельные приложения и все

ну да, н-р сообщения в играх, шутере или realtime strategy, где очень важны доли секунды пинга до сервера, для игрока эти доли секунды - разница между победой и проигрышем

еще, по хттп плохо push-нотификации, не? Клиент должен постоянно долбить сервер «а есть ли для меня новые сообщения, хозяин?». Серверу становится под нагрузкой от бессмысленных огромных запросов, серверу плохо.

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

Кластеризация методом умножения, «запусти-ка мне глассфиш на трех серверочках мое приложение», или нормальная, контролируемая?

http://habrahabr.ru/company/jelastic/blog/138193/

См. п. 6. Для того, чтобы GlassFish производил репликацию Http-сессий между экземплярами кластера необходимо, чтобы веб-дескриптор приложения содержал соответствующую инструкцию (тэг <distributable/>) и при деплое приложения установить флаг Avalaibility.

Очевидно, такое Java EE приложение будет работать на всех узлах кластера. Иначе какой смысл в кластеризации, как не в распределении нагрузки на железо и не в отказоустойчивости всего кластера? Один сервер вышел из строя — приложение на живом сервере подхватило пользовательскую сессию и продолжило обслуживание запрососов клиента. Клиент ничего не почувствовал. PROFIT!

Предпочитаете такое велосипедить на эрлангах?

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

меня гораздо больше волнует взаимодействие нескольких разных приложений

Отказ одного приложения выносит всю цепочку взаимодействия (нескольких разных приложений) в аут?

когда не найдено ни одного storage-сервера - это печально, не в чем хранить данные. Когда не найдено ни одного веб-сервера - это печально, нечем показывать странички. Итп.

Недавно наткнулся на статью: Сравнение производительности механизмов ввода-вывода в Java: классического (блокирующего), неблокирующего и асинхронного.