Есть ли способ подключить Java настольное приложение с MySQL через сервлеты или что-то подобное?

Question

Некоторое время я разрабатывал настольное приложение Java, и в основном он занимается CRUD-данными базы данных MySQL онлайн. Моя проблема сейчас в безопасности, я не хочу хардкорить любую пользовательскую информацию в клиентском приложении. Я думаю о двух способах сделать это:

1. Сконфигурировать большинство операторов MySQL в клиентском приложении и использовать серверное приложение для передачи клиенту информации о пользователе и пароле, таким образом, клиент может подключиться напрямую к базе данных. Мне эта идея не нравится, потому что я не хочу, чтобы у пользователя был какой-либо способ получения учетных данных базы данных.

2. Использование 3-уровневой архитектуры. У меня клиентское приложение почти полностью закодировано, у меня сервер, работающий на MySQL, теперь мне нужен средний уровень для обработки всех логических операций, учетных данных и всего, и для этого для связи с клиентским приложением, например: если клиент приложение запрашивает список инвентаря, затем сервер проверяет его учетные данные и отправляет клиентскому приложению файл со всеми данными инвентаря.

Моя проблема заключается в следующем:

• Какой компонент я должен использовать для достижения варианта 2? Мне сказали использовать сервлеты, я читал об этом, но будет ли это лучшим вариантом? Сервлеты используются для веб-приложений, и я не знаю, как заставить мое клиентское приложение (которое будет работать на рабочем столе) связываться с сервлетами и получать данные?

Answer 1

Или удаленный пользовательский интерфейс через веб-браузер

3-й вариант: веб-приложение, выполняющее все ваши бизнес-логи c на стороне сервера, с пользовательским интерфейсом, запущенным удаленно в веб-браузере с использованием автоматического сгенерированный HTML / CSS / JavaScript. Пользователь будет использовать веб-браузер, а не веб-браузер.

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

Существует две такие платформы:

• Vaadin с чистым Java на сервере. Построен на основе изношенной Java технологии сервлетов .
• Xojo Web Edition (ранее известной как RealBasi c) запуск проприетарного скомпилированного объектно-ориентированного языка программирования на сервере.

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

Обе эти платформы автоматически генерируют все HTML, CSS, JavaScript, DOM, AJAX, WebSocket, и Pu sh код. Так что вам не нужно осваивать эти веб-технологии. Обе эти платформы могут использоваться с любым современным веб-браузером, поскольку они используют только стандартные веб-технологии. Никаких плагинов или апплетов не задействовано.

Вам нужно будет переписать ваше приложение. Но это может быть не так страшно, как кажется. Большая часть работы в настольном приложении заключается в разработке, разработке деталей взаимодействия с пользователем и определении бизнес-правил. Это все перешло бы к вашей работе с Ваадином или Ходжо. И если вы используете Vaadin, весь ваш код не GUI Java будет напрямую передан.

Если ваше местное локальное приложение имело специальные функции, которые нельзя воссоздать в рамках ограничений веб-приложения, тогда этот подход не подходит. Но вы сказали, что основной целью вашего приложения является база данных CRUD . Такие бизнес-ориентированные на формы приложения являются основным назначением для Vaadin & Xojo Web Edition .

Запуск веб-приложения в автономном режиме

Vaadin имеет раннюю поддержку Progressive Web Apps (PWA) , чтобы включить веб-приложение, работающее в автономном режиме. В настоящее время самые передовые, но улучшающиеся браузеры уже поддерживают необходимую инфраструктуру. Если PWA можно заставить работать хорошо, некоторые виды настольных приложений можно заменить веб-приложением PWA.

См. Руководство по прогрессивному веб-приложению Vaadin .

Answer 2

Способ прокси

Что касается вашего конкретного варианта использования, я бы предложил вам еще один способ решения. Вы упомянули, что у вас уже есть настольное приложение, возможно, с большим количеством кода. На данный момент он запрашивает БД напрямую. Поэтому, с моей точки зрения, было бы довольно сложно перенести вашу логику доступа к данным c на другую технологию - 3tier. И это почти не зависит от точного выбора.

Если я правильно понял, ваша главная проблема - безопасность БД. Чтобы решить эту проблему, не переписывая приложение полностью, вы можете ввести своего рода прокси для БД в качестве промежуточного уровня. Этот прокси будет находиться на стороне сервера и хранить учетные данные для БД. Таким образом, они не будут доступны для клиента. Клиент подключается к прокси-серверу и ведет себя точно так же, как и раньше, за исключением учетных данных (конечно, вы можете требовать учетные данные для прокси-сервера). Для защиты необработанных данных вы можете ввести некоторые ограничения для доступа к данным на стороне прокси.

Я не уверен, что это простая задача. Это больше о сетевом / системном программировании. Но я ожидаю гораздо меньшего объема работы, если ваше текущее приложение будет большим и достаточно зрелым. Вы можете попытаться найти некоторые существующие инструменты, такие как jdb c -proxy, в качестве отправной точки.

Answer 3

Вы правы, что скептически относитесь к своему первому выбору. С одной стороны, MySQL и другие серверы баз данных намного более безопасны, когда они находятся в брандмауэре от publi c inte rnet.

Вам необходим серверный уровень, который может доставлять данные вашему клиенту ярус.

Важный совет по безопасности не создавайте серверный уровень для приема необработанных SQL запросов от клиентского уровня. Cybercreep может использовать его для выдачи запросов типа SELECT * FROM user и компрометации ваших данных. Или DROP TABLE user до sh вашей системы.

Разработайте API, с помощью которого ваши клиенты могут запрашивать услуги CRUD с вашего сервера. Возможно, вы захотите рассмотреть API в стиле REST, в котором клиенты могут произносить такие вещи, как

GET https://example.com/user/id

, или обновлять данные такими вещами, как

POST https://example.com/user/id

tel=5551212&email=mickey@disney.com

Хитрость заключается в том, чтобы выяснить, какие объекты вы хотите использовать в презентации RE S Tate T Перевод. Затем вы можете использовать http PUT для их создания, POST для их замены или обновления и DELETE для их удаления.

API в стиле REST довольно просты для реализации в вашем клиенте; они используют обычные операции HttpClient . Они легко защищены с помощью https.

Обычно они авторизуются с помощью секретного токена, ключа API, который передается в объекте заголовка http при каждом запросе. Вы можете прочитать об этом.

Итак, код вашего сервера должен реализовывать ваш API. Если вы решите использовать язык Java для его реализации, сервлеты - это путь к go: они позволяют разрабатывать и развертывать код Java веб-сервера. Вы можете развернуть их в серверной среде Tomcat или Jetty .

Существует множество ресурсов о том, как это сделать. Например, https://www.journaldev.com/9170/restful-web-services-tutorial-java