![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Сервера приложений
Периодически на работе всплывает вопрос: а не завести ли нам манула? а не переселить ли приложения на трехзвенную архитектуру ради большей адекватности серверной части и убирания части логики с клиентской.
Но все это натыкается на то, что единственный сервер приложений на слуху - это JBoss, затраты от переписывания всего этого на жабу превысят потенциальные улучшения, а мысль о том, что придется деплоить это в условиях предприятий, где ИТ-службы или нет, или она состоит из адептов экзотических сортов клея, сразу оставливает любое желание что-либо делать.
В связи с этим, имеется вопрос: если не жаба и не дотнет, и не веб-интерфейсы, а нормальная трехзвенка - субд, аппсервер, более-менее интеллектуальный клиент и все это предпочительно кроссплатформенное - на чем такое вообще писать? И какая должна быть архитектура подобной вещи, а особенно - какая модель данных, какая парадигма программирования и в каком виде гонять данные между клиентом и аппсервером, чтобы это не оказалось очередной инкарнацией СуперУниверсальнойСистемыДляВсего, на которой сделать что-либо сложнее, чем это же склепать по быстрому с нуля вручную :)
Но все это натыкается на то, что единственный сервер приложений на слуху - это JBoss, затраты от переписывания всего этого на жабу превысят потенциальные улучшения, а мысль о том, что придется деплоить это в условиях предприятий, где ИТ-службы или нет, или она состоит из адептов экзотических сортов клея, сразу оставливает любое желание что-либо делать.
В связи с этим, имеется вопрос: если не жаба и не дотнет, и не веб-интерфейсы, а нормальная трехзвенка - субд, аппсервер, более-менее интеллектуальный клиент и все это предпочительно кроссплатформенное - на чем такое вообще писать? И какая должна быть архитектура подобной вещи, а особенно - какая модель данных, какая парадигма программирования и в каком виде гонять данные между клиентом и аппсервером, чтобы это не оказалось очередной инкарнацией СуперУниверсальнойСистемыДляВсего, на которой сделать что-либо сложнее, чем это же склепать по быстрому с нуля вручную :)
no subject
Я стремлюсь к минимализму и гибкости, а с ней это не получается. В результате мой теперяшний стэк выглядит так:
Jetty для http.
Spring для инициализации приложения, конфигурирования, обеспечения декларативных транзакций, работы с почтой и всяких мелочей.
Hibernate для ORM.
c3p0/commons-dbcp для пулинга работы с базой.
Самодельная либа AutoDAO для DAO.
Apache Wicket для веб-интерфейса.
Maven 2 для сборки.
RPC в зависимости от требований делаю либо с помощью Spring HttpInvoker (только Java<->Java, зато всего 2 строчки конфигов), либо с помощью вебсервисов (сановский jax-ws + jaxws-spring). Асинхронный RPC пока ни разу не понадобился.
Гуй не писал, раньше склонялся в пользу свинга, но в свете последних событий сильно им огорчён.
На клиенте в любом случае опять же юзал бы Spring, для единообразия настройки. Может быть имеет смысл заюзать вебстарт, но пока руки не дошли.
Единственное чем пока в данной конструкции пока недоволен - невозможно больше одного запроса из клиента к серверу в рамках одной транзакции. Как я понимаю при Spring HttpInvoker хоть сколько-нибудь готового решения нет вообще, для вебсервисов есть WSIT, но мне пока не удалось оторвать его от глассфиша.
no subject
Сам использую Tomcat, Spring, Hibernate/Spring JDBC + тот же Generic Dao, Spring'овские же декларативные транзакции и конфиги, Apache Commons библиотеки, куда уж без них :-). Насчет пула соединений, почему-то кажется, что в jdbc-драйверах последние пару лет есть собственные механизмы для этого. Для веб интерфейса GWT или Flex (этот больше нравится). Для сборки Maven 2 или Ant.
no subject
no subject
Вот собственно говоря, что больше всего пугает - это количество конфигурационных xml-файлов. Получается, что мы вместо одного места, где может быть ошибка(исходный код) получаем множество мест(исходный код+файлы конфигурации). Код становится более декларативным, по нему отладчиком особо не походишь.
Дело в том, что я похожую архитектуру (декларативные конфиги поверх набора классов) использовал в .net и дельфи, и каждый раз вместо упрощения получается усложнение :)
no subject
no subject