Tomcat, ActiveMQ, Swing и автономный Java-сервер

Question

Я бы сказал, что это скорее общая публикация, требующая совета, а не прямой запрос на решение.

В настоящее время я планирую создать дизайн и инфраструктуру для запуска с моим коллегой, тем не менее, мой опыт лежит в сфере разработки Java Swing и миров JavaScript/Ajax, а также некоторых C++. С этим умом я считаю, что есть много других, которые могут помочь с предложениями и мыслями относительно моего дизайнерского предложения.

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

Второй вариант - это Swing (хотя открытый для других альтернатив Java и open source) на местных предприятиях для запросов менеджера, выполняемых через Интернет. Терминал будет постоянно подключен к нашей инфраструктуре для обновления статуса и обратной связи.

Наконец, инфраструктура будет представлять собой несколько автономных серверов Java, работающих в кластерах на основе их функциональности (управление, отчетность, запрос и т. Д.).

В настоящее время я думаю об использовании следующих решений: Для моего веб-уровня я бы использовал его с помощью Google Web Toolkit (учитывая его силу, принятие и потенциал). Веб-уровень управлялся бы через экземпляры tomcat с балансировкой нагрузки, напрямую связанные через ActiveMQ с внутренними ресурсами сервера.

Серверы будут простыми многопоточными серверами Java, обрабатывающими сообщения из службы обмена сообщениями ActiveMQ. Мне нужен совет по поддержанию кластеризации (убедитесь, что данные синхронизированы, а также возможность загрузки баланса, так что связь между подобными серверами имеет решающее значение)

Наконец, я не уверен, как реализовать это, но мои первоначальные мысли связаны удаленные терминалы в базовую сеть через сервер шлюза (мысль о экземпляре tomcat, но для двунаправленного действия должна была отказаться от мысли) через Active MQ или просто через TCP.

Я не занимаюсь использованием Tomcat против Java EE или весной, так как основная часть тяжелого подъема фактически будет выполняться серверами задней части.

Является ли мой проект выполнимым? У вас есть какие-нибудь рекомендации? Основные недостатки? проблемы масштабируемости? Я был бы очень признателен за все входные данные ...

Answer 1

Вместо того чтобы писать собственные серверы с пользовательской настройкой потоков, попробуйте использовать установленные Java EE-серверы (GlassFish, JBoss, Geronimo). Они упростят работу и сократят время разработки. Мы говорим здесь о проверенном и проверенном сервере приложений. Spring имеет богатый API, который сделал меня продуктивным, с недостатком, возможно, большого количества конфигураций XML (которые сами по себе хороши, поскольку вы можете больше изменять приложение без написания большого количества кода). Я бы порекомендовал Spring на сервере Java EE

Я бы порекомендовал Tapestry для веб-уровня, потому что он упрощает разработку и поддерживает базовый CRUD из коробки. Некоторые подробно howtos. При этом рассмотрим подробный web framework comparison

Для настольного приложения я бы предложил Eclipse RCP, однако вам нужно убедиться, что вы понимаете фрейм , some tutorials. Возможно, вы захотите, чтобы это приложение основано на веб-интерфейсе, если на стороне клиента не так много бизнес-логики.

Проблемы с подключением могут быть значительно упрощены с помощью веб-служб через SSL с аутентификацией. Но это может быть медленным. Другой вариант может быть Google's Protocol Buffers

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

Answer 2

Вот что я хотел бы предложить, как это будет запуск:

1. Как вы начали использовать GWT для вашей стороны сервера. Воспользуйтесь этим опытом, который ваша организация создала и развивала вашу клиентскую сторону, также основываясь на этих знаниях.

2. Для приложения на стороне клиента уменьшите область применения swing, это приложение swing начнет внедренное веб-приложение tomcat с помощью приложения swing и пользователь сможет получить к ним доступ (клиентская сторона с помощью веб-страницы localhost) в качестве веб-страницы. Пользователь может также предоставить другим людям также возможность взглянуть на то, что он видит, что-то вроде предоставления другому ip доступа к его локальной информации, которая размещается {с помощью embobbeded tomcat} со своего локального стола.