![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Сервера приложений
Периодически на работе всплывает вопрос: а не завести ли нам манула? а не переселить ли приложения на трехзвенную архитектуру ради большей адекватности серверной части и убирания части логики с клиентской.
Но все это натыкается на то, что единственный сервер приложений на слуху - это JBoss, затраты от переписывания всего этого на жабу превысят потенциальные улучшения, а мысль о том, что придется деплоить это в условиях предприятий, где ИТ-службы или нет, или она состоит из адептов экзотических сортов клея, сразу оставливает любое желание что-либо делать.
В связи с этим, имеется вопрос: если не жаба и не дотнет, и не веб-интерфейсы, а нормальная трехзвенка - субд, аппсервер, более-менее интеллектуальный клиент и все это предпочительно кроссплатформенное - на чем такое вообще писать? И какая должна быть архитектура подобной вещи, а особенно - какая модель данных, какая парадигма программирования и в каком виде гонять данные между клиентом и аппсервером, чтобы это не оказалось очередной инкарнацией СуперУниверсальнойСистемыДляВсего, на которой сделать что-либо сложнее, чем это же склепать по быстрому с нуля вручную :)
Но все это натыкается на то, что единственный сервер приложений на слуху - это JBoss, затраты от переписывания всего этого на жабу превысят потенциальные улучшения, а мысль о том, что придется деплоить это в условиях предприятий, где ИТ-службы или нет, или она состоит из адептов экзотических сортов клея, сразу оставливает любое желание что-либо делать.
В связи с этим, имеется вопрос: если не жаба и не дотнет, и не веб-интерфейсы, а нормальная трехзвенка - субд, аппсервер, более-менее интеллектуальный клиент и все это предпочительно кроссплатформенное - на чем такое вообще писать? И какая должна быть архитектура подобной вещи, а особенно - какая модель данных, какая парадигма программирования и в каком виде гонять данные между клиентом и аппсервером, чтобы это не оказалось очередной инкарнацией СуперУниверсальнойСистемыДляВсего, на которой сделать что-либо сложнее, чем это же склепать по быстрому с нуля вручную :)
no subject
Скажем, если нужно отправить какой-то запрос на сервер и дождаться результата, не понадобится ли потом поверх очередей реализовывать вручную синхронные протоколы?
no subject
Формально есть "генераторы" данных, есть их "потребители", если хочешь послать данные и дождаться их результата, то у данной программы можно сделать разрез попалам. первая часть "генератор запроса на сервер", вторая "обработчик результата с сервера". Да, тут немного другие подходы, и немного ломается моск, но идея в принципе здравая и широкоиспользуемая.
Если есть конкретный пример, что нужно сделать, я попытаюсь конкрнетно ответить как это решается через очередь сообщений. Вообще да, тут главный упор делается на асинхронность и многоагентность. Но неплохо повышает одказоустоичивость, ибо падение всего, кроме самой очереди не страшно.