EJB или JavaBean

Трябва да направя едно приложение което предоставя rest интерфейс към бизнес логика отнемаща време и обработваща опашка от задачи.
Rest сървисът поставя задача в опашката, след като тя бъде обработена връща отговор на клиентът.

За реализацията на бизнес логиката се чудя какво да ползвам EJB (singleton) или да го направя с обикновен java bean с application scope. Като изборът съответно касае и смяна на сървърът на който ще върви приложението (tom ee заради ejb-то или tomcat).

Направи го максимално просто - Spring Boot ти дава и двете неща улеснено и не си зависим от App сървъра

хахаха

а си зависим от спринга, което е апсървър, само че без спецификация и стандарти

Как да не съм зависим, като spring boot включва сървър/web контейнер. Единствения плюс който виждам при него е, че приложението се пакетира със сървъра.

Ако решиш да контейнеризираш приложението си, този плюс не е за пренебрегване.

Дайте мнение за биновете - къде да набутам логиката - в сесийни ejb бинове или в обикновени pojo обекти (java beans). И по двата начина би работело, ама май по-чистия вариант (чисто архитектурно) е да ползвам ejb (евентуално mdb за поставяне на задачи в опашката, ама така пък не виждам как ще чакам за отговор ...).

Аз има подобно приложение, но убедих клиентите, да ползваме асинхронна комуникация:

1) Те изпращат заявка за обработка, която се изпраща на опашката и им се връща идентификатор на заявка
2) Обработката се извършва асинхронно
3) След известно време клиентът проверява състоянието на заявката на базата на идентификаторя върнат в първа стъпка, ако обработката не е приключила тази стъпка може да се повтори няколко пъти през определен интервал (polling)

Може би това е по-удачното решение, но не ми харесва постоянното питане за статус (не, че ми е проблем де) - по скоро ще го модна с някаква push нотификация.

При нас проблемът е, че натовареността на системата варира много - повечето заявки се изпълняват за секунди и не е проблем да се чака, но ако се затлачи обработката може и до часове да се стигне.

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

Пуш нотификацията също е вариант (всъщност и това го имаме в една система), но polling обикновено е най-лесно да за реализация и почти не изисква поддръжка.

защо не си купите Righting Software ?