Миграция 2-уровневого Java-приложения в ...?

Question

В настоящее время у нас есть двухуровневое приложение Java Swing, расположенное поверх MS SQL Server 2005. Вся бизнес-логика находится в базе данных.Клиент довольно старый (и не очень дружелюбный), и по соображениям производительности и масштабируемости мы уже начали переносить некоторые службы на средний уровень в Java.

Однако у нас все еще есть ряд короткихи долгосрочные цели:

Выбор технологического стека для нового интерфейса

Это непросто - я вижу все - от веб-приложения на одном конце континуума до традиционногоприложение для настольного компьютера на другом является жизнеспособным выбором.Текущий интерфейс не очень сложен (в основном на основе форм), поэтому я вижу подходящие web / AJAX, но это область, где мы не знаем, чего не знаем.

Стекив моем списке:

• Eclipse RCP, Netbeans RCP
• Flex / Flash, Silverlight, JavaFX
• Чистые интерфейсы Javascript (Sprout Core, Javascript MVC, ...)
• Веб-фреймворки на основе Java (Wicket, JSF, ...)

Найдите способ заставить текущее приложение приемлемо работать в удаленной ситуации

У нас есть клиенты, которые перепродают наше приложение мелким клиентам и должны иметь возможность удаленного развертывания.Из-за двухуровневой природы текущей архитектуры это приводит к ужасной производительности (например, вызов хранимой процедуры, которая возвращает 18 наборов результатов).В прошлом мы использовали решение Citrix, но такой подход никому не нравится.Туннелирование JDBC через порт 80 также звучит как плохая идея.Я начинал задаваться вопросом, есть ли что-нибудь, что могло бы использовать X-Windows-подобный подход к удаленной части графического интерфейса.

Answer 1

Мы только что прошли очень похожий процесс оценки при переносе устаревшего приложения.

Для нас самым большим решающим фактором в том, какую интерфейсную среду использовать, было предварительное знание команды разработчиков. Мы хотели чего-то, что всем сразу было бы удобно. У нас была пара старших разработчиков, которые работали с X или Y, но фреймворк, который все знали, был Swing.

В итоге мы выбрали платформу NetBeans, использующую веб-сервис RESTful для связи с сервером EE.

В качестве бонуса вы можете заставить ваше приложение на платформе NetBeans развертываться как приложение Java WebStart, что означает, что вам не нужно беспокоиться об отдельных установках.

Answer 2

Чтобы упростить разработку и использовать свой опыт в Swing , рассмотрите возможность использования Vaadin для своего интерфейса . Это Java-фреймворк для создания современных веб-приложений, которые отлично выглядят и хорошо работают. Весь код написан на Java и выглядит очень похоже на Swing.

Что касается общей архитектуры приложения, я бы посоветовал многоуровневую сервис-ориентированную архитектуру. Лучший способ сделать это - использовать Spring Framework с Hibernate для доступа к базе данных .

Answer 3

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

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

Относительно лучшего фреймворка, зависит от знаний вашей команды, способа вашего приложения.будет использоваться (более или менее JavaScript) и т. д.

Answer 4

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

Answer 5

Предполагая, что вы собираетесь заставить всех своих клиентов установить новый средний уровень, я не могу придумать аргумента против того, чтобы сделать его веб-приложением на Java. Как уже упоминалось, у вас есть преимущество в управлении всем доступом к вашей платформе через HTTP, что позволяет легко перепродавать, просто с настройкой брандмауэра. Нет причин, по которым вы не можете использовать Javascript в веб-интерфейсе, вас может заинтересовать DWR , который позволяет напрямую взаимодействовать с объектами Java через Javascript. Я использовал это раньше, чтобы добавить простое взаимодействие с Ajax в веб-приложение Spring MVC.

Причины, по которым мне нравится этот подход, вы уже переносите код на средний уровень Java, поэтому

1. Уже навязывая клиенту стоимость аппаратного обеспечения Java-сервера, хост-сервер приложений / веб-сервер сопоставим
2. У вас уже есть опыт работы с Java, вы можете использовать DWR
3. Может использовать столько, сколько нужно Javascript (я использовал DWR с IE6, Firefox 3, Chrome)

Я думаю, что вы правы, опасаясь использовать слишком много функциональности для клиента, я бы выбрал максимально тонкого клиента. Единственная причина, по которой я посмотрю на первые два варианта стека, заключается в том, что у вас есть опыт разработчика в определенной области, а не Java-приложение / Javascript.

Answer 6

Если интерфейс в основном основан на форме, я бы держался подальше от Flex.Flex отлично подходит для некоторых приложений (я использую его для холст-приложений), но у компонентов формы Flex есть некоторые проблемы с удобством использования.Они просто не работают так, как вы ожидаете от сегодняшней сети.(например, отсутствует поддержка колесика мыши, ввод в выпадающем списке учитывает только первый символ и т. д.)