Сервера приложений

[metaclass]

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

Но все это натыкается на то, что единственный сервер приложений на слуху - это JBoss, затраты от переписывания всего этого на жабу превысят потенциальные улучшения, а мысль о том, что придется деплоить это в условиях предприятий, где ИТ-службы или нет, или она состоит из адептов экзотических сортов клея, сразу оставливает любое желание что-либо делать.

В связи с этим, имеется вопрос: если не жаба и не дотнет, и не веб-интерфейсы, а нормальная трехзвенка - субд, аппсервер, более-менее интеллектуальный клиент и все это предпочительно кроссплатформенное - на чем такое вообще писать? И какая должна быть архитектура подобной вещи, а особенно - какая модель данных, какая парадигма программирования и в каком виде гонять данные между клиентом и аппсервером, чтобы это не оказалось очередной инкарнацией СуперУниверсальнойСистемыДляВсего, на которой сделать что-либо сложнее, чем это же склепать по быстрому с нуля вручную :)

Comments

[max-posedon.livejournal.com]

Ну на этот вопрос ответ известен - 42.

Хотите общий ответ - apache, sqlite, протокол общения - XML(или что там у вас любимое) через HTTP. JBOSS-ов и .Net-а не требует. Логику помещаете в mod_whatever (написанную хоть на haskell) и наслаждаетесь жизню.
Все компаненты вроде не требуют admin прав, и завернуть их в oneclick-msi не сложно.

[metaclass.livejournal.com]

Да, в некотором роде идея хорошая :)

[max-posedon.livejournal.com]

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

[metaclass.livejournal.com]

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

[max-posedon.livejournal.com]

Попробуем обсуждать в терминах задач, а не просто "хотелки" что-то куда-то послать.

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

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

[zamotivator.livejournal.com]

Тут потребуется некоторый механизм серализации/десериализации объектов в XML и обратно, в СУБД и обратно...
Собственно, ORM системы этот вопрос и решают (как один из вопросов, что встаёт в серверах приложений).
Все в итоге идут к кодогенерации классов из некоторого описания.
В идеале - ER -> схему БД, ER -> классы + БД <-> объекты классов, объекты классов <-> XML