Как сделать мой Java приложением Swing Клиент-серверное приложение?
Я сделал Java приложением Swing. Теперь я хотел бы сделать это Клиент-серверным приложением. Все клиенты должны быть уведомлены, когда данные по серверу изменяются, таким образом, я не ищу веб-сервис. Клиент-серверное приложение будет запущено на единственной LAN, это - бизнес-приложение. Сервер будет содержать базу данных, JavaDB.
С чего технология и библиотека являются самыми легкими запуститься? Я должен реализовать его с нуля использующие Сокеты, или я должен использовать Java RMI или возможно JMS? Или есть ли другие альтернативы, с которых легче запуститься?
И есть ли какая-либо библиотека сервера, которой я должен пользоваться? Действительно ли Причал является альтернативой?
5 ответов
Mina является хорошим выбором в качестве фреймворка сетевых приложений для создания простого сервера для этих целей - это гораздо лучший вариант, чем использование сырых сокетов.
Если вам действительно нужен сервер приложений, то вы можете рассмотреть JBoss. Он также предоставляет компонент remoting (в качестве альтернативы чему-то вроде Mina):
http://www.jboss.org/jbossremoting
Однако у вас, вероятно, не будет большой потребности в Enterprise Java Beans. В большинстве случаев простого POJO более чем достаточно - вы можете связать все это с фреймворком инъекции зависимостей, таким как Guice:
http://code.google.com/p/google-guice/
или Spring. Сохраняйте простоту, не используйте J2EE-сервер, если это действительно не нужно. Надеюсь, это поможет.
Это многое из того, что делает J2EE, но это совершенно новая кривая обучения, потому что они заранее решили многие проблемы, с которыми вы столкнетесь, и многие, с которыми вы не столкнетесь, и поэтому добавили много новых технологий.
Но в самой своей основе J2EE отвечает именно на этот вопрос.
Я работал в таком проекте. Мы реализовали Swing на стороне клиента и на стороне сервера с J2EE. Мы использовали EJB, компоненты без состояния и компоненты, управляемые сообщениями. Также я участвовал в проекте отслеживания устройств и управления ими. Нашими клиентами были пользователи грузовиков + Swing, и мы использовали Servets + TCP / UDP, инфраструктуру Apache Mina для обработки и сохранения соединений.
Я работаю в Java Swing клиент/серверных приложениях почти 3 года. Я бы посоветовал вам перейти на RMI/EJBs. Первоначальное приложение, которое мы разрабатывали, использовало RMI/EJB для связи клиент-сервер с WebLogic в качестве сервера.
Но позже мы обнаружили, что в приложение необходимо включить множество "браузерных" функций, таких как таймаут сессии и т.д. Поэтому мы использовали BrightSide Framework, который оборачивает вызовы RMI через HTTP. Еще одно усовершенствование, которое мы внесли, это замена Weblogic на сервер JBoss с открытым исходным кодом.
Обертка вызовов с помощью HTTP станет очень удобной, и вы сможете сделать свои swing-приложения действительно богатыми. Позже, когда ситуация потребует от вас строгого использования веб-сайта, вы сможете развернуть свой swing с помощью jnlp.
Надеюсь, это помогло.
Учитывая, что у вас уже есть приложение, возможно, самое простое, что можно сделать, это определить интерфейс, который вам нужен между клиентом и сервером, и, прежде всего, рефакторить ваше приложение, чтобы использовать этот интерфейс для общения между back-end и front-end в рамках одного процесса.
Затем вы можете начать разделять это на части. Простым решением было бы разделить это с помощью RMI (поскольку вы общаетесь с Java-объектами и имеете вызовы Java-методов). Spring содержит полезные инструменты для упрощения/автоматизации RMI-обработки интерфейсов.
Для требования уведомления достаточно простой многоадресной рассылки UDP (или широковещательной рассылки).
Обратите внимание, что как только вы разделите приложение на части, у вас возникнут проблемы с поддержанием согласованных представлений данных, управлением своевременными обновлениями, обработкой случаев, когда сервер не работает, возможными проблемами с загрузкой при большом количестве клиентов и т.д. В некотором смысле, разделение приложения на клиент и сервер - это только начало нового архитектурного процесса.